Security Policy

1Architecture and isolation

• Tenant isolation at three layers: every request is bound to the authenticated principal's platform/company scope (never to identifiers in the request body); every query is scope-filtered; and PostgreSQL Row-Level Security is enforced on all tenant tables, so a query outside a tenant scope returns nothing.
• Inbound quarantine: a bank statement whose account belongs to a different company is refused.
• Production hardening: production mode fails closed: the service refuses to start with development keys, open authentication, or plaintext database transport; production connections cannot point at bank test endpoints.
• Network controls: outbound connections to banks are validated against SSRF guards; inbound files are size-capped, format-validated, and parsed with hardened parsers.

2Encryption and key custody

• In transit: TLS 1.2+ for all external traffic, including database connections.
• At rest: field-level AES-256-GCM encryption of payment payloads, bank-connection credentials and key material, and approver identity data; ciphertexts are key-identifier-tagged to support rotation.
• Bank channel security: payment files are signed and encrypted per channel requirements (e.g. PGP for SFTP, XML-DSig for web services, EBICS signatures); bank host keys, certificates, and published keys are pinned and verified, and a mismatch fails closed.
• Key custody: bank-connection key material is generated and stored server-side, encrypted at rest, used solely to operate the owning company's bank connections, and destroyed on wind-down completion. Migration of key custody to a dedicated KMS/HSM is planned.

3Access control and authentication

• Roles: admin, approver, viewer, plus a separate workspace administrator; least-privilege by design.
• Authentication: httpOnly session cookies with CSRF protection; login throttling and lockout; TOTP multi-factor authentication available for login and as approval step-up.
• Approvals: release of a payment file requires approval under the company's policy (maker-checker); approval policies are versioned and immutable, changed only by dual co-signature of two distinct administrators.
• Internal access: production access on a need-to-use basis, individually identifiable, with confidentiality undertakings.

4Integrity and auditability

• Tamper-evident audit trail: a per-company hash-chained activity log, verifiable on demand through the service.
• Idempotency: duplicate-payment protection via idempotency keys.
• Journal: every payment and imported statement is journaled with lifecycle status.

5Operations and continuity

• Monitoring, metrics, and alerting on service health, job queues, and stuck payments.
• Documented and periodically exercised disaster-recovery procedures; encrypted off-site backups.
• Horizontal-scaling-ready architecture with safe concurrent processing (advisory locks, atomic claims).
• A public status page for availability, incidents, and maintenance.

6Secure development

• Mandatory type-checking, linting, and an extensive automated test suite (including live-database isolation tests) gate every change.
• A maintained threat model and a security-control matrix mapped to OWASP ASVS; recurring internal security audits with tracked remediation.
• Dependency and supply-chain hygiene (lockfiles, reviewed upgrades).

7Incident response

• Security incidents are triaged by severity with documented response procedures.
• Personal-data breaches: we notify affected customers without undue delay, and in any case within 48 hours of becoming aware, as set out in the DPA, with ongoing updates until resolution.
• Post-incident reviews feed back into controls and tests.

8Certifications and assurance

• Planned: SOC 2 examination, ISO 27001 certification, and recurring external penetration testing. Reports will be available on request under NDA once achieved. Until then, summaries of our internal security assessments are available on request.

9Customer-side controls

Security is shared. Customers are expected to: enforce MFA for administrators and approvers; use role separation and approval policies appropriate to their risk; protect API keys and rotate them on suspicion of compromise; verify webhook signatures; keep user lists current and disable departed personnel promptly; and report suspected compromise without undue delay.