Egenkontroll · Self-assessment
What an assessor
actually asks to see.
Article 21(2) names ten categories of measure. Most organisations can describe all ten and evidence about four. This is the artefact that settles each one — run it against your own estate before somebody else does.
- Measures
- Ten, (a)–(j)
- Applies to
- Essential & important entities
- Takes
- An afternoon, honestly done
- Costs
- Nothing
The gap that fails an assessment is rarely the measure itself. It is that the measure exists as a practice rather than as an artefact with a date on it. A nightly backup is not evidence of continuity; a restore test with a timestamp and a name against it is.
Work down the list. For each measure, the question is not “do we do this?” but “what would I hand over this afternoon if asked?” Anything you cannot produce in a day is the honest answer to where you are.
-
21(2)(a)
Risk analysis and information system security policies
Evidence to produce: The architecture document and threat model, dated, with the decisions and who took them.
How we deliver it: Architecture documented in the repository; the threat model and its decisions are written down and reviewable, not folklore
-
21(2)(b)
Incident handling
Evidence to produce: Runbooks, the alerting configuration, log retention period, and the record of a rehearsed on-call escalation.
How we deliver it: Monitoring, alerting and log retention specified up front, with runbooks in plain language and an on-call path that has been rehearsed
-
21(2)(c)
Business continuity, backup management, disaster recovery
Evidence to produce: A restore test report — not a backup report. The date, what was restored, how long it took, and who verified it.
How we deliver it: Nightly encrypted backups to a second European region, restore-tested monthly with the evidence sent to you; a machine is a file, so recovery is a rebuild rather than an archaeology exercise
-
21(2)(d)
Supply chain security
Evidence to produce: A dependency inventory you can produce on demand, with named upstreams and pinned versions.
How we deliver it: Open-source components with named upstreams, pinned by hash in Nix; a dependency set that can actually be enumerated, which is the part most estates cannot do
-
21(2)(e)
Security in acquisition, development and maintenance; vulnerability handling
Evidence to produce: Code review records, the build pipeline, and the elapsed time from a published CVE to it being patched in production.
How we deliver it: Everything through code review, reproducible builds, and a patch path that is a commit — so applying a fix is not a change-management project
-
21(2)(f)
Policies to assess the effectiveness of the measures
Evidence to produce: Evidence produced on a schedule: restore tests, CI checks, firewall rule reviews — with dates, not assurances.
How we deliver it: Restore tests, link and budget checks in CI, and firewall rules reviewed as code — measures that produce evidence on a schedule rather than on request
-
21(2)(g)
Cyber hygiene and training
Evidence to produce: Attendance and content of training, plus the handover pairing record for anyone operating the system.
How we deliver it: Handover pairing, written runbooks, and the hackathon and workshop practice we have run since 2015
-
21(2)(h)
Cryptography and encryption
Evidence to produce: The encryption inventory: what is encrypted in transit, at rest, with which algorithms, and who holds the keys.
How we deliver it: WireGuard between every site and host, TLS terminated by us, full-disk encryption on the laptops, keys held by you
-
21(2)(i)
Human resources security, access control, asset management
Evidence to produce: The access list, joiner-mover-leaver records, and an asset inventory that matches what is actually running.
How we deliver it: SSO against your directory, enforced 2FA, per-device revocation, and an asset inventory that is the Nix configuration itself
-
21(2)(j)
Multi-factor authentication and secured communications
Evidence to produce: Proof MFA is enforced rather than available, and that internal traffic does not traverse the public internet.
How we deliver it: MFA enforced on everything we deploy; internal traffic on a private mesh rather than the public internet
Run it and find gaps? That is the normal result, and the useful one. Send us the list — the first conversation is forty minutes and costs nothing, and we will tell you which gaps are technical and which are paperwork.
Talk it through