Auditing ISO 27001 Annex A 8.9 Configuration Management is the technical verification of hardened system states and automated enforcement protocols. The Primary Implementation Requirement is the establishment of secure configuration baselines, providing the Business Benefit of preventing unauthorised changes and maintaining infrastructure integrity across the enterprise.
ISO 27001 Annex A 8.9 Configuration Management Audit Checklist
This technical verification tool is designed for lead auditors to establish the security integrity and hardening of organisational infrastructure. Use this checklist to validate compliance with ISO 27001 Annex A 8.9.
1. Standard Security Configuration Baselines Verified
Verification Criteria: Formally documented security baselines (e.g. CIS Benchmarks or vendor-specific hardening guides) exist for all hardware, software, and cloud services.
Required Evidence: Hardening standards documents or “Gold Image” configuration specifications for OS, Database, and Network tiers.
Pass/Fail Test: If the organisation cannot produce a documented baseline for its primary operating systems or cloud environments, mark as Non-Compliant.
2. Baseline Enforcement and Automation Confirmed
Verification Criteria: Technical controls or automation tools (e.g. Ansible, Terraform, Intune GPOs) are utilised to enforce and maintain the established security baselines.
Required Evidence: Configuration-as-Code (CaC) repository logs or Group Policy Object (GPO) deployment reports showing baseline enforcement.
Pass/Fail Test: If security settings are applied manually without an automated enforcement mechanism for new deployments, mark as Non-Compliant.
3. Configuration Drift Monitoring and Alerting Validated
Verification Criteria: Active monitoring is in place to detect unauthorised changes or deviations from the approved security baselines (drift).
Required Evidence: File Integrity Monitoring (FIM) logs or Cloud Security Posture Management (CSPM) alert reports for drift detection.
Pass/Fail Test: If a configuration change occurs on a production server and no alert or log entry is generated to flag the baseline deviation, mark as Non-Compliant.
4. Hardening of Default Settings Verified
Verification Criteria: All default manufacturer settings that pose a security risk (e.g. default passwords, unnecessary services, or open ports) are disabled or modified.
Required Evidence: Build checklists or server audit logs showing the removal of “root/admin” defaults and deactivation of legacy protocols (e.g. Telnet, SMBv1).
Pass/Fail Test: If a sampled production asset is found running with factory-default credentials or unneeded pre-installed services, mark as Non-Compliant.
5. Least Privilege Service Account Configuration Confirmed
Verification Criteria: Service accounts and system-to-system credentials are configured with the minimum necessary permissions required to execute their specific function.
Required Evidence: IAM permissions report for service accounts or Kubernetes Role-Based Access Control (RBAC) YAML files.
Pass/Fail Test: If service accounts are found with “Domain Admin” or “Superuser” rights when only local file access was required, mark as Non-Compliant.
6. Secure Handling of Sensitive Configuration Data Validated
Verification Criteria: Sensitive configuration information, such as API keys, secrets, and private keys, is protected using dedicated secret management tools.
Required Evidence: Configuration logs from a Secret Manager (e.g. HashiCorp Vault, AWS Secrets Manager, or Azure Key Vault).
Pass/Fail Test: If secrets or private keys are found stored in plain-text within configuration files or public code repositories, mark as Non-Compliant.
7. Configuration Change Synchronisation with Change Management Verified
Verification Criteria: All configuration changes are linked to a formal change management request and authorised prior to implementation in production.
Required Evidence: Cross-reference between a technical configuration change log and an approved Change Request (CR) ticket in the ITSM tool.
Pass/Fail Test: If a significant production configuration change was made without an associated, approved Change Request, mark as Non-Compliant.
8. Periodic Configuration Baseline Audits Recorded
Verification Criteria: Management performs periodic audits of the configuration state to verify continued alignment with the ISMS requirements.
Required Evidence: Quarterly security configuration audit reports or vulnerability scanner “compliance” reports.
Pass/Fail Test: If there is no record of a formal configuration review or compliance scan being conducted in the last 6 months, mark as Non-Compliant.
9. Backup of Master Configuration Templates Confirmed
Verification Criteria: Master configuration files, templates, and “images” are securely backed up and protected against unauthorised modification or deletion.
Required Evidence: Backup logs for the Configuration Management Database (CMDB) or immutable storage settings for “Gold Images.”
Pass/Fail Test: If the loss of a configuration management server would result in the loss of all environment blueprints, mark as Non-Compliant.
10. Software Version and Vulnerability Alignment Verified
Verification Criteria: Configuration management ensures that only approved, secure versions of software are deployed, following the patch management cycle.
Required Evidence: Software inventory list showing version parity across the environment and absence of “End of Life” (EOL) versions.
Pass/Fail Test: If the configuration management system allows the deployment of software versions with known “Critical” vulnerabilities, mark as Non-Compliant.
| Control Requirement | The ‘Checkbox Compliance’ Trap | The Reality Check |
|---|---|---|
| Baseline Definition | Tool identifies “Hardening Policy” exists. | Verify the Technical Detail. A policy is just words; the auditor must see the actual CIS level 1 or 2 mapping. |
| Drift Detection | GRC dashboard reports “Config Management: Active”. | Verify Alerting. Does the tool actually flag a change to a local firewall rule, or just say the agent is “installed”? |
| Secrets Protection | Platform assumes “IAM” is secure. | Demand the Secret Scan. Many GRC tools miss hardcoded API keys in Terraform or Ansible scripts. |
| Automation | Tool records that “Terraform” is used. | Verify Enforcement. If “Manual Changes” are allowed in the Cloud Console without being overwritten by the code, automation is failed. |
| Default Settings | GRC tool identifies “Standard Build” is complete. | Verify Real Assets. Automated reports often hide local ‘admin’ accounts that exist on the underlying hardware nodes. |
| Review Cycle | Platform sets an “Annual Task” for review. | Check the Delta. Configuration drift happens in minutes. An annual review is a “checkbox” that ignores the 364 days of risk. |
| Documentation | Tool links to a “CMDB” spreadsheet. | Verify Sync. If the spreadsheet says 100 servers but the cloud console shows 120, the configuration management is failed. |
What is the objective of ISO 27001 Configuration Management?
The objective is to ensure that hardware, software, and services are configured and maintained according to documented security requirements, preventing unauthorised changes and ensuring consistent hardening levels.
How should configuration drift be monitored in a cloud environment?
Drift should be monitored using automated Cloud Security Posture Management (CSPM) tools or File Integrity Monitoring (FIM) systems that compare the live environment state against the approved “as-code” baseline.
Is automation mandatory for Annex A 8.9 compliance?
While the standard does not explicitly use the word “mandatory,” it requires effective configuration management. Given the complexity of modern systems, automation is the industry-standard method for ensuring baseline enforcement and drift detection.
About the author
