Security

Assessed against OWASP ASVS 5.0 Level 2

ASVS is the application security standard from OWASP. Level 2 is the level intended for applications that process sensitive data. We have gone through all 253 requirements of Level 1 and 2 one by one and recorded, for each requirement, where it stands — and why.

Where we stand

222 of the 253 are settled or not applicable, with justification. The remaining 31 are listed by name in our register — including the reason.

These figures are derived from the register and checked at every release. So they cannot quietly go stale while the register changes.

What that means in practice

A standard is abstract. This is what it amounts to in practice:

• Separation between organisations

  All process, risk and master data queries pass through a tenant boundary that enforces the organisation and fails closed if that context is missing — a forgotten boundary produces an error, never someone else's data in silence. A user from one organisation cannot retrieve another organisation's data — not even with a guessed id.

• Roles and permissions on the server

  Who may do what is decided on the server, not in the browser. A reader cannot change any of the content — not even by conjuring a button back into view.

• Two-factor authentication

  Available through an authenticator app, with backup codes. We offer it and do not mandate it; that trade-off is justified in the register.

• Breached passwords are rejected

  When a password is set, we check it against the Have I Been Pwned database. If it appears there, it is not allowed.

• Rate-limited login paths

  The paths that handle credentials are rate-limited — and that limit lives in the database, not in the memory of a single process, so a restart or a second container does not reset it.

• Strict Content-Security-Policy

  With a nonce per page, so an injected script never runs.

• Sessions

  The session cookie is HttpOnly, Secure and SameSite. There is an absolute maximum lifetime, and sensitive actions ask for your password again.

• Audit trail and security logging

  Changes to your processes, roles, risks and controls are recorded with who, what and when. A denied authorisation is logged separately — a failed login is noise, but someone with a valid session attempting something they are not allowed to do is a signal.

• Supply chain

  We maintain an SBOM of the dependencies we run in production, and the pipeline automatically scans each change for accidentally committed secrets.

By chapter

The 17 chapters of the standard, with the state of play per chapter. The chapter titles are the names from the standard itself and we leave them untranslated — that way they can be looked up.

What is still open

We publish what is not finished too — otherwise transparency is just a marketing word. At the moment 10 requirements are open and 21 partial. The bulk of them are infrastructure requirements we have consciously accepted on the basis of our threat model, alongside a few policy choices that still call for a decision, one deviation that sits in a third-party library, and a remainder of hardening we have yet to finish ourselves. Every point is in the register with its reason — including the ones we want to close first.

And NIS2?

If your organisation falls under NIS2, you have to demonstrate a grip on your processes, your risks and your supply chain. Capturing exactly that is what Proceshuis is built for: processes, roles through RASCI, risks and controls in one system, with version history and an audit trail over that content showing who changed what and when.

The full register

All 253 requirements with the justification line by line, including the open points and why they are open. We share it on request: it contains implementation details that do not belong on a public page.