DigiD assessment checklist: the 21 norms and what you need ready for each

The DigiD assessment tests against the Normenkader 3.0: 21 security guidelines selected from the ICT Security Guidelines for Web Applications issued by the Dutch National Cyber Security Centre and adopted by the Ministry of the Interior in consultation with Logius, the Central Government Audit Service and the NCSC. This checklist walks through the norm groups with, per group, the question that matters in practice: what evidence could you put on the table today?

First: design, existence and operating effectiveness

For a new connection, all 21 norms are tested on design and existence. Is it arranged, and does it actually exist?

For an existing connection, five norms are additionally tested on operating effectiveness: U/TV.01 (identity and access means), U/WA.02 (web application management), C.07 (monitoring of logging and detection), C.08 (change management) and C.09 (patch management).

That distinction drives your preparation. For operating effectiveness a procedure is not enough: you have to show over a period that the process was actually executed. Think of a sample of changes with approval and testing, patch reports covering several months, and records of alerts that were followed up. Anyone who picks up these five a month before the assessment simply has no history to show.

Policy and outsourcing

B.01 requires an information security policy that explicitly addresses web applications, covering topics such as data classification, access provisioning and vulnerability management. A general policy without those specific sections produces a finding.

B.05 covers outsourcing. If a third party builds or manages the web application, the security requirements must be recorded in the contract and established at the appropriate level. Check whether your contract contains those requirements and whether they align with the norms for which that party supplies the evidence. A data processing agreement does not cover this.

Access and management

U/TV.01 covers identity and access means: reliably establishing who someone is, assigning rights, making usage verifiable. Make sure you have a current overview of accounts and rights, that your periodic review is demonstrable, and that offboarding demonstrably leads to revocation. This norm is tested on operating effectiveness.

U/WA.02 requires web application management to be organised as a process, with authorised administrators working on the basis of role profiles. Record who holds which administrative role and what that assignment is based on. This norm is also tested on operating effectiveness.

The web application itself

U/WA.03 and U/WA.04 cover input and output: normalising and validating input before processing it, and limiting output to values that can be processed safely. In practice this means being able to show how your application handles injection and cross-site scripting, not just that a framework catches it by default.

U/WA.05 covers cryptographic and privacy-enhancing techniques. Record which algorithms and key lengths you use, where data is stored and transmitted encrypted, and how key management is arranged.

Web server and platform

U/PW.02, U/PW.03, U/PW.05 and U/PW.07 concern the server side: the protocol characteristics the web server enforces, configuration according to a baseline, management through secure protocols in line with operational policy, and a hardening guideline for configuring platforms.

The evidence here comes in two layers. You need the guideline or baseline as a document, and you must be able to demonstrate that the running systems comply with it. A baseline without verification against the actual configuration is the most common finding in this group.

Network

U/NW.03 requires separation into physical and logical zones, with a DMZ between the internal network and the internet. U/NW.04 covers protection and detection mechanisms for network components and traffic. U/NW.05 requires management traffic and production traffic within the production environment to be segregated. U/NW.06 requires a hardening guideline for networks.

Make sure you have a current network diagram showing the zones, the DMZ and the management paths. That diagram is often the first thing an auditor asks for and often the first thing that turns out to be outdated.

Scans and penetration tests

C.03 requires vulnerability assessments to be performed as a process on the ICT components within scope. C.04 requires the same for penetration tests on the infrastructure of the web application, supported by guidelines.

Two things go wrong here. First, the test does not cover the full scope, for example because an interface or the management environment fell outside the engagement. Second, findings were remediated but never retested, leaving you unable to demonstrate the fix. Schedule the test well before the deadline, with room for remediation and a retest.

Logging, monitoring and detection

C.06 requires signalling functions in the web application environment to be active and securely configured. C.07 requires logging and detection information to be monitored regularly and findings to be reported. That last one is tested on operating effectiveness.

For C.07 you therefore need more than a SIEM licence. Show which alerting rules exist, which alerts fired in the past period, what was done with them and where that is recorded. A log file nobody reads does not meet the norm.

Change management and patch management

C.08 requires changes to be implemented in a timely, authorised and tested manner. C.09 requires security patches to be installed in good time, supported by guidelines. Both are tested on operating effectiveness.

Prepare a sample for these: a number of changes from the period with request, approval, test evidence and deployment, plus patch reports showing how quickly patches were rolled out after publication. Define your own deadline and stick to it, because the auditor tests against your norm.

When to start

Count back from the date the report must be with Logius. The five norms with an operating effectiveness test require history, so those processes must already have been running for months. Schedule the penetration test so that remediation and a retest fit. Ask chain partners for their assurance first, because that usually has the longest lead time.

Source: Logius, Normenkader 3.0 for DigiD ICT security assessments: https://www.logius.nl/onze-dienstverlening/toegang/digid/ict-beveiligingsassessments-digid/documentatie/norm-ict-beveiligingsassessments-digid

Secure Audit performs DigiD assessments and supports organisations in preparing for them. Get in touch for a baseline measurement against the 21 norms.