The ultimate audit guide to ISO 27001 Annex A 8.9 Configuration Management
Table of contents
- 1. Standard Security Configuration Baselines Verified
- 2. Baseline Enforcement and Automation Confirmed
- 3. Configuration Drift Monitoring and Alerting Validated
- 4. Hardening of Default Settings Verified
- 5. Least Privilege Service Account Configuration Confirmed
- 6. Secure Handling of Sensitive Configuration Data Validated
- 7. Configuration Change Synchronisation with Change Management Verified
- 8. Periodic Configuration Baseline Audits Recorded
- 9. Backup of Master Configuration Templates Confirmed
- 10. Software Version and Vulnerability Alignment Verified
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.
About the author
