ISO 27001 Configuration Management
ISO 27001 Annex A 8.9 Configuration Management is an ISO 27001 control that looks to make sure you have configured software and hardware, documented it and are monitoring and reviewing it.
The focus for this ISO 27001 Annex A Control is having standard, secure, configurations for software and hardware. As one of the ISO 27001 controls this is about having configurations in place and managing them.
Table of contents
- ISO 27001 Configuration Management
- Key Takeaways
- Purpose
- Definition
- Explanation
- Requirement
- Audit Focus
- FREE Training Video
- Document Configuration Management
- What to document
- Configuration Changes
- Configuration Monitoring and Review
- Standard Build Checklist
- How to implement it
- How to pass the ISO 27001
- Top 3 mistakes and how to avoid them
- Applicability across different business models
- FAQ
- Related ISO 27001 Controls
- Further Reading
- Controls and Attribute Values
- About the author
Key Takeaways
ISO 27001 Annex A 8.9 is a new control in the 2022 update. It requires organizations to establish, document, and manage the technical configurations (the “Standard Build”) of their hardware, software, and services. The goal is to ensure that systems are “hardened” by default, preventing security incidents caused by unpatched services, default passwords, or open ports.
Purpose
The purpose of Annex A 8.9 Configuration Management is to ensure hardware, software, services and networks function correctly with required security settings, and configuration is not altered by unauthorised or incorrect changes.
Definition
The ISO 27001 standard defines Annex A 8.9 as:
Configurations, including security configurations, of hardware, software, services and networks should be established, documented, implemented, monitored and reviewed.
ISO 27001:2022 Annex A 8.9 Configuration Management
Explanation
ISO 27001 Annex A 8.9 is a security control that requires organizations to define and maintain secure configuration baselines for all hardware, software, services, and networks. By enforcing documented standards and monitoring for unauthorized changes (configuration drift), this control ensures systems are “hardened” by default, preventing vulnerabilities caused by default settings or unpatched services.
ISO 27001 Annex A 8.9 is about configuration management which means you need to document and implement the technical configurations of systems and software.
Requirement
- Standard Build Templates: You must define exactly what a “secure” device looks like before it is given to a user. This includes disabling unused services, enforcing auto-lock, and removing default manufacturer passwords.
- Avoid “Configuration Drift”: Once a system is live, its settings can change. You must monitor your systems to ensure they haven’t “drifted” away from your secure baseline (e.g., a developer temporarily opening a port and forgetting to close it).
- Integration with Change Management: Any change to a critical configuration must be authorized. You shouldn’t tweak firewall rules or server settings without a record of who authorized it and why.
- Use of Industry Benchmarks: Rather than guessing, the standard encourages using recognized standards like CIS Benchmarks or NIST guidelines to define your secure configurations.
Audit Focus
- Documentation: “Show me the standard build checklist for a new company laptop.”
- Verification: They will perform a “spot check” on a random device: “Show me that ‘Guest Accounts’ are disabled on this machine, as per your policy.”
- Governance: “Show me the last time you reviewed your cloud (AWS/Azure) configurations for security gaps.”
FREE Training Video
In this free training video you will learn How to implement ISO 27001 Configuration Management (Annex A 8.9) and Pass Your Audit.
Document Configuration Management
My advice when starting out with configuration management is document before you implement, if you can. Work out what your secure configurations should be based on vendor advice, industry best practice and your own needs. It may that you can’t as you already have an environment in place and you are trying to retro fit, but if you can do it first, do it first.
We know when we purchase hardware and software that it just comes with the standard default set up. Clearly it has to be this way as they cannot account for every use case. This can include default passwords and things should be locked down and closed being left open.
To document it, if you can, get your hand on vendor or industry templates for the thing you are trying to secure. Sure, the actual configuration set up itself can be enough, but for belts and braces documenting it in templates allows a couple of other things to happen. It enables the change management cycle which includes the processes and steps for authorisation. With documentation you can show previous states and evidence that changes to configuration were effectively managed.
What to document
What kind of things can you consider in your templates and documentation? Well here are few of the common ones. Clearly access management and the use of admin accounts will be documented. You are going to remove or disable services that you do not need and document those. Clocks are going to be synchronised and the mechanism for that recorded. The requirement to remove default user names and passwords. You are also going to tie back to licensing to make sure you have licenses for the things you are configuring.
Configuration Changes
For changes you will follow your change management process. In that you will have records of configuration changes that show owners, what the change was, when it was changed, the version of the configuration or template and where needed the relation to other assets.
Configuration Monitoring and Review
Once that configuration is in place you are going to monitor those configurations and review them. Depending on how big and complex you are you may benefit from deploying tools. If you find that the configurations do not match your templates and requirements then you follow your corrective action and risk management processes.
Standard Build Checklist
An example standard build checklist and CIS Benchmarks:
| Component | Standard Setting (Hardening) | Reason |
| Default Passwords | DISABLED / CHANGED | Prevent default credential attacks. |
| Unused Ports | CLOSED (e.g., Telnet port 23) | Reduce attack surface. |
| Guest Account | DISABLED | Prevent anonymous access. |
| Auto-Run | DISABLED (on USBs) | Prevent malware spread. |
Hello. I am Stuart Barker.
CEO here at High Table: The Compliance Agency
If you want help by the hour, internal audit or consulting support …
How to implement it
Establishing robust configuration management is essential for maintaining system integrity and ensuring that all hardware, software, and network components are deployed in a secure, standardised state. By following these technical steps, your organisation can satisfy the requirements of ISO 27001 Annex A 8.9 and mitigate the risks associated with configuration drift and unauthorised changes.
1. Formalise Configuration Baselines and Policies
- Identify and document secure configuration baselines for all asset types, utilising industry standards such as CIS Benchmarks or NIST guidelines.
- Draft a formal Configuration Management Policy and Rules of Engagement (ROE) document that defines the technical standards for hardening operational systems.
- Result: A centralised governance framework that ensures all infrastructure is provisioned according to a verified security minimum.
2. Provision Automated Configuration Management Tools
- Deploy Infrastructure as Code (IaC) or Configuration Management Database (CMDB) tools to automate the deployment and tracking of system settings.
- Utilise tools such as Ansible, Terraform, or Microsoft Intune to enforce policy-based configurations across cloud and on-premises environments.
- Result: Elimination of manual errors and the ability to rapidly scale secure deployments while maintaining a consistent technical state.
3. Restrict Configuration Access via IAM and MFA
- Enforce the Principle of Least Privilege by assigning specific Identity and Access Management (IAM) roles for configuration modification tasks.
- Mandate Multi-Factor Authentication (MFA) for all administrative interfaces and console access used to adjust system parameters or security groups.
- Result: Prevention of unauthorised tampering and protection against credential-based attacks targeting critical infrastructure settings.
4. Implement Change Control and Versioning Processes
- Integrate all configuration files into a version control system to maintain a complete history of changes, rollbacks, and author attributions.
- Establish a formal change management workflow that requires technical review and management sign-off before any baseline modification is pushed to production.
- Result: A transparent and auditable change history that supports rapid troubleshooting and compliance verification.
5. Execute Continuous Monitoring for Configuration Drift
- Provision automated scanning tools to perform real-time integrity checks and detect deviations from the established security baselines.
- Configure automated alerts within a SIEM platform to notify the security team when a non-compliant configuration change is detected on a critical asset.
- Result: Immediate visibility into unauthorised changes, allowing for rapid remediation before vulnerabilities can be exploited.
6. Perform Periodic Configuration Audits and Reviews
- Conduct quarterly technical audits to verify that the operational state of the environment matches the documented configuration baselines.
- Revoke access for any outdated or “orphan” administrative accounts discovered during the review process to maintain environment hygiene.
- Result: Sustained compliance with ISO 27001 standards and the continuous improvement of the organisational security posture.
How to pass the ISO 27001
Time needed: 2 hours.
How to comply with ISO 27001 Annex A 8.9
- Have effective asset management and know what assets you have
Have an asset management process that includes an asset register.
- Document your configuration standards
Using templates and industry best practice you will document your configuration standards for each asset type.
- Configure your assets appropriately before use
Using the configuration standards that you have developed and approved you will configure your assets appropriately before you deploy them.
- Monitor your configurations
For all asset types you will monitor the configurations to ensure they continue to meet the standards that you have set.
- Review your configurations
On a periodic basis you will review your asset configurations to ensure they are in line with the standards that you have set.
- Take actions where configurations do not match the templates and standards you have set
If you identify that assets are not configured in line with the configuration standards you will take action and follow appropriate internal processes such as risk management and change control to rectify.
- Implement controls proportionate to the risk posed
The controls that you implement and the configuration standards you choose are based on your risk assessment and proportionate to that risk and your business needs.
- Keep records
For audit purposes you will keep records. Examples of the records to keep include changes, updates, monitoring, review and audits.
- Test the controls that you have to make sure they are working
Perform internal audits that include the testing of the controls to ensure that they are working.
Top 3 mistakes and how to avoid them
The top 3 mistakes people make for ISO 27001 Annex A 8.9 are
- Leaving configuration defaults in place: Leaving systems and hardware default configurations, especially user names and passwords, is the biggest mistake that we see.
- You never check your configurations: Configuration management is not a one and done. Often we see that the actual configurations do not match the templates and standards that are documented. There are many reasons why this can happen. Do not assume you have configured and it works before the audit happens, check it. You may be surprised.
- Your document and version control is wrong: Keeping your document version control up to date, making sure that version numbers match where used, having a review evidenced in the last 12 months, having documents that have no comments in are all good practices.
Applicability across different business models
| Business Type | Applicability | Examples of Control Implementation |
|---|---|---|
| Small Businesses | Focuses on establishing “Standard Build” templates for office hardware to ensure consistent security across a small fleet. The goal is to move away from “out of the box” defaults which often contain security holes. |
|
| Tech Startups | Critical for managing fast-scaling cloud environments. Compliance requires automated configuration management to prevent “Configuration Drift” and ensure that new microservices are secure by default. |
|
| AI Companies | Vital for protecting specialized high-performance computing (HPC) and GPU clusters. Focus is on hardening the research environment to prevent unauthorized access to model IP and training data. |
|
FAQ
Configuration Management defines the “secure state” of a system, whereas Change Management controls the “process” of altering that state. While they are closely related, they serve different functions:
Configuration Management (Annex A 8.9): Focuses on the content of the settings (e.g., “The password length must be 12 characters”). It ensures the system matches the approved security blueprint (Golden Image).
Change Management (Annex A 8.32): Focuses on the workflow of modification (e.g., “Who authorized changing the password length?”). It tracks the approval and testing of changes to the configuration.
Implementation follows a five-step lifecycle: Define, Document, Implement, Monitor, and Review. To satisfy auditors, you must demonstrate a structured approach rather than ad-hoc settings:
Define: Select a security standard (e.g., CIS Benchmarks or vendor hardening guides) for each asset type.
Document: Create a “Standard Build Checklist” that details every required setting (e.g., “Disable Telnet,” “Enable Firewall”).
Implement: Apply these settings to all new devices using automation scripts or manual checklists before deployment.
Monitor: Regularly scan systems to detect “Configuration Drift” (unauthorized changes).
Review: Update your baselines annually to address new security threats.
No, a complex CMDB software is not explicitly mandatory, though it is highly recommended for larger organizations. The standard requires that configurations are “established, documented, implemented, monitored, and reviewed.”
Small Organizations: Can achieve compliance using spreadsheets (“Asset Registers”) and manual Standard Build Checklists.
Large Organizations: Should use automated tools (e.g., Microsoft Intune, Ansible, or specialised CMDBs) to manage complexity and ensure continuous compliance.
Responsibility typically lies with the Head of IT or IT Operations, while accountability remains with Senior Management. Specific roles include:
System Administrators: Responsible for applying the standard build templates and fixing configuration drift.
Security Officers: Responsible for defining the security requirements (e.g., “Passwords must expire every 90 days”) that IT must implement.
Asset Owners: Accountable for ensuring their specific assets (e.g., a finance server) adhere to the organizational policy.
A Secure Baseline (or Golden Image) is a pre-configured version of an operating system or application that has already been “hardened.” Instead of configuring every new computer manually, IT teams deploy this master image to ensure 100% consistency. It acts as the “known good state” against which all live systems are measured.
Related ISO 27001 Controls
Further Reading
Controls and Attribute Values
| Control type | Information security properties | Cybersecurity concepts | Operational capabilities | Security domains |
|---|---|---|---|---|
| Preventive | Availability | Protect | Secure Configuration | Protection |
| Integrity | ||||
| Confidentiality |
About the author
