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 applied to tenant data as a further safeguard.
• Inbound quarantine: a bank statement whose account belongs to a different company is refused.
• Production hardening: the production service will not start with development keys, without authentication, or without encrypted database connections; production connections cannot point at bank test endpoints.
• Network controls: outbound connections to banks are validated against server-side request forgery (SSRF); 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 stops the connection.
• 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.

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; approval policies are versioned, and changes are subject to the controls described in the Documentation. A company can also require that the person who created a payment cannot approve it (maker-checker).
• Internal access: production access on a need-to-use basis and individually identifiable.

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 delayed payments.
• Documented and periodically exercised disaster-recovery procedures; encrypted off-site backups.
• A public status page for availability, incidents, and maintenance.
• Fault diagnostics: when the web portal fails in a customer's browser, the error and its technical stack trace are recorded so the fault can be traced to the record that caused it. These reports are access-controlled, not visible to customers or end users, and deleted automatically after a limited period.

6Secure development

• Type-checking, linting, and an extensive automated test suite, including live-database isolation tests, are part of our release process.
• A maintained threat model and a security-control matrix mapped to OWASP ASVS; recurring internal security audits with tracked remediation.
• Controlled management of software dependencies and supply-chain risk, including pinned versions and 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

• We do not hold external security certifications today. We may pursue certifications or external testing at our discretion. Summaries of our internal security assessments may be shared on request under confidentiality.

9Customer-side controls

Security is a shared responsibility. Customers must: 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.