ISO/IEC 27001:2022 · derived mapping target
A.8.9Configuration management
Establish, document and maintain secure configurations for your hardware, software and services, and detect drift away from them over time.
Mapping at a glance
A.8.9Configuration managementISO/IEC 27001:2022
A.8.9 is covered by 46 Sekit CSF controls. +41 more in the table below. Open in the full graph →
Mapped from the Sekit CSF
The Sekit controls that cover this requirement, lens by lens.
RCF-0003Policy management · TechnicalsupportsConfiguring systems so key policy rules are enforced automatically, rather than relying on staff goodwill, is the technical layer underneath A.8.9's configuration baselines.RCF-0012Risk treatment · TechnicalsupportsVerifying that each agreed technical risk measure is genuinely configured in the live environment is exactly the drift check A.8.9 requires.RCF-0015Exception management · TechnicalrelatedMaking approved policy exceptions visible to monitoring and pairing them with compensating measures keeps deliberate deviations from becoming untracked configuration drift.RCF-0039Hardware inventory · TechnicalsupportsAutomated discovery through MDM enrollment, RMM agents or network scanning keeps the hardware inventory honest, the asset-accuracy precondition A.8.9's baselines depend on.RCF-0042Software inventory · TechnicalsupportsTooling that reports installed software and flags unlicensed or unexpected applications gives A.8.9's configuration baseline something concrete to check devices against.RCF-0054Criticality tagging · TechnicalrelatedTagging assets with criticality ratings to prioritize alerts and patching is an input to configuration management rather than the baseline enforcement A.8.9 itself covers.RCF-0057CMDB quality · TechnicalsupportsConnecting discovery tooling to the authoritative asset repository keeps configuration records synchronized with the real state of the environment, the accuracy A.8.9 assumes.RCF-0108Data minimization · TechnicalrelatedAutomated discovery of sensitive data across storage supports classification decisions but sits outside the system-hardening scope A.8.9 addresses directly.RCF-0130CI/CD hardening · PolicysupportsWritten security requirements for the build and deployment pipeline treat it as a production system, extending A.8.9's configuration discipline to the pipeline itself.RCF-0132CI/CD hardening · TechnicalsupportsLocking the pipeline down so build definitions and deployment steps cannot be tampered with is A.8.9's configuration integrity applied to the delivery system.RCF-0133IaC scanning · PolicysupportsRequiring infrastructure-as-code templates to pass a security scan before deployment prevents misconfiguration before it reaches the environment A.8.9 is meant to protect.RCF-0134IaC scanning · ProcesssupportsScanning every infrastructure template for misconfigurations before changes are applied catches configuration errors at the design stage rather than after deployment.RCF-0135IaC scanning · TechnicalsupportsEnforcing automated template scanning in the pipeline so non-compliant infrastructure cannot deploy is a technical gate for exactly the drift A.8.9 tries to prevent.RCF-0139Container security · PolicysupportsWritten standards for how container images are built, stored and run set the configuration baseline A.8.9 expects for containerized workloads specifically.RCF-0140Container security · ProcesssupportsReviewing container images and runtime configurations against the standard on a schedule is A.8.9's baseline-review practice applied to containers.RCF-0141Container security · TechnicalsupportsScanning container images automatically before deployment and enforcing runtime restrictions is the technical enforcement A.8.9 expects, scoped to containers.RCF-0145Configuration baselines · PolicysupportsA written, management-approved configuration standard for every device type, reviewed at least annually, is the written-baseline leg A.8.9's requirement is built around.RCF-0146Configuration baselines · ProcesssupportsApplying the approved baseline at deployment and re-checking after significant changes is the process leg A.8.9 needs alongside the written standard.RCF-0147Configuration baselines · TechnicalsupportsA management tool that continuously compares device settings to the approved baseline and flags drift is the ongoing verification A.8.9's baseline otherwise lacks.RCF-0160Device hardening · PolicysupportsDefining in writing which services and defaults must be disabled to shrink attack surface is a specific hardening instance of A.8.9's configuration standards.RCF-0161Device hardening · ProcesssupportsHardening each device at build time and after major changes applies the written standard consistently rather than only at initial rollout.RCF-0162Device hardening · TechnicalsupportsPushing hardening settings from a central tool so every device keeps the approved configuration without manual work is A.8.9's enforcement mechanism for hardening specifically.RCF-0182TLS termination/hardening · ProcesssupportsScanning public endpoints for weak TLS protocols and expiring certificates on schedule is a configuration-drift check A.8.9 expects for network-facing services.RCF-0191Wireless security · ProcesssupportsChecking wireless configuration against the standard, rotating passphrases and hunting for rogue access points is A.8.9's drift detection applied to the wireless network.RCF-0194Time sync · ProcessrelatedVerifying that clocks stay synchronized with the approved time source is a narrow but recurring configuration check within A.8.9's scope.RCF-0197Centralized logging · ProcessrelatedOnboarding new log sources and closing gaps keeps logging configuration current, though it is a monitoring concern that only partly overlaps A.8.9's system-hardening focus.RCF-0209Log protection & retention · ProcessrelatedChecking that retention settings match policy and stored logs remain complete is a configuration verification specific to logging infrastructure.RCF-0223Configuration management · PolicysupportsWritten security configuration standards for each system type, operating systems, cloud services, network devices, is the policy expression of A.8.9's requirement.RCF-0224Configuration management · ProcesssupportsReviewing deployed configurations against the approved standards on a recurring basis and correcting deviations is the process leg A.8.9 explicitly asks for.RCF-0225Configuration management · TechnicalsupportsTooling that continuously checks configurations against the standard and fixes or alerts on deviations is the technical enforcement A.8.9's drift-detection requirement describes directly.RCF-0226Baseline compliance · PolicysupportsCommitting to measure what share of systems meet approved baselines and report that to management operationalizes A.8.9's configuration standard into a tracked metric.RCF-0227Baseline compliance · ProcesssupportsMonitoring baseline compliance continuously and bringing non-compliant systems back within the standard inside an agreed window closes the loop A.8.9 requires.RCF-0228Baseline compliance · TechnicalsupportsTooling that reports baseline compliance rates and remediation progress over time gives A.8.9's compliance monitoring measurable evidence rather than a point-in-time claim.RCF-0333Shared responsibility model · TechnicalsupportsDeploying tenant hardening, backup, logging and secure configuration for everything on the company's side of the cloud boundary applies A.8.9's discipline to shared-responsibility gaps specifically.RCF-0337CSPM posture · PolicysupportsDocumenting a requirement that every cloud environment is continuously checked against an agreed configuration standard is A.8.9's baseline requirement applied to cloud infrastructure.RCF-0338CSPM posture · ProcesssupportsReviewing cloud configuration findings on schedule and fixing misconfigurations within severity-based deadlines is A.8.9's review-and-correct cycle scoped to cloud.RCF-0339CSPM posture · TechnicalsupportsA tool that continuously scans cloud accounts for insecure configurations and alerts immediately is the automated drift detection A.8.9 expects, applied to cloud.RCF-0346Workload protection · PolicysupportsWritten security requirements every cloud workload must meet before and while running extends A.8.9's configuration baseline to virtual machines, containers and functions.RCF-0350Multi-tenancy controls · ProcessrelatedVerifying tenant boundaries and treating cross-tenant exposure as a defect to fix immediately is a cloud-specific check adjacent to A.8.9's general baseline scope.RCF-0352SaaS security configuration · PolicysupportsDefining the security settings every SaaS application must have, MFA, sharing defaults, admin limits, is A.8.9's configuration baseline extended to SaaS tools.RCF-0353SaaS security configuration · ProcesssupportsConfiguring every SaaS application to the standard at adoption and re-checking when vendor settings change keeps SaaS configuration from silently drifting.RCF-0354SaaS security configuration · TechnicalsupportsTooling that continuously compares SaaS settings against the security baseline and alerts on drift gives A.8.9's SaaS-configuration requirement the same automation as endpoint baselines.RCF-0402Change management · TechnicalsupportsEnforcing the change workflow technically so unapproved production changes are blocked, rather than merely discouraged, protects the configuration baselines A.8.9 exists to maintain.RCF-0420OT asset inventory · TechnicalsupportsPassive discovery that learns the OT device population from network traffic without probing fragile equipment keeps the asset inventory A.8.9's baselines depend on current for OT.RCF-0426Patch/compensating controls (ICS) · TechnicalrelatedNetwork isolation, application allowlisting and targeted monitoring for unpatchable production systems are compensating configuration controls where A.8.9's normal baseline-and-patch approach cannot apply.RCF-0432Safety alignment · TechnicalrelatedDesigning and validating that security controls cannot interfere with safety-critical functions before deployment is a configuration-change safeguard specific to OT environments within A.8.9's scope.
NIST CSF 2.0 counterparts
Reached through the Sekit CSF controls both map to — a mapping, not a formal equivalence.
ISO/IEC 42001:2023 — Annex A counterparts
Cyber Essentials counterparts
Evidence that proves this control
What an auditor, or Sekit's evidence engine, asks for.
Device hardening baseline
The secure-configuration standard applied to devices when handed out (default settings, disabled services) and how compliance is checked.
Change and release management records
The process to review and approve changes to production systems before applying them, and how new versions are released in a controlled way.
From the Sekit evidence catalog
In practice
Configuration baselines usually exist as a document from when devices were first standardized, and drift takes over from there. An SME might show a hardened laptop image, but the RMM console reveals a meaningful share of the fleet has drifted from it: a disabled firewall rule here, a browser extension there. Cloud configuration is worse: the CSPM tool flags dozens of findings on day one because default settings were never reviewed against a written baseline, only against whatever the vendor shipped, and production changes still slip in outside the ticketed process whenever an incident makes the approval step feel like an obstacle.
Common gaps
A configuration baseline exists for laptops, but the management console shows a meaningful share of the fleet has drifted from it undetected.
Cloud posture management flags misconfigurations on day one because default settings were never reviewed against a written baseline before go-live.
Change management approval is documented, but production changes still happen outside the ticketed process during time-pressured incidents.
Questions your auditor will ask
How does the company know a device has drifted from its approved configuration?
A management tool continuously compares device settings to the approved baseline and flags drift, rather than relying on the original build image staying correct.
Are cloud environments checked against a security standard, or only against defaults?
Cloud security posture management tooling continuously scans every account against an agreed configuration standard and alerts on new misconfigurations.
Can a change reach production without going through approval?
No, the change workflow is enforced technically so unapproved production changes are blocked, not merely discouraged in a policy document.
How is the hardware and software inventory kept accurate over time?
Automated discovery, MDM enrollment, RMM agents, network scanning, surfaces devices and software the manual register misses.
Where regulation demands it
NIS2 Article 21 names configuration management as its own obligation (6.3), distinct from but linked to change management (6.4).
ENS op.exp.3 requires managing the security configuration of systems, the direct Spanish-framework counterpart to A.8.9.
Related controls
Via the shared Sekit CSF topic, not the framework's own index.
Ask Sekura: “What evidence proves A.8.9?”
Also via MCP, free with account