Configuration management policy
The secure baseline for each class of system, how it is applied, checked for drift and changed.
How the register reads it
| Also called | hardening standard, secure build standard |
|---|---|
| Family | Operations and technology |
| Document type | Policy. The regimes ask for the content, not the label; a line pasted as a standard, procedure, plan or schedule is placed here with the label noted. |
| Expected owner | The head of IT operations. |
| Review cadence | Annual (the register's default: the clauses say planned intervals and on significant change, and do not fix a period). |
| On the gap list when | ISO 27001 is ticked and no line resolves to it (NIS2 requires it too, inside a parent document, so it does not list it separately). |
| Template | Configuration management policy. |
Which standards require it, and what each expects it to contain
2 requiring clauses, 2 regimesShown on a register for the regimes you tick; with none ticked, ISO 27001 is applied. Requirement text drawn from a human-verified compliance corpus under licence: the corpus statement of each clause, not the instrument verbatim.
ISO/IEC 27001:2022
ISO 27001 8.9 Configuration managementEstablish, document, implement, monitor and review secure configurations for hardware, software, services and networks.
What the ISO 27002 guidance expects the document to say: Requires configurations of hardware, software, services and networks, including their security configurations, to be established, documented, implemented, monitored and reviewed. Supporting material frames this as a standing process that keeps systems configured securely and consistently.
Common gap: outdated baselines
Source: ISO/IEC 27001:2022; guidance ISO/IEC 27002:2022
The NIS2 Directive
NIS2 Art. 21(2)(e) Security in acquisition, development and maintenance, including vulnerability handling and disclosureTwo duties travel together in this point. The first is that security is built into how systems are acquired, developed and maintained: security requirements set before purchase or build, secure development practice, change control, and maintenance that does not quietly reintroduce weakness. The second is vulnerability handling and disclosure, meaning the entity can receive a vulnerability report about its own products or systems, triage it, fix it on a timescale that reflects severity, and handle disclosure. A published route for a finder to reach the entity is the part most often missing, and its absence is visible from outside. Note that the coordinator role and the European vulnerability database in Article 12 belong to the CSIRTs and ENISA; what binds the entity is its own handling and disclosure capability.
Common gap: Security requirements defined for new build only, leaving acquired and inherited systems untouched
Source: NIS2 Directive
Do this for every document on your list
Paste the list and get this reading for every document at once, with the owner and cadence against each, the clauses quoted, and the documents the regimes expect that the list does not carry. Eight documents free, no account.
Build a registerCloud security policy · Container and orchestration security standard