Self-assessment
Provability check: what can your system prove when it matters?
Ten questions taken from real audits, security questionnaires and incident reviews. You need no documents, only an honest assessment. The result appears right here.
The questions are deliberately binary. A “probably yes” counts as no in an audit because the evidence is missing — so the same strictness applies here.
For each question you can expand what requirement sits behind it and what is usually there instead.
Nothing is stored or transmitted. The result is computed in your browser and gone when you close the page.
0 of 10 questions answered
Your result
No open points yet — answer the questions to see your result.
This check replaces neither an audit nor legal advice. It reflects the questions we keep meeting in projects and audits. Which regulation applies to you specifically depends on your sector, size and role in the supply chain.
Answers that look good in a questionnaire
Four phrases appear in almost every security questionnaire. They are not wrong, and they are not meant to deceive. They quickly signal that the topic has been handled, and they lift the conversation to a procedural level where technical detail is not immediately required.
Against surface-level questions this works. It breaks on the targeted follow-up: “show me the state of this record on 14 March — and who held which permissions then.” That is exactly what this check asks about.
“We are ISO 27001 certified.”
ISO/IEC 27001 is the standard for an information security management system. It requires risks to be assessed systematically, controls to be defined and documented, and the whole thing to be audited regularly.
- Covers
- Documented policies for logging, access control and incident handling. Risk assessments, control catalogues, internal and external audits of the management system.
- Does not provide
- Any statement about how good the technical evidence in a specific system is. A certified company can still have mutable application logs, no point-in-time reconstruction, and need days to scope an incident. What is audited is the management system, not the ability to prove immutably what a record looked like on 14 March.
Leaves open: Questions 1, 2, 3, 7
“We have audit logs and a SIEM.”
Audit logs record who did what and when. A SIEM collects logs from many sources, correlates them and raises alerts — it supports detection and investigation of incidents.
- Covers
- Events are recorded. There is one central, searchable place. In many cases you can establish that something happened.
- Does not provide
- Immutability — most application audit logs sit in the same database as business data and are writable by admins and the application. Completeness of the chain including triggers. The point-in-time state of a business object, because a SIEM shows events, not states. The permission state from six months ago. And accessibility for the business side.
Leaves open: Questions 1, 2, 3, 5, 10
“Tenant isolation is implemented.”
Tenant isolation means one customer's data and actions are strictly separated from another's — in multi-tenant SaaS the central security promise.
- Covers
- Some form of separation exists, and the clear intention that tenants do not reach into each other.
- Does not provide
- The decisive distinction: enforced technically, or only through filter conditions in application code. If separation runs on `WHERE tenant_id = …`, one forgotten filter or one bug is enough. Real isolation — separate databases, row-level security at the database, policy enforcement outside the application — is rarer and more expensive. The word “implemented” hides exactly the how.
Leaves open: Question 4
“We have an incident response process.”
A documented flow for security and operational incidents: detection, containment, analysis, remediation, review — usually aligned with NIST or ISO/IEC 27035.
- Covers
- Roles, escalation paths, playbooks, communication plans. This satisfies the procedural side of NIS2 and DORA: procedures must exist.
- Does not provide
- The ability to scope quickly and provably. The process says analysis will happen. It does not guarantee you can name within 24 hours which tenants and records are affected. Without immutable history, fast queryability and permission history, analysis takes days — and the reporting clock runs regardless.
Leaves open: Questions 1, 5, 7
The reasoning behind these answers is understandable: you have the organisational building blocks that checklists ask for. The check instead asks about technical and organisational provability when it matters. Being able to say “yes, provable” early — and show it — is an advantage with customers in regulated sectors that cannot be argued away.
Questions about the check
- Are my answers stored?
- No. Everything runs in your browser. No answers are transmitted, stored or analysed.
- How reliable is the result?
- It is a self-assessment, not an audit. The value lies in walking through the right questions once — most gaps end up named instead of vague.
- What if I answer “unclear” several times?
- That is a finding in itself. In an audit, “unclear” means the evidence is not available when asked — which is why we count it as an open point.
- Isn't ISO 27001 certification enough?
- It evidences a working information security management system — policies, risk assessment, audit cycle. It says nothing about whether your system can immutably reconstruct the state of a record on a given day. Both are useful, but they answer different questions.
- Does this apply to us if we are not directly regulated?
- Usually yes, but indirectly. As soon as a customer falls under NIS2, DORA or the AI Act, they pass the requirements on to you through security questionnaires, data processing agreements and supplier assessments. The trigger is then not an auditor but a deal.
Want to talk the result through?
Describe your situation in a few sentences. You get an assessment of whether and where a cut pays off — and when it does not.