A single misconfigured firewall rule. A default credential nobody changed. An open management port on a cloud workload that was supposed to be locked down months ago. Configuration drift is invisible — until an attacker finds it first. ISO 27001 Control 8.9 exists to close that gap, requiring organizations to define, enforce, and continuously monitor secure configurations across their entire environment.
What 8.9 Requires
ISO 27001 Control 8.9 requires organizations to establish, document, implement, monitor, and review secure configurations for hardware, software, services, and networks. The goal is to ensure that systems operate in a known, hardened state and that any deviation from that state is detected and corrected.
In practical terms, compliance means your organization must:
- Define secure configuration baselines for every category of system in your environment — servers, workstations, network devices, cloud resources, and applications.
- Use industry benchmarks as starting points. CIS Benchmarks, vendor hardening guides, and internal risk assessments should inform your baselines rather than relying on vendor defaults.
- Enforce baselines consistently. Every system deployed should match its applicable baseline before it enters production.
- Monitor for configuration drift. Regularly compare live configurations against baselines to detect unauthorized or unintended changes.
- Integrate with change management. No configuration change should happen without authorization, documentation, and a record. This ties directly to Control 8.32 (Change Management).
- Review and update baselines when systems are patched, upgraded, decommissioned, or when new threats emerge.
The control applies across the full technology stack — on-premise infrastructure, cloud services, SaaS platforms, and operational technology. If it has a configuration, it is in scope.
Why 8.9 Matters
Consider a common scenario: an organization migrates workloads to the cloud. Under pressure to ship, the team deploys virtual machines with default configurations — management ports open to the internet, unnecessary services running, logging disabled. Six months later, an attacker discovers an exposed management port through routine scanning, authenticates with a default credential, and pivots from that single machine into production databases containing customer data.
This is not a sophisticated attack. It is a configuration failure that compounded over time. Research from Business Insider found that 97% of organizations report cybersecurity incidents linked to configuration drift — not zero-day exploits or advanced persistent threats, but systems that quietly drifted from their intended state.
Configuration failures create a specific class of risk: unauthorized access, data exposure, regulatory penalties, and audit failures. A misconfigured system does not generate alerts. It does not look compromised. It simply sits in an insecure state until someone — an attacker or an auditor — notices.
What attackers exploit
Attackers do not need sophisticated tooling when configurations hand them the keys. Common patterns align with MITRE ATT&CK initial access and lateral movement techniques:
- Default credentials left on network devices, databases, and management interfaces
- Unnecessary services and open ports on production systems that expand the attack surface
- Configuration drift after initial hardening — ports reopened during troubleshooting, permissions expanded for a one-time task and never reverted
- Inconsistent configurations across environments — development settings deployed to production, staging credentials active in live systems
- Missing or disabled logging on critical infrastructure, eliminating visibility into unauthorized access
- Unpatched or outdated firmware with known vulnerabilities on devices that were hardened at deployment but never maintained
Each of these represents a gap between intended security posture and actual system state — exactly the gap Control 8.9 is designed to eliminate.
How to Implement 8.9
For your organization (first-party)
Implementation follows a lifecycle: inventory, define, enforce, monitor, review. The maturity of your configuration management program depends on how consistently you execute each phase — and how much of it you automate. Organizations that treat this as a manual documentation exercise invariably fall behind within months.
1. Inventory all configuration items. Catalog every asset that has a configurable state — servers, workstations, network devices, cloud resources, containers, applications, and services. You cannot manage configurations you do not know exist.
2. Define secure baselines. Build baselines from a combination of vendor hardening guides, CIS Benchmarks, and your own risk assessment. Baselines should specify exact settings — not general guidance. For a Linux server, that means specific sysctl parameters, disabled services, firewall rules, and file permissions.
3. Document baselines as standard build templates. Golden images, Infrastructure-as-Code (IaC) templates, and automated build pipelines ensure that every system starts from a known secure state. Treat baselines as code — version-controlled, peer-reviewed, and tested before deployment.
4. Enforce baselines through automation. Configuration management tools (Ansible, Puppet, Chef, SaltStack) and cloud-native policy engines (AWS Config, Azure Policy, Google Cloud Organization Policy) can enforce configurations at deployment and detect drift in production. Manual enforcement does not scale and introduces human error.
5. Implement configuration change control. Tie every configuration change to a formal change management process aligned with Control 8.32. Every change needs a request, risk assessment, approval, implementation record, and verification step. No ad hoc changes to production systems.
6. Monitor for drift continuously. Automated configuration compliance scans should compare live system states against baselines on a defined cadence — daily for critical systems, weekly for standard infrastructure. Alert on deviations and require remediation within defined SLAs.
7. Review and update baselines regularly. Baselines are not static. When systems are patched, upgraded, or when new vulnerabilities are disclosed, baselines must be reviewed and updated. Schedule formal reviews at least annually, with ad hoc reviews triggered by significant changes or threat intelligence.
8. Maintain an audit trail. Record who changed what, when, why, and who approved it. This evidence is essential for both incident investigation and audit compliance.
Common mistakes to avoid:
- Defining baselines but never monitoring for drift. A baseline that is not enforced is documentation, not a control.
- Treating configuration management as a one-time project. This is a continuous process, not a checkbox exercise.
- Excluding cloud infrastructure and SaaS from scope. If it is in your environment and has a configuration, it is in scope — regardless of where it runs.
- No clear ownership. When configuration management is split across teams with no single accountable party, gaps are inevitable.
- Using vendor defaults as the baseline. Vendor defaults prioritize ease of setup, not security. They are a starting point for hardening, not the baseline itself.
For your vendors (third-party assessment)
Control 8.9 applies to your supply chain. When vendors process, store, or transmit your data, their configuration practices affect your risk posture.
Questionnaire questions to include:
- Do you maintain documented configuration baselines for systems handling our data?
- How do you detect and remediate configuration drift?
- What change control process governs configuration changes?
- Which industry benchmarks (CIS, DISA STIGs, vendor guides) do your baselines follow?
Evidence to request: Configuration management policy, a sample baseline document (redacted as needed), a recent drift detection report, and change management logs showing the approval workflow.
Red flags during assessment:
- The vendor cannot name the benchmark standard their baselines follow
- No automated drift detection — reliance on periodic manual reviews only
- Configuration changes are not tied to a formal change management process
- “We use vendor defaults” presented as adequate hardening
Verification: Request a recent configuration audit report or third-party assessment. Ask for evidence of periodic baseline reviews — not just that baselines exist, but that they are actively maintained.
Audit Evidence for 8.9
Auditors expect specific artifacts demonstrating that configuration management is operational, not just documented. The table below maps evidence types to the artifacts you should have ready.
| Evidence Type | Example Artifact |
|---|---|
| Policy | Configuration Management Policy defining baseline standards, review cadence, roles and responsibilities |
| Baseline documentation | Standard build templates for each system type (servers, workstations, network devices, cloud resources) |
| Drift detection reports | Automated configuration compliance scan results showing current state vs. baseline |
| Change records | Configuration change requests with approval, implementation, and verification records |
| Review records | Minutes or tickets from periodic baseline review meetings (at least annual) |
| Inventory | Configuration item database or CMDB linking assets to their applicable baselines |
| Hardening evidence | CIS Benchmark compliance scores or equivalent scan exports for representative systems |
| Incident records | Post-incident reviews where configuration drift was identified and remediated |
The key principle: auditors want to see that the control is operating, not just that it was designed. A policy without drift detection reports is insufficient. Baselines without change records suggest the process is not being followed. The strongest evidence packages pair automated scan results with the change records that explain each deviation — showing auditors that drift is detected, investigated, and either remediated or formally accepted through the risk management process.
Cross-Framework Mapping
Control 8.9 maps to configuration management requirements across multiple frameworks. The NIST 800-53 mapping below follows the official OLIR crosswalk.
| Framework | Equivalent Control(s) | Coverage |
|---|---|---|
| NIST 800-53 Rev. 5 | CM-01 (Policy & Procedures) | Configuration management policy framework |
| NIST 800-53 Rev. 5 | CM-02 (Baseline Configuration) | Baseline definition and documentation |
| NIST 800-53 Rev. 5 | CM-02(03) (Retention of Previous Configurations) | Baseline version history |
| NIST 800-53 Rev. 5 | CM-03 (Configuration Change Control) | Change authorization and tracking |
| NIST 800-53 Rev. 5 | CM-03(07) (Review System Changes) | Post-implementation review |
| NIST 800-53 Rev. 5 | CM-03(08) (Prevent/Limit Changes) | Enforcement of approved configurations |
| NIST 800-53 Rev. 5 | CM-04 (Impact Analyses) | Change impact assessment |
| NIST 800-53 Rev. 5 | CM-05 (Access Restrictions for Change) | Authorization controls on configuration changes |
| NIST 800-53 Rev. 5 | CM-06 (Configuration Settings) | Specific security configuration parameters |
| NIST 800-53 Rev. 5 | CM-08 (System Component Inventory) | Configuration item inventory |
| NIST 800-53 Rev. 5 | CM-09 (Configuration Management Plan) | Overarching CM program plan |
| NIST 800-53 Rev. 5 | CM-09(01) (Assignment of Responsibility) | Roles and accountability |
| NIST 800-53 Rev. 5 | SA-10 (Developer Configuration Management) | Secure development configurations |
| SOC 2 (TSC) | CC8.1 (Change Management) | Change control processes |
| CIS Controls v8.1 | Control 4 (Secure Configuration of Enterprise Assets and Software) | Baseline configuration and hardening |
| NIST CSF 2.0 | PR.IP-1 (Configuration Management) | Configuration management practices |
| DORA (EU) | Article 9 (ICT Risk Management) | ICT asset configuration requirements |
| CPS 230 (APRA) | Operational Risk Management | IT asset configuration governance |
Organizations subject to multiple frameworks can use this mapping to demonstrate how a single configuration management program satisfies overlapping requirements — reducing duplication in both implementation and audit evidence. When preparing for a multi-framework audit, map your configuration management artifacts (policies, baselines, drift reports, change records) to each framework’s specific control IDs. This allows you to present a unified evidence package rather than maintaining separate documentation for each standard.
Related ISO 27001 Controls
Configuration management does not operate in isolation. The following controls have direct functional relationships with 8.9.
| Control ID | Control Name | Relationship |
|---|---|---|
| 8.32 | Change Management | Configuration changes must follow the change management process — these controls are tightly coupled |
| 8.8 | Management of Technical Vulnerabilities | Patching and vulnerability remediation changes baseline configurations and may require baseline updates |
| 5.37 | Documented Operating Procedures | Baselines should reference and align with documented operating procedures |
| 8.1 | User Endpoint Devices | Endpoint configurations (laptops, workstations, mobile devices) are a key baseline target |
| 8.20 | Networks Security | Network device configurations (firewalls, switches, routers) fall directly under 8.9 scope |
| 8.25 | Secure Development Life Cycle | Development and build environment configurations need baselines to prevent insecure defaults reaching production |
| 8.15 | Logging | Configuration change logging supports 8.9 monitoring requirements and provides audit evidence |
| 5.23 | Information Security for Use of Cloud Services | Cloud service configurations — IAM policies, network rules, storage permissions — are explicitly in scope |
Frequently Asked Questions
What is ISO 27001 8.9?
ISO 27001 Control 8.9 is a configuration management control that requires organizations to establish, document, and maintain secure configurations for hardware, software, services, and networks. It is part of the Annex A technology controls in ISO/IEC 27001:2022 and applies to all configurable assets within the ISMS scope, including cloud infrastructure and third-party services.
What is the difference between configuration management and change management?
Configuration management (Control 8.9) focuses on defining, documenting, and maintaining the desired state of systems — what settings should be in place and whether they remain that way over time. Change management (Control 8.32) governs the process of making changes — ensuring that every modification is requested, assessed for risk, approved, and documented. The two controls are tightly coupled: every configuration change should flow through the change management process, and the resulting system state should be validated against the configuration baseline.
What happens if 8.9 is not implemented?
Without configuration management, systems drift from their intended security state over time — default credentials remain active, unnecessary services stay enabled, and permissions expand without oversight. This drift creates exploitable vulnerabilities that lead to unauthorized access and data breaches. During an audit, the absence of configuration baselines, drift monitoring, and change records is a significant nonconformity that can block certification.
How do you audit 8.9?
Auditors evaluate 8.9 by examining whether configuration management is both designed and operating effectively. They will request documented baselines, evidence of drift detection scans, change management records, and periodic review artifacts. The audit typically includes sampling specific systems to verify that their live configurations match documented baselines and that any deviations are tracked and remediated.
How UpGuard Helps
Configuration drift and unmanaged attack surfaces are two sides of the same problem. UpGuard Breach Risk continuously monitors your external attack surface for misconfigurations, exposed services, and security risks that configuration management programs are designed to prevent. It automatically detects exposed admin panels, default configurations on public-facing assets, and security header misconfigurations — giving your team visibility into the configuration gaps that auditors and attackers both look for.
See how UpGuard Breach Risk monitors your configuration exposure →