EvidenceSheet

8.9 Configuration management

The organization is to set, record, apply, watch and review how its hardware, software, services and networks are configured, security settings included. Purpose: keep hardware, software, services and networks working correctly with the security settings they need, and keep settings from being altered without approval or by mistake. Guidance: define and run processes and tools that enforce defined configurations for hardware, software, services such as cloud services, and networks, both on new installations and through the life of operational systems, with roles, responsibilities and procedures that keep every configuration change under control. Standard secure configuration templates should draw on public guidance such as vendor and independent security organization baselines, reflect the protection level needed, support the organization's policies and standards, and be feasible in its context; review them periodically and update them for new threats, vulnerabilities or new software and hardware versions. Templates should consider: keeping the number of privileged or administrator identities low; disabling unnecessary, unused or insecure identities; disabling or restricting unneeded functions and services; restricting access to powerful utilities and host parameters; clock synchronization; changing vendor default credentials immediately after installation and reviewing other security-relevant defaults; inactivity timeouts that log devices off; and checking licence compliance (5.32). Managing: record established configurations and log every change, stored securely, for example in a configuration database or templates, with changes going through change management (8.32); records can hold the current owner or contact, date of last change, template version and links to related assets' configurations. Monitoring: use a broad range of system management tooling (maintenance utilities, remote support, enterprise management, backup and restore) and review regularly to check settings, evaluate password strength and assess activity; compare actual settings with target templates and correct deviations by automatic enforcement or by manual analysis and corrective action. Other information: system documentation often holds configuration detail; hardening is part of configuration management; it can be joined with asset management; automation such as infrastructure as code is usually more effective; templates and targets can be confidential and should be protected.

Source: ISO/IEC 27002:2022, 8.9. The statement above is our statement of the clause, read from the published text and cited so you can check it against the official text, not the instrument verbatim. Open ISO/IEC 27002:2022 in the compliance library.

ISO/IEC 27002 is guidance on the Annex A controls; certification is against ISO/IEC 27001. Use this set when your sheet follows the 27002 numbering.

6
artefacts
4
held by a system
1
at each review
easy
to go live
Vendor register / contract repository
where the evidence lives
teal = a system already holds it · olive = produced at each review. To go live: easy when half or more of the artefacts are already held by a system, moderate from a quarter to a half, hard below a quarter.

These are the artefacts auditors commonly ask for on this requirement, our guidance rather than text from the standard. Your assessor decides what is sufficient in your context, and asks for samples across the period when a report covers one.

system holds itEvidence a system already holds

  • Approved secure configuration templates or baselines for each platform, derived from vendor or independent guidance, with review dates · Vendor register / contract repository
  • Configuration records or a CMDB showing owner, last change date, template version and relationships between assets · Cloud console / configuration management
  • Change records showing configuration changes passed through change management · Ticketing / ITSM
  • Configuration compliance scan results comparing actual settings with templates, and records of deviations corrected · Vulnerability scanner / patch tooling

periodic reviewEvidence produced at each review

  • Evidence of default credentials changed, unnecessary services disabled and inactivity timeouts set · Identity provider / directory

governing documentDocuments that govern the control

  • Infrastructure as code repositories or automated enforcement tooling, with access restricted to protect the templates · Policy repository / GRC workspace

First move

Automate the pull from your Vendor register / contract repository. Vendor register with review dates and attached assurance reports; expiry-driven reminders, not an annual scramble.

Common gaps auditors find

Do this for your whole sheet

Paste the rows you run your controls from and get this mapping for every control at once, with the periodic-review ones flagged and a first move per row. No account for the first run.

Build my evidence sheet

8.8 Management of technical vulnerabilities · 8.10 Information deletion