Annex A 8.9: Configuration Management

To meet the annex a 8.9: configuration management requirement, you need a controlled, repeatable way to define, approve, implement, monitor, and evidence secure configuration baselines across systems, applications, network devices, and cloud services. Operationalize it by standardizing baselines, tying changes to a formal change process, continuously detecting drift, and retaining proof that configurations stay within approved parameters. ¹

Key takeaways:

• Define configuration baselines per asset class and environment, then make them auditable artifacts.
• Integrate configuration changes with change management, with approvals, testing, and rollback.
• Detect and resolve configuration drift continuously, and retain evidence for assessors.

Annex A 8.9 focuses on configuration management as a security control, not an IT preference. Assessors expect you to show that configurations for in-scope technology are intentionally designed, consistently applied, and kept within approved boundaries over time. The operational goal is simple: reduce avoidable risk from insecure defaults, ad hoc changes, and undocumented “snowflake” systems that nobody can reproduce or defend during an incident.

For a CCO or GRC lead, the fastest path is to treat configuration management as a control system with four parts: (1) standards (what “good” looks like), (2) governance (who can change what and how), (3) monitoring (how you detect drift and exceptions), and (4) evidence (how you prove the control operated). This page gives you requirement-level guidance you can hand to Infrastructure, Security Engineering, and Cloud Ops and then audit back to.

This requirement page is written for ISO/IEC 27001:2022 Annex A control 8.9 and should be mapped into your Statement of Applicability and control testing plan. ¹

Regulatory text

Framework requirement: “ISO/IEC 27001:2022 Annex A control 8.9 implementation expectation (Configuration Management).” ¹

Operator interpretation: You must establish and maintain controlled configurations for information processing facilities (for example: endpoints, servers, network devices, cloud resources, and applications) so they remain secure and consistent. Practically, that means you define approved configuration baselines, control changes to those baselines, and verify configurations stay aligned over time, with evidence. ¹

Plain-English interpretation (what the control demands)

Configuration management under Annex A 8.9 expects answers to five audit questions:

1. What is the approved configuration for each major technology type? (baseline/standard)
2. How do you build systems so the baseline is actually applied? (implementation mechanism)
3. Who is allowed to change configuration, and how is it approved? (governance + change control)
4. How do you detect configuration drift and insecure settings? (monitoring)
5. How do you prove it happened, repeatedly, for systems in scope? (evidence)

A working program accepts that exceptions exist (legacy apps, third-party appliances, emergency fixes). The control still expects you to manage exceptions deliberately: record them, approve them, time-bound them, and track compensating controls.

Who it applies to (entity and operational context)

Entity scope: Service organizations implementing an ISMS aligned to ISO/IEC 27001. ²

Operational scope (typical):

• Corporate IT: laptops/desktops, MDM policies, endpoint security settings
• Infrastructure: Linux/Windows servers, virtualization platforms, directory services
• Network: firewalls, routers, switches, VPN, DNS, Wi-Fi controllers
• Cloud: IAM configuration, security groups, storage policies, logging settings
• Applications: secure config flags, secrets handling patterns, hardened images/containers
• CI/CD: build agent hardening, pipeline permissions, artifact signing settings (if used)

Where auditors draw the line: Anything that stores, processes, or transmits sensitive business data, customer data, or supports critical services should be covered by baselines and drift detection. Your SoA should state how Annex A 8.9 is implemented and which systems are in scope. ¹

What you actually need to do (step-by-step)

Step 1: Define configuration “asset classes” and owners

Create a short list of configuration domains and assign accountable owners:

• Endpoints (IT Ops)
• Servers (Infra)
• Network devices (Network team)
• Cloud accounts/subscriptions (Cloud platform team)
• Applications/platform services (App owners + Security Engineering)

Deliverable: a configuration management scope statement and RACI that ties each domain to an owner and backup owner.

Step 2: Establish secure baseline standards (the “gold configurations”)

For each asset class, write a baseline that includes:

• Security-critical settings (authentication, logging, encryption, remote access)
• Administrative controls (who can administer, MFA expectations, break-glass controls)
• Patch/update configuration expectations (where configured, not patch SLAs)
• Monitoring/log forwarding configuration
• Allowed/blocked services, ports, protocols
• Configuration parameters that must never be changed without approval

Practical tip: Keep baselines readable. Put “must” requirements in the baseline and move “how-to” build steps into runbooks.

Deliverables: baseline standards per asset class, with versioning and approver names.

Step 3: Implement baselines using automation where possible

Auditors don’t require a specific tool, but they will challenge manual-only approaches because they are hard to sustain.

Common implementation patterns:

• Endpoint baselines via MDM policies and standard images
• Server baselines via configuration-as-code (desired state) or hardened images
• Cloud baselines via templates/policies and guardrails (preventive controls)
• Network baselines via standardized templates plus controlled pushes

Deliverable: evidence that the baseline is applied (for example: policy assignments, template IDs, build pipeline references, screenshots or exports from admin consoles).

Step 4: Integrate configuration changes with change management

You need an explicit rule: configuration changes are changes, and they follow the change process unless handled under an emergency path.

Minimum operational requirements:

• Request ticket with scope, risk, and rollback
• Approval from the right owner (and Security for high-risk changes)
• Testing/validation notes (even if lightweight)
• Implementation record and post-change verification
• Emergency change path that forces retrospective review

Deliverables: change records tied to configuration items, plus a small sample you can hand to an auditor.

Step 5: Monitor for configuration drift and exceptions

This is where teams often fail Annex A 8.9 in practice: they have baselines on paper but no detection.

Build a drift program:

• Define “drift signals” per asset class (for example: logging disabled, admin group change, firewall rule opened)
• Run recurring checks (continuous where possible; scheduled where not)
• Route alerts to an owning queue
• Track exceptions with justification, approver, compensating control, and review date

Deliverables: drift reports, alert tickets, exception register, and evidence of remediation.

Step 6: Prove control operation with recurring evidence capture

Annex A 8.9 is assessable only if you can show ongoing operation. Set a routine evidence package per quarter (or your internal audit cadence) that includes:

• Current baseline versions
• A list of in-scope systems mapped to baseline
• Drift findings and closure evidence
• Change samples showing approvals and verification
• Exceptions and re-approvals

Daydream fits naturally here when you need repeatable evidence capture mapped directly to Annex A 8.9, with clean audit trails and recurring collection workflows that don’t depend on one engineer’s inbox.

Required evidence and artifacts to retain (audit-ready)

Use this table as your evidence checklist:

Artifact	What it proves	Good enough for an auditor
Configuration Management Policy/Standard	You defined control intent and governance	Dated, approved, versioned
Baseline standards per asset class	You know your approved secure settings	“Must” statements, version history
Build/runbooks or configuration-as-code references	Baselines are implementable	Links/IDs, change history
CMDB/inventory mapping assets to baselines	Coverage of in-scope systems	Exported list, owner fields
Change tickets for config changes	Controlled change governance	Approvals, rollback, verification notes
Drift detection outputs	You detect misconfiguration	Reports/alerts with timestamps
Exception register	Managed deviations	Approval, justification, compensating controls
Periodic review records	Ongoing operation	Meeting notes, sign-offs, updated baselines

(Alignment to Annex A 8.9 is expected under ISO/IEC 27001:2022. Source: ISO/IEC 27001 overview; ISMS.online Annex A control index)

Common exam/audit questions and hangups

Expect these questions and prepare crisp answers:

• “Show me your baselines.” Provide the baseline documents, version history, and last approval.
• “How do you know systems match the baseline today?” Show drift monitoring outputs and remediation tickets.
• “Pick a system. Prove its configuration is controlled.” Walk from inventory → baseline mapping → applied policy/template → drift status → recent change history.
• “How do you handle emergency changes?” Show emergency change records plus retrospective approvals.
• “What about SaaS and managed services?” Explain what you configure (tenant settings, IAM, logging) and how you monitor for changes.

Hangup to avoid: “We rely on engineering judgment.” Auditors want defined standards and repeatable verification aligned to Annex A 8.9. ¹

Frequent implementation mistakes (and how to avoid them)

1. Baselines that are aspirational and never applied.
   Fix: tie each baseline to a technical enforcement point (MDM policy, IaC module, firewall template).

2. No inventory-to-baseline mapping.
   Fix: maintain a list of in-scope systems and the baseline each must meet. Without mapping, coverage is guesswork.

3. Drift detection exists, but nobody owns remediation.
   Fix: assign queues and SLAs internally, even if informal. Track closure in tickets.

4. Exceptions are tribal knowledge.
   Fix: create an exception register with approvals, compensating controls, and periodic revalidation.

5. Change management is bypassed for “small” config edits.
   Fix: define what constitutes a configuration change and enforce logging/approval for high-risk settings.

Enforcement context and risk implications

No public enforcement cases were provided for this control in the source catalog, so this page does not cite enforcement outcomes.

Risk-wise, weak configuration management tends to create two practical failure modes:

• Preventable exposure from insecure defaults, overly permissive access, or disabled logging.
• Audit failure because you cannot prove configurations are controlled and stable over time, even if teams believe they are.

ISO/IEC 27001 positions controls like Annex A 8.9 as part of a verifiable management system, so “we do it sometimes” will not survive a serious certification audit. ²

Practical 30/60/90-day execution plan

First 30 days (stabilize and define)

• Name configuration owners and publish a simple RACI.
• Identify in-scope asset classes and systems (start with the most critical services).
• Draft baseline standards for the top asset classes you can influence quickly (endpoints, cloud IAM/logging, servers).
• Decide where baselines will live, how they are versioned, and who approves changes.

Days 31–60 (implement and connect to governance)

• Implement at least one enforcement mechanism per asset class (policy, template, code, or hardened image).
• Update change management procedures to explicitly include configuration changes and emergency handling.
• Stand up a basic exception register and approval workflow.
• Start recurring evidence capture for Annex A 8.9 (baseline versions, change samples, inventory mapping).

Days 61–90 (prove operation and reduce drift)

• Enable drift detection for high-impact settings (logging, IAM/admin access, network exposure).
• Run a first drift review, open remediation tickets, and close a meaningful set of findings.
• Hold a baseline review meeting; record decisions and update versions.
• Prepare an “auditor pack” for Annex A 8.9 with hyperlinks to evidence, exports, and tickets. If you use Daydream, map Annex A 8.9 directly to tasks and recurring evidence collection so the pack regenerates cleanly for each audit cycle.

Frequently Asked Questions

Does Annex A 8.9 require configuration-as-code?

No specific tooling is mandated, but assessors will expect consistent application and verification. Configuration-as-code often makes evidence and drift control easier to prove. ¹

What systems should be in scope first?

Start with systems that process or store sensitive data and the platforms that control access to them (identity, logging, network controls). Expand coverage by asset class once you can prove baseline + change control + drift detection.

How do we handle third-party managed infrastructure where we can’t change settings?

Document shared responsibility: what you can configure (tenant settings, IAM, logging) and what the third party controls. Track contractual or assurance artifacts separately, but keep your configurable settings under your baseline and monitoring.

What counts as “evidence” for configuration management in an ISO audit?

Auditors typically accept a mix of baseline documents, system exports/screenshots, change tickets, and drift reports that show operation over time. Your evidence should connect a specific system to a baseline and show verification.

How strict do baselines need to be to pass an audit?

Strict enough that they constrain high-risk settings and are actually enforceable. A short baseline that is applied and monitored generally audits better than a long baseline that nobody can implement consistently.

We have different configs per environment (dev/test/prod). Is that allowed?

Yes, if you define environment-specific baselines and document the rationale (for example, production logging and access controls). The audit risk comes from undocumented differences and unmanaged drift.

Footnotes

1. ISO/IEC 27001 overview; ISMS.online Annex A control index

2. ISO/IEC 27001 overview