Policy Register

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 calledhardening standard, secure build standard
FamilyOperations and technology
Document typePolicy. 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 ownerThe head of IT operations.
Review cadenceAnnual (the register's default: the clauses say planned intervals and on significant change, and do not fix a period).
On the gap list whenISO 27001 is ticked and no line resolves to it (NIS2 requires it too, inside a parent document, so it does not list it separately).
TemplateConfiguration management policy.

Which standards require it, and what each expects it to contain

2 requiring clauses, 2 regimes

Shown 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 management

Establish, 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.

Evidence an auditor accepts: Documented secure configuration baselines per platform and service, and their basis such as a recognised benchmark; evidence baselines are implemented, sampled across live systems rather than assumed from the build image; automated compliance monitoring output showing conformance and drift, with the frequency of measurement
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 disclosure

Two 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.

Evidence an auditor accepts: Security requirements applied in procurement and in the development lifecycle, with gate evidence; secure development practices in use, such as design review, code analysis and dependency scanning, with output; change and maintenance control records for in-scope systems
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 register

Cloud security policy · Container and orchestration security standard