Where every control actually stands today.
This is the honest ledger. Each row is the true current state from a code-level review — implemented, partial, planned, inherited, or not applicable — with the exact claim we allow ourselves to make. Security status is separate from service uptime; both are below.
Active security incidents
| Date | Severity | Component | Status |
|---|---|---|---|
| None. No active security incident is affecting PayHQ. | |||
Vulnerability advisory history
| Date | Severity (CVSS) | Component | Advisory |
|---|---|---|---|
| None published. Report a suspected vulnerability via our disclosure policy. | |||
Controls posture
The “State” column is deliberately blunt. A partial or planned control links to the roadmap item that closes it. We will not describe a control as more complete than the code makes it.
| Control | State | What we say |
|---|---|---|
| No third-party AI, OCR, or model training on your data | Implemented | Invoice extraction runs on OCR and language models we host ourselves; invoice content is not sent to any third-party AI, OCR, or analytics service, and no model is trained on your data. The worker enforces this in code — it fails closed unless the OCR/LLM endpoint is self-hosted or on the operator's explicit allowlist, and in our own deployment that allowlist contains only self-hosted hosts. |
| Uploaded invoice documents encrypted at rest | Implemented | Uploaded invoice documents are encrypted at rest with AES-256-GCM (per-object nonce, object-key-bound AAD). |
| Structured supplier bank details are not yet column-encrypted (R-CRYPTO-02) | Partial | Structured supplier bank details are stored in our EU database but are not yet encrypted at the column level; database-column encryption is on the roadmap. We do not claim blanket 'data encrypted at rest'. |
| Traffic to PayHQ encrypted in transit | Implemented | All traffic to PayHQ is encrypted in transit using TLS 1.2/1.3, terminated at the edge and the application ingress. |
| Internal service-to-service TLS (R-CRYPTO-01) | Partial | Internal traffic between the application, database, and object storage currently runs unencrypted on an isolated single host; enabling internal TLS is on the roadmap. We disclose this rather than imply end-to-end encryption everywhere. |
| Bank details masked by default; reveal permission-gated and logged (R-ACCESS-01) | Partial | The supplier registry and the invoice-detail view mask bank details by default at the API; cleartext reveal is permission-gated and every reveal is recorded in the audit trail. One API surface — the read-results endpoint of the API-key integration API — is still being brought under the same server-side masking. |
| Workspace / tenant isolation (R-TENANT-01) | Partial | Each workspace is isolated; records never cross workspace boundaries. Isolation is enforced at the application and query layer with workspace-scoped composite foreign keys. There is no database-level row-level-security backstop today. |
| Audit trail for supplier, reveal, review, and approval actions (R-AUDIT-01) | Partial | Supplier changes, reveals, reviews, and approvals are recorded in an audit trail. The trail is not yet tamper-evident, and read/authentication events are not yet recorded — cryptographic tamper-evidence is on the roadmap. |
| MFA and SSO (R-AUTH-01) | Planned | Multi-factor authentication and SSO are not available today and are on the roadmap, gated on production launch and enterprise demand. |
| Password hashing | Implemented | Account passwords are hashed with Argon2id. |
| Automated backups and disaster recovery (R-BCP-01) | Planned | Automated, encrypted, off-site backups with a tested restore are on the roadmap and not yet in place; we do not publish an RPO or RTO. A manual database export procedure is documented. |
| ISO 27001 / SOC 2 / penetration test (R-CERT-01) | Planned | PayHQ is not certified to any standard, and no independent penetration test has been performed yet. ISO 27001 readiness work is underway as a forward-looking effort; SOC 2 is gated on first US enterprise demand. |
| Data residency | Implemented | Customer data is stored in the EU with Hetzner in Finland (Helsinki, HEL1-DC8). Beyond the always-on Cloudflare edge, a couple of opt-in paths (Resend inbound and the Telegram intake bot) can carry invoice content outside the EU when a workspace enables them, as can a connected Microsoft 365 mailbox where an operator enables it; a Google/Gmail connector is a planned path. All are named on our sub-processor list, rather than claiming data 'never leaves the EU'. |
| PCI DSS scope | Not applicable | PCI DSS does not apply to PayHQ: we process bank-account identifiers for supplier payments, never cardholder data. |
| Payment-services regulation (PSD2 / FCA) | Not applicable | PayHQ is not a payment service provider. We never initiate, hold, or move funds — we verify and flag before a customer's own payment. FCA authorisation is not required for the current product. |
| Physical and environmental security | Inherited | Physical and environmental controls for our infrastructure are inherited from our hosting provider, Hetzner, at its ISO 27001-certified Finnish datacentre. |
| Published security contact and disclosure policy | Implemented | We publish a machine-readable security contact (RFC 9116 security.txt) and a Coordinated Vulnerability Disclosure policy. |
Service availability
PayHQ is pre-production pilot software. We do not publish an uptime SLA, an RPO, or an RTO, and availability commitments apply only under a contracted engagement. This is a separate question from the security posture above — we keep the two apart on purpose.