Security and compliance

Version: 2025-12-17
Owner: Epoynt Technologies Ltd. (Taxpoynt)

This document summarizes Taxpoynt's security controls and compliance posture for delivering SI/AP e-invoicing services.

1) Data and information security compliance

• NDPR-aligned controls: Tenant scoping by organization/environment, least-privilege access, encryption in transit, and auditable access/change logs.
• Cloud provider compliance: Production infrastructure is planned on AWS and leverages provider security and compliance programs (e.g., ISO 27001/SOC reports at the cloud layer). Cloud provider attestations/reports are available where applicable.
• Operational controls: Versioned deployments, change management, incident response, and periodic backup/restore testing; connector health checks and readiness gating reduce unsafe processing.

2) Data encryption standards

The platform uses the following data encryption standards:

• In transit: TLS 1.2+ for all public endpoints (https://api.taxpoynt.com, https://app.taxpoynt.com, https://www.taxpoynt.com); strict HTTPS-only transport on production deployments.
• At rest: Managed database and object storage encryption at rest (e.g., PostgreSQL + S3 server-side encryption; SSE-KMS where enabled).
• Keys/secrets: Secrets are managed via deployment environment variables or secret managers with rotation practices; per-org FIRS credentials are stored encrypted at rest and crypto key material is not exposed in the UI. Connector configs (e.g., Odoo) are encrypted at rest; per-org/env API keys are issued once and stored hashed/secured.
• Passwords: Passwords are hashed using bcrypt (salted, one-way).
• Webhook integrity: Callback payloads include x-signature computed as HMAC-SHA256 over the raw request body; Mono webhooks use x-mono-signature + x-mono-timestamp; KYC webhooks use x-kyc-signature + x-kyc-timestamp.

3) Access control and tenant isolation

• Multi-tenant scoping is enforced by organizationId + environmentId (sandbox vs production) across reads/writes.
• RBAC is enforced for protected operations (SI/AP access, callbacks, replay, configuration).
• Per-environment configuration separates sandbox from production and prevents cross-tenant access; connector flags are scoped per environment.
• Sandbox callbacks are allowlisted and HTTPS-only by default; inbound KYC and Mono webhooks require HMAC signatures with timestamp validation.

4) Audit, monitoring, and traceability

• Processing events and configuration changes are written to audit logs; invoice processing returns trace IDs for support and reconciliation.
• Connector health, pipeline metrics, and recent failures are tracked in operational telemetry.
• DLQ and replay controls are available for failed invoice processing and callbacks.
• Mono eligibility decisions and reconciliation failures are tracked with trace IDs and DLQ entries for review.

5) Incident response and vulnerability management

• Incidents follow severity-based response targets and post-incident reporting (PIR/RCA) as described in docs/mbs/sla.md.
• Vulnerability handling includes dependency management, access reviews, and remediation tracking; customers are notified of material security issues per contractual terms.

6) Data retention and privacy

• Data retention aligns with customer contracts and regulatory requirements. Data processing and privacy commitments are documented in the Data Processing Agreement and Privacy Policy.