Security and compliance

Version: 2026-07-10 (supersedes 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. Claims below reflect the deployed platform (API on Railway, region europe-west4; web/cockpit on Vercel; managed PostgreSQL), not planned architecture — planned items are marked as such.

1) Data and information security compliance

• NDPR-aligned controls: Tenant scoping by organization/environment, least-privilege access, encryption in transit and at rest, and auditable access/change logs. Terms, Privacy, and Data Processing commitments are published on the marketing legal pages.
• Cloud provider compliance: Production runs on managed cloud infrastructure (Railway compute + managed PostgreSQL; Vercel CDN/frontend), leveraging provider security programs at the infrastructure layer. A migration to AWS (VPC, ALB, RDS Multi-AZ, KMS) remains a planned scale-up path.
• Operational controls: Versioned deployments with CI security gates on every merge (SAST, dependency audit via pnpm audit --prod, DAST SQL-injection probes, clean-database migration smoke), change management via protected branches and mandatory checks, documented incident response, and provider-managed automated database backups.

2) Data encryption standards

• In transit: TLS 1.2+ (TLS 1.3 supported) on all public endpoints (api.taxpoynt.com, app.taxpoynt.com, www.taxpoynt.com) with managed certificates and automated issuance/renewal; HTTPS-only with HTTP Strict Transport Security (HSTS) response headers on the API. Outbound calls to NRS MBS endpoints are TLS-encrypted and routed through an authenticated egress gateway with a static IP registered with NRS.
• At rest (application layer): Per-organization, per-environment NRS/FIRS API credentials are encrypted with AES-256-GCM (unique random 96-bit IV and authentication tag per record) under a dedicated encryption key (FIRS_CREDENTIALS_ENCRYPTION_KEY) that is segregated from authentication secrets; production refuses to boot without it (ADR 0008). ERP connector configurations are encrypted under their own dedicated key. TOTP MFA secrets are encrypted with AES-256-GCM under a further dedicated key.
• At rest (storage layer): Managed PostgreSQL storage is encrypted at rest by the hosting provider.
• Keys/secrets: Secrets are managed as deployment environment variables with rotation practice; per-org/env API keys are issued once and stored as one-way hashes; invoice-signing key material is held in operational key custody and never exposed through UI or API responses.
• Passwords: Hashed with 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; PostgreSQL row-level-security policies are additionally provisioned as defense-in-depth with a staged enforcement rollout.
• RBAC is enforced for protected operations (SI/AP access, callbacks, replay, configuration); global API rate limiting and a strict CORS origin allowlist protect the perimeter.
• 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) Multi-factor authentication

• Factors: Time-based one-time passwords (TOTP, RFC 6238) enrolled via QR code, plus ten single-use hashed backup codes (regenerable only with a valid code).
• Login step-up: Users with MFA enabled complete a challenge bound to a short-lived (5-minute), single-purpose token with a capped number of attempts; repeated failures trigger a temporary lockout.
• Lifecycle controls: Disabling MFA requires both the account password and a valid code; TOTP secrets are stored AES-256-GCM-encrypted.
• Audit: Every MFA event (enrollment, verification success/failure, disablement, lockout) is recorded in a dedicated audit trail with IP address and user agent.
• Coverage: Available to all user categories (organization owners, administrators, operators) via self-service security settings; role-based mandatory enforcement for administrative users is on the near-term roadmap.

5) Audit, monitoring, and traceability

• Every NRS/FIRS API call is written to an immutable call-audit log with endpoint, status code, and response evidence; invoice processing returns trace IDs for support and reconciliation.
• Operational telemetry from both the API and the cockpit is shipped to a centralized sink (Axiom) for monitoring and investigation.
• Failed submissions are marked for retry with idempotent reconciliation (interrupted transmissions are resolved via status pull, never duplicated); an exceptions dashboard surfaces stuck invoices for operator review.
• Connector health, pipeline metrics, and recent failures are tracked with circuit-breaker state per external operation.

6) 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 CI-enforced dependency auditing on every merge, access reviews, and remediation tracking; customers are notified of material security issues per contractual terms.

7) 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.