← Back

Trust & Security

What Pensius actually does today for data protection, access control, and tenant isolation, and what's honestly still on the roadmap. Every status below is literal: live means shipped and true right now, planned means it isn't yet. Last reviewed 12-10-2026.

Certifications

No third-party certifications exist yet, shown honestly rather than implied.

Planned

SOC 2 Type II

Not started. Realistic sequencing: technical controls first (this page tracks them), then an audit engagement. See the roadmap below.

Planned

ISO 27001

Not started. Would run in parallel with SOC 2 once the ISMS groundwork (policies, risk register, vendor management) begins.

Planned

Penetration test

No third-party pen test has been performed yet. A self-review against the OWASP Top 10 is part of every build wave; that is a development practice, not a substitute for an independent test.

Data protection

Live

Encryption in transit

TLS is enforced at the network edge for every deployment (the demo instances run behind Cloudflare Tunnel, which terminates TLS 1.2+; a production deployment terminates TLS at its own load balancer/ingress).

Live

Encryption at rest

Document files are encrypted at rest with a key derived per organisation, so one tenant's key cannot open another's papers, and each document is served only after its stored bytes are re-checked against the SHA-256 it was registered with. Sensitive columns (second-factor secrets, integration signing secrets, and the tax identifiers of clients and funds) use application-level column encryption, and so does the confirmed read-out of an uploaded paper, which holds the identifiers printed on it. Every encrypted value and document that the current version writes names the key that sealed it, by a fingerprint and never the key itself. Values and documents stored by an earlier version name no key until they are written again, and open with the key in force. Identifiers and read-outs that an earlier version stored in the clear are encrypted when this version first starts, once the server has shown that it holds that database's own keys. Names and amounts are not encrypted in the application: they are searched and summed in the database, and rest on tenant isolation and on the full disk/volume encryption the hosting platform provides. Losing the encryption key loses the encrypted values, so it is backed up apart from the database. Key rotation and a managed key service are roadmap items.

Live

Backups

Automatic daily backups today (SQLite file snapshot, 30-day retention). Point-in-time recovery and a tested restore drill are roadmap items for the Postgres cutover.

Live

Secrets management

The application secret is required from a secrets manager/env var in production mode (the app refuses to start without one). It no longer signs sessions (a session is a random token checked on the server): it signs only the short-lived second-factor and password-change tickets, and unless separate keys are supplied, the encryption and audit-chain keys are derived from it. A dedicated secrets-manager integration (KMS/Vault) is a roadmap item.

Access control & tenant isolation

Live

Authentication

First-party password auth (Argon2id hashing), account lockout after repeated failures, HttpOnly session cookies scoped to HTTPS. Each organisation sets one password rule, checked wherever a password is chosen: at least 12 characters (15 for administrators), not one of the most common passwords and not the person's own name, optionally with upper and lower case, a digit and a symbol, or 15 characters for everyone. Passwords can be set to expire after 90, 180 or 365 days (off unless an administrator turns it on); an expired password must be changed before anything else opens. Staff and client-portal accounts change their own password, which signs out their other browsers. An administrator never sets or sees a password: a reset clears it, ends every session and hands out a one-time link to choose a new one. Only that link can set it, and an account with two-step verification still gives its code afterwards. Before anyone signs in, the sign-in and password screens say that only authorised use, for the work the organisation has approved, is allowed, and that every sign-in and action is recorded. SSO (SAML 2.0 / OIDC) is on the roadmap for enterprise buyers.

Live

Sessions

Every sign-in is a session held on the server. The browser's cookie carries only a random token, and the server keeps a hash of it, so a copy of the database signs nobody in. A session ends after 15 minutes without activity (an administrator can set 10 or 5, never more than 15) and after 12 hours whatever happens; a screen left alone warns a minute before and then signs itself out. Signing out ends the session on the server, anyone can sign out on every browser at once, an administrator can end an account's sessions, a new or reset password and a deactivation end them all, and a change to two-step verification ends all but the one that made it. Only a count of browsers is shown: no IP address or browser details are kept.

Live

Role-based access control

Named permissions (not just role strings) gate every sensitive route: admin actions, business-rule changes, period close, exports, integrations. A new account starts with no role and sees nothing until an administrator gives it one. Every grant that widens access (a role, a single permission, an external consultant's case) needs a reason, kept with who gave it and when, on the account and on both audit trails. Administrators keep an access matrix read from the enforced rights: every account type and every active account against every permission, exceptions and their reasons, which grants have none, and who must use two-step verification. It downloads as a CSV and is confirmed on a cycle the organisation sets (quarterly by default); each confirmation is recorded on both trails, and the screen says when access has changed since. A full per-action permission catalogue (beyond today's coarse set) is in progress.

Live

Document classification

Every document carries a confidentiality label from one scale (Public, Internal, Confidential, Restricted). The label follows from the document's type the moment it arrives, under a rule each organisation sets, and can be changed on one document with a reason; only an administrator can lower it. The label is enforced where a document's content is served: Confidential and Restricted open only for accounts that hold the matching permission, and a paper is gated at the strictest label any of its versions carries, so a replaced version does not stay open at an older level. The client portal and external consultants are never shown or served a Restricted document. A Restricted document is never placed in a ZIP or a report bundle, a Confidential one only for an account that may open it, and the access record and the bundle's manifest say how many documents were kept out. A saved bundle is checked again when it is fetched: it opens only for an account that opens the strictest document inside it, whoever built it, and a bundle saved before bundles carried that level is handled as Restricted. Every open of a Restricted document is recorded on the security trail, each time. The full data export is the one copy that carries every document, Restricted included: it is made only by an administrator whose own account opens every document in it, and its record on both trails says how many Confidential and Restricted documents left. Not covered: retention periods follow the document type, not the label; file names stay visible in lists; and the rendered pages and sheets inside a bundle are not classified, only the documents are.

Live

API keys: expiry and rotation

The read API is opened with tokens an administrator issues. A token is stored as a hash, bound to one tenant and one account, and stops working when that account loses read access. Every token carries an end date from the day it is made: ninety days at most, shorter if the organisation sets it so. A token is replaced by rotating it: the successor is shown once and the old one keeps working for seven days at most, so the consuming system can switch without a gap; revoking ends a token at once. Administrators are told before a token ends, when one ends without that warning, and when one has not been used for thirty days. Issuing, rotating, revoking and expiry are on the security trail with the token's own id. Not built: scopes per endpoint, restriction by caller address, and client certificates; the last two depend on the hosting choice.

Live

Tenant data isolation

Every tenant-owned table carries an organization id; an ORM-level row-security layer auto-filters every query and auto-stamps every write by the signed-in user's organization, failing closed when no tenant is bound, proven by an automated cross-tenant test matrix. On Postgres this is backstopped at the database by row-level security: the app connects as a non-superuser role under policies that return nothing for an unbound request, so even a query that forgot to scope sees no other tenant's data.

Live

Audit trail

Every business mutation (cases, cheques, allocations, period close) is written to an insert-only audit log whose links are keyed (HMAC-SHA256) under a key held outside the database, so an edit cannot be covered up by recomputing the chain. Signed anchors of the chain tip can be exported and held elsewhere, which is what proves nothing was cut off the end. A SEPARATE chained log covers security events (logins, lockouts, password changes, API-token issuance) distinct from the business chain, together with the access log: who opened a document, a case or a client file, every export and every look at a log. How long that security log is kept is an administrator's setting (everything, or 90, 180 or 365 days); once a period is set, its oldest part is removed daily under a signed retention cut, so the trail still proves nothing else was taken out. The business trail is never removed: it is the financial record.

Live

Two-step verification

Every account can add a second factor (TOTP, checked on this system; no external service). An organization can require one per role: administrators, or administrators and the tax team. Someone without it reaches only their own security page until they set it up. Federated sign-in (SSO/SCIM) is on the roadmap.

Live

CSRF / rate limiting

Origin-header verification on every state-changing request. The sign-in and account forms allow a fixed number of attempts per address in five minutes, counted in the database so the number is the same on every server process; an address is kept there only as a keyed digest, and rows past those five minutes are swept out every quarter of an hour. A general per-address request limit applies to everything else.

Subprocessors

The complete, current list, updated whenever it changes.

Live

Cloudflare · Network edge / tunnel (TLS termination, DDoS protection)

Encrypted traffic only. Cloudflare does not have access to application data or the database.

Data handling

No OCR or LLM-based document extraction is enabled by default. The pluggable document-reading seam stays off until a customer explicitly supplies a provider and a data-handling policy (see docs/BACKLOG.md).
No customer data is used to train any model.
Uploaded documents are validated by content (magic-byte sniffing), not just file extension, before storage.
Deleting a document's content takes two people: an administrator asks, with a reason, and a second, different person approves. It can then be restored by an administrator for a period the organisation sets (30 days by default, at least 7); after that the file leaves the store on its own, unless a legal hold placed in the meantime keeps it. Every step is on both audit trails.
Deleting a refund case or a compliance case takes two people as well: a member of the tax team asks, with a reason, and a second, different person approves; one of the two is an administrator. A case that holds cheques, withholding lines, comments or carry-forward entries, or that sits in a locked period, is a record and cannot be deleted at all. An approved deletion removes the case and everything that belongs to it and keeps every one of its documents: in the archive, or in use on another case that still holds it. An administrator can restore the case for the same period, as it was. After that it is final. Every step is on both audit trails.

Hosting

The product is designed to be deployed in the customer's or a vendor's EU region (Postgres-ready, containerization-ready). Today's live demo instances run from a single non-production host for evaluation purposes only. No real customer data is ever placed in a demo instance.

Data portability & exit

A one-click "export everything" package (Periods & reports → Full data export, admin-only): every record this organization owns: clients, funds, cases, cheques, allocations, the carry-forward ledger, both hash-chained audit trails in full with their chain hashes, and the original bytes of every uploaded document, in one ZIP, in open, non-proprietary formats (CSV + the original files). Also available: the existing CSV export (Allocation dataset → Export CSV) and the read API (docs/API.md) for integrating with your own systems on an ongoing basis.

Need the full documentation?

Security questionnaire responses, a DPA, or details beyond this page, available on request.

Request docs →

This page describes the Pensius product and its default configuration. A specific deployment's actual posture (hosting region, certifications in progress, DPA terms) is confirmed in writing as part of a commercial agreement, not by this page alone.