A.8.9 Configuration management: requirements and evidence

What A.8.9 configuration management asks for and why it is new in 2022

A.8.9 Configuration management asks the organization to establish, document, implement, monitor and review configurations of its hardware, software, services and networks, including the security settings that protect them. A compliance lead or engineer answering this control must be able to show which configuration is approved, that it was applied, and that it is still in place. A.8.9 has no counterpart in the 2013 edition: it is one of the 11 controls added in the 2022 revision of Annex A, so organizations that certified under 2013 will find no earlier control to point to and must write the requirement into their Statement of Applicability from scratch.

The control covers more than general build settings. Security configurations, such as logging levels, disabled services, default credentials, firewall rules, encryption options and hardening benchmarks, sit inside its scope, and so do the configurations of cloud services and network devices. The usual difficulty is drift: the approved baseline is written down, but production systems gradually diverge through emergency fixes, manual changes and upgrades that nobody records. An assessor will usually sample a few systems, compare their live settings with the documented baseline, and ask who noticed and corrected any difference. Confirm with your certification body how it expects you to define the baseline for your environment before you build the evidence trail.

Three related Annex A controls shape the boundary of A.8.9. A.8.19 Installation of software on operational systems governs who may install software and how it is tested first. A.8.32 Change management governs how changes are requested, authorized, tested and rolled back, and assessors often check that configuration changes pass through it. A.5.9 Inventory of information and other associated assets provides the list of systems that a baseline must cover. Mapping these three controls together prevents gaps where a configuration change bypasses both the inventory and the change record. DeployOpen plans, implements and documents these technical and procedural controls in your environment and prepares the evidence an assessor will sample. Only an independent auditor or accredited certification body can test the control and issue a certificate, and the organization remains responsible for operating its own controls.

Which systems and decisions bring configuration management into scope

A.8.9 applies wherever a configuration can weaken security, so the scope starts with an inventory of what carries settings. The decisions below determine which baselines, owners and evidence the organization must maintain, and they match what the NIST SP 800-53 crosswalk and the ENISA NIS2 mapping expect from configuration management practices.

Hardware and user endpoints

Laptops, servers, mobile devices and network appliances all carry settings such as disk encryption, local firewall state, screen lock and service exposure. Decide whether every device class is in scope or only those that touch sensitive data, and record the owner of each class. Check that the asset inventory from A.5.9 lists the devices, so that a configuration check cannot quietly skip a device that no one has registered.

Operating systems and applications

Scope covers the operating system build, installed services, application settings and default accounts that ship with each product. Decide whether the baseline is a vendor benchmark, an internal standard or both, and who approves deviations. Agree how often the baseline is reviewed, since a configuration that was secure at install can drift after patches or upgrades.

Cloud and SaaS tenant settings

Cloud accounts and SaaS tenants expose security settings through consoles and APIs, such as storage access policies, logging switches and sharing defaults. Decide whether these settings are inside the ISMS scope and who changes them. Under a managed service, the provider may run the platform, but the organization usually still owns the tenant configuration it chooses, so confirm that split in the contract and the shared responsibility documentation.

Network devices and segmentation

Firewalls, switches, load balancers and VPN gateways hold rule sets and management settings that determine which systems can talk to each other. Decide which devices fall under the baseline and whether rule changes must follow the same review path as server changes. Keep management interfaces and administrative protocols in scope, because an unreviewed default on a management plane can undo the segmentation that other controls depend on.

Infrastructure as code and pipelines

When environments are built from templates, the template becomes the configuration. Decide whether the repository holding these files is the authoritative record, and whether manual console changes are allowed at all. Scope the review of templates and the pipeline that applies them, since an approved template can still be altered in a branch before deployment. The repository history then becomes part of the evidence.

Third-party managed services

Outsourced hosting, managed detection and backup services change configurations on the organization's behalf. Decide which service configurations are reported back to the organization, how often, and whether the provider's own baseline is accepted or replaced. Record the evidence the provider must supply, and include the obligation in the supplier agreement so that the scope does not depend on informal promises.

How an assessor tests A.8.9 configuration management

This table walks through the four steps an assessor usually takes for A.8.9: confirming a documented configuration standard, sampling live systems against it, reviewing how deviations are approved and reverted, and checking that monitoring runs and findings are acted on. Read each row as a test, the evidence the assessor asks for, and the gap that most often produces a finding. The main takeaway is that a documented baseline alone is not enough; the assessor will expect proof that real systems match it and that drift gets caught.

Test step	Evidence requested	Common findings
Confirm a configuration standard exists	Approved baseline documents for each system type, including security settings, with owner and review date	No documented baseline for some server or cloud types, or baselines that were never approved
Sample live systems against the standard	Current configuration exports or scan results for a sample of endpoints, servers, network devices and cloud resources, compared to the baseline	Sampled systems differ from the baseline with no record of why, or sampled hosts are missing from the inventory
Review deviation and exception handling	Exception register with justification, risk acceptance, approver and expiry, plus change records for approved deviations	Unapproved exceptions, exceptions without expiry, or deviations made directly on systems without a change request
Check reversion of unapproved changes	Tickets or scan history showing drift was detected and corrected, with timestamps	Drift found in scans but no ticket raised, or corrections recorded without verification
Verify monitoring runs as described	Scan schedules, tool configuration, coverage reports showing which assets are assessed	Monitoring covers only part of the estate, or scans were disabled or failing without anyone noticing
Confirm configurations are checked after change	Change records linked to post-change configuration checks, such as a re-scan or peer review of settings	Changes closed without any configuration check, especially for cloud and network changes made outside the normal process
Review how findings are acted on	Remediation tickets with owners, due dates, closure evidence and trend reports reviewed by management	Findings left open with no owner, or the same misconfiguration recurring across review cycles

The sequence to implement A.8.9 configuration management

The sequence moves from knowing what exists, to agreeing what secure looks like, to proving that systems stay in that state and that changes are controlled. Each step leaves a record an assessor can sample.

Inventory the in-scope assets
Start by listing every hardware device, operating system image, application, cloud service, network device and security tool that falls within the ISMS scope. The owning team should record each asset with its owner, location, purpose and asset class, so that baselines can be assigned to something concrete. The output is an asset register that ties back to the inventory control in A.5.9. The step is complete when the register is reviewed against live discovery data and the gaps are assigned to owners.
Define a baseline for each asset class
Group the inventory into asset classes such as workstations, Linux servers, network switches, container images and SaaS tenants, then write a configuration baseline for each. Each baseline should list the security settings that matter for that class, including service exposure, authentication settings, logging, encryption and default account handling. Teams often draw these from a recognized hardening benchmark, adjusted to the organization's own risk decisions. The output is a set of approved baseline definitions, and the step is complete when the security owner signs off each class.
Document each baseline and its owner
Record every baseline in a controlled document that names its purpose, the asset classes it covers, the approved settings, any justified deviations, and the accountable owner. Versioning matters here because an assessor will ask which baseline applied on a given date. The output is a baseline document set held under document control, and the step is complete when each baseline has a named owner and an approval record.
Deploy the baseline to in-scope systems
Apply the approved settings to systems through the organization's build pipeline, configuration management tooling or golden images, so that new systems start in the documented state. Existing systems are brought into line through a planned change rather than ad hoc edits. The output is deployment records and the configuration files or images that carry the settings. The step is complete when a sample of systems shows the approved settings and any exceptions are logged with an approved reason.
Monitor for configuration deviation
Run automated checks that compare live systems against the baselines, and act on the findings. Open-source options include Wazuh Security Configuration Assessment, which scans monitored endpoints for misconfigurations using YAML policies that can be extended with custom checks, and Fleet, which asks devices yes or no policy questions through osquery and shows which devices pass or fail. The organization should confirm that a given tool covers its operating systems and asset classes before relying on it. The output is scan and policy results, and the step is complete when failing items are triaged to an owner with a target fix.
Route configuration changes through change management
Require that every change to a baseline, and every deliberate deviation from one, passes through the change process in A.8.32. The request should state the affected assets, the reason, the security impact and the rollback plan, and an authorized approver should decide before the change is made. The output is change records linked to the affected baseline, and the step is complete when monitoring results can be matched to an approved change or flagged as unauthorized.
Coordinate with ticketing for remediation records
Send monitoring findings and approved changes into a ticketing system so that every deviation has a traceable owner, status and closure. GLPI's Assistance module supports tickets, problems and changes following ITIL practices, and Zammad provides a ticket system for requests that arrive by email or other channels. The output is a ticket history that shows who handled each finding and how it closed. The step is complete when a sample of closed tickets links to a change record or a verified fixed state.
Review baselines on a set cycle
Review each baseline on a defined schedule and whenever a major platform change, new threat or audit finding occurs. The reviewer should check whether settings are still appropriate, whether deviations have expired, and whether new asset classes need a baseline. The organization should set its own review interval and record it in the procedure. The output is a dated review record for each baseline with decisions and updated versions, and the step is complete when the review is signed and any changes flow back into the baseline and inventory.

Evidence that passes A.8.9 configuration management

An assessor testing A.8.9 looks for a chain of records: the approved configuration, the inventory it applies to, proof that systems match it, and proof that exceptions and changes were handled. Each card below is one link in that chain, and the set only holds together if the records are refreshed on a schedule between audits.

Approved configuration baselines

These are the documents that state the agreed secure configuration for each class of hardware, operating system, application, cloud service and network device. Each baseline should carry a version number, a named owner, an approval date and a change history showing who altered which setting and why. Check that every baseline names the system types it covers, since an assessor will pick a server or device and trace it back to the baseline it should follow. Store baselines in version control so the history cannot be quietly rewritten.

Asset inventory tied to baselines

A baseline only means something if the organization can show which assets it applies to. The inventory should list each device, virtual machine, container host, SaaS tenant and network element, with its owner, location and the baseline assigned to it. Related guidance sits under A.5.9 Inventory of information and other associated assets. Ask whether the inventory is produced from discovery tools or maintained by hand, because a hand-kept list that omits recently built systems is a common reason configuration evidence fails sampling.

Compliance scan results over time

Scan output shows whether systems actually match their baselines, and the trend matters as much as any single run. Keep dated exports of configuration assessment results, showing passing and failing checks per host and per policy. Wazuh Security Configuration Assessment and Fleet policies can both produce this kind of pass or fail record for endpoints. Set an export schedule that writes results to retained storage, because most tools keep only recent history by default and an assessor may ask for results covering a full audit period.

Approved deviation register

Some systems will never match a baseline exactly, for example a legacy application that needs an older protocol enabled. Each deviation should be recorded with the failing setting, the business reason, the compensating measure, the approver and an expiry date after which it must be reviewed again. Expired exceptions with no decision are a frequent finding. Record every exception as it is granted, not at the next audit, and link each one to the scan result that shows the deviation.

Change records for configuration updates

When a baseline setting changes, or a system is reconfigured to match one, there should be a change record showing the request, the impact assessment, the approval and the test result. Related requirements sit under A.8.32 Change management. Ticketing tools such as GLPI's Assistance module, which follows ITIL-style tickets and changes, can hold these records. Link each change to the baseline version it produced so an assessor can follow a setting from request to production.

Periodic baseline review sign-offs

The control expects configurations to be reviewed, not only set once. Record a dated review of each baseline by its owner, noting whether the standard is still correct, whether new vendor hardening guidance applies and whether any deviations should close. Sign-offs should follow a fixed calendar, and the reviewer should be someone other than the person who maintains the configuration. Missed reviews are easy to spot in a sample, so set reminders in the ticketing system and keep the signed record alongside the baseline it covers.

What meeting A.8.9 configuration management costs

This table breaks the cost of meeting A.8.9 into its main components, showing who is paid, whether each cost is one-time or recurring, and what pushes it up or down. No prices are given here because none were researched for this topic, so use the questions in the final row to request comparable written quotes.

Cost component	Who is paid or who bears it	One-time or recurring	Main drivers and how to keep it down
Tooling or licenses	Software vendor or subscription provider	Usually recurring, sometimes with a one-time setup	Asset classes, cloud accounts and endpoint counts drive licensing. Self-hosted open-source tools such as Wazuh, Fleet and GLPI remove license spend, but hosting and administration remain.
Engineering time to write and deploy baselines	Internal platform or security staff, or an implementation partner under a fixed-scope agreement	Mostly one-time, with updates when systems change	Number of hardware, software, network and cloud configuration types. Reusing hardened templates and infrastructure as code reduces the work per system.
Ongoing evidence upkeep	Internal operations staff	Recurring	Change frequency and the number of systems being monitored. Automated compliance scans that export results reduce manual screenshots and spreadsheets.
Review and testing of baselines	Independent security testers or internal reviewers	Periodic, often tied to major changes or assessment cycles	Scope of security settings reviewed and number of deviations found. Clear baseline ownership and documented exception approvals limit rework.
Auditor sampling time	The certification body or auditor, billed under its own agreement	Recurring within each audit cycle	Number of configurations and changes the auditor samples. Consistent records of baselines, deviations and changes shorten sampling.
Items to request in a written quote	Any party proposing work	Stated once per quote	Ask for: scope by asset class and cloud account, licensed versus self-hosted tooling assumptions, named deliverables, who maintains baselines after handover, evidence formats, assumptions about change frequency, and exclusions such as auditor fees.

Open-source tools that produce configuration evidence

A.8.9 asks for configurations to be set, documented, monitored and reviewed, so the evidence sits in three places: what the device actually runs, what the organization decided it should run, and how changes to that baseline were requested and approved. The four tools below each cover one of these, and none of them replaces the organization's own configuration standard or its ownership of the control.

Endpoint configuration scanning with Wazuh

Wazuh's Security Configuration Assessment scans monitored endpoints for misconfigurations using YAML policies. These policies are mostly based on CIS benchmarks and check files, directories, registry keys and running processes, then recommend remediation. The output shows which checks each endpoint fails, which gives an assessor a dated record of the security settings in place. Before relying on it, confirm that the shipped policies match the organization's own baseline, and add custom policies for settings the benchmarks do not cover. Check the GPL-2.0-only license terms before deployment.

Yes or no device policies with Fleet

Fleet policies are yes or no questions asked of devices as osquery queries, such as whether disk encryption or a host firewall is enabled. The policies page shows which devices in each fleet pass or fail each policy, so the organization can show both its requirement and the current state of each device. A failing policy is only useful if someone owns the remediation and records it. Confirm that each query tests the setting the organization's baseline actually requires, and check the MIT license terms before deployment.

Change requests and approvals in GLPI

The GLPI Assistance module lets users create, follow and process tickets, problems and changes following ITIL practices, with plannings, statistics, recurrent tickets and a Kanban view. For A.8.9, change records show who requested a configuration change, who approved it, and when it was implemented, which links the baseline to its authorized history. Confirm that your change workflow requires approval before a configuration is altered, and review the GPL-3.0-or-later license terms before deployment.

Request intake in Zammad

Zammad is a web-based helpdesk that brings customer communication from email, chat, telephone and social media into one ticket system. It fits the intake side of configuration management: requests for a new setting, an exception or an access change arrive in one queue and keep their history. Zammad does not decide whether a configuration is correct, so the organization still needs its approval rules and a link from each ticket to the resulting change record. Check the AGPL-3.0-only license terms before deployment, including obligations that apply if the software is modified and offered over a network.

Who does what for configuration management

Your organization owns the control. Accountability for A.8.9 sits with the people who run the systems, not with whoever installs the monitoring tools. Your team decides which security settings each class of hardware, software, service and network must carry, approves the baselines, and decides when a system may deviate from them. The partner can draft these, but the decisions and the records of who made them must come from inside the organization.

Owning the baselines: Name a control owner for each baseline, such as a workstation build, a Linux server profile or a cloud account standard, and record the version and approval date.
Approving exceptions: Require a written request for each deviation that states the risk, the compensating measure and an expiry date.
Reviewing exceptions: Re-check open exceptions on a fixed schedule and close those that no longer have a business reason.
Acting on drift: Decide who triages failed policy checks, how quickly high-impact failures are fixed and when a change must go through change management.
Keeping the inventory current: Make sure the asset inventory under A.5.9 covers every system the baselines apply to.

Before an assessment, check that every baseline has a named owner, an approval record and a dated exception register.

Where organizations fall short on configuration management

Most A.8.9 gaps are not missing tools. They are missing links between a baseline, the systems it governs, the people who own deviations and the records that show someone reviewed them. The cards below cover the failure points an assessor is most likely to probe, with a concrete way to close each one.

Baselines stop at servers

Teams often document hardened builds for servers and endpoints but say nothing about cloud account settings, SaaS administration panels, network devices or managed services. A.8.9 covers hardware, software, services and networks, so the configuration scope must match the asset inventory. Check whether your cloud tenancy, identity provider and collaboration tools each have a named baseline with an owner and a version.

Scan results nobody triages

A configuration scan that runs every night but produces findings no one assigns, ranks or closes gives an assessor evidence of monitoring without evidence of action. Each failing check should end in a fix, a documented exception or a risk acceptance. Ask for the last quarter of findings and confirm each has a status, an owner and a closing date.

Exceptions without owners or expiry

Deviations from a baseline are often granted verbally and never recorded, or recorded with no named owner and no end date. Over time, temporary exceptions become permanent configuration. Every exception should record the setting affected, the business reason, the compensating control, the approver and a review date. Check whether a sample of exceptions can still be traced to an approval.

Changes made outside change management

Administrators sometimes adjust firewall rules, feature flags or server settings directly, bypassing the request and approval path. The running configuration then drifts from the documented baseline, and the change record does not exist. Connect configuration monitoring to change tickets so that a detected deviation either matches an approved change or triggers investigation. Confirm that your change records in GLPI or a similar tool cover infrastructure changes, not only application releases.

No evidence of periodic review

A baseline approved once and never revisited does not show that configurations are monitored and reviewed as A.8.9 requires. Assessors look for a dated review cycle, the people who attended it, the changes agreed and the baseline version that resulted. Schedule reviews for each baseline, keep the minutes and confirm that the review frequency is written into the configuration management procedure.

Inventories that lag real assets

A configuration baseline is only as complete as the list of systems it applies to. New cloud accounts, short-lived servers and SaaS tenants added by business teams often appear in no inventory, so they are never scanned or reviewed. Reconcile your asset register against discovery data from cloud APIs, endpoint agents and network scans each cycle. Confirm that the inventory records the owner and the baseline assigned to each asset.

What does A.8.9 configuration management cost and take to meet?

What drives the cost of meeting A.8.9 configuration management?

The cost is driven mainly by how many systems are in scope, how many different platforms and configurations exist, and how much of the baseline work is new. A small estate with one cloud account and standard images costs far less to document and monitor than a hybrid estate with many operating systems, network devices and SaaS services. Cost falls into three parts: internal staff time to define baselines and approve them, tooling (open-source tools carry no license fee but still need hosting, configuration and operating time), and any external help you buy. Some costs are one-time, such as writing baselines and building the first scans, while others recur, such as reviewing deviations, updating baselines and running periodic checks. Ask any partner to split its quote into these parts and to state which items are one-time and which are recurring.

How long does it take to make A.8.9 audit ready?

No duration is supplied for this control, so the time depends on your environment and must be confirmed with your partner and your certification body. The work usually runs in sequence: inventory the systems in scope, agree the configuration baselines, implement and monitor them, then run a review cycle that produces records an auditor can sample. Auditors generally need to see that the process ran, not only that it was designed, so a control that has been operating for only a short time may be harder to show. Ask your certification body how much operating history it expects before a certification audit, and ask your partner to tie its written plan to milestones you can check.

What does A.8.9 need from our internal team?

A.8.9 needs people who own the systems, not only people who run the tools. Your team must decide what a secure configuration means for each platform, approve baselines, and accept or reject deviations. System owners must act on failed checks and record changes. Security and compliance staff must define the review cadence and keep the evidence. Expect the control to touch infrastructure, platform engineering, application owners and change management. The organization remains responsible for its controls, so these decisions cannot be delegated to an outside partner, even when the partner prepares the technical work.

Can a small team run A.8.9 configuration management on its own?

A small team can run A.8.9 alone if its estate is small and standardized, and if one person can own baselines and review deviations. Open-source tools such as Wazuh, Fleet and GLPI can cover parts of the work, but each needs configuration, hosting, updates and someone to read the results. The main risk for a small team is not the tooling but the review routine: when the same two people handle engineering, incidents and audits, reviews slip. If you cannot name an owner and a review cadence, bring in outside help for the setup phase and keep the recurring review in-house.

What should we ask an implementation partner to include in a written scope?

A written scope should name the systems in scope, the baselines to be written or adopted, the tools to be deployed and hosted, and the evidence each deliverable produces. Ask the partner to list what it will hand over, such as a configuration inventory, baseline documents, policy rules, scan configurations, dashboards and a review procedure. Ask which items are the client's responsibility, such as approving baselines or acting on failed checks. Require a statement of what is excluded, a change process for scope, and the acceptance criteria for each deliverable. Ask for the commercial structure in writing, including what is one-time and what is a retainer. DeployOpen agrees scope, deliverables and timelines in writing before work starts.

Can a consultant or partner issue the A.8.9 evidence or the ISO 27001 certificate?

No. A consultant or implementation partner can prepare systems, configurations and evidence, but it cannot issue an audit report or a certificate. Only an accredited certification body can certify your ISMS, and it reaches its conclusion by sampling your records and testing your controls. DeployOpen prepares systems, controls and evidence for assessments and does not issue audit reports, attestations or certifications. Before you hire anyone, confirm with your certification body what evidence it will accept for A.8.9 and check that the certification body is accredited through the IAF CertSearch database.

How DeployOpen scopes and prepares configuration evidence

DeployOpen plans, implements and documents self-hosted open-source platforms inside the client's own infrastructure, so configuration baselines and their evidence are produced where the systems run. We prepare the systems, settings and records that an assessor will sample; the organization owns its controls and an independent certification body decides conformity.

How we scope

Agree in writing which hardware, operating systems, services and network devices fall inside the A.8.9 configuration scope.
Confirm which platforms need security configuration assessment and which settings are owned by the organization or by a vendor.
Record the baseline sources, such as internal standards or CIS benchmarks, the organization chooses to adopt for each asset class.

How we build

Define documented baseline configurations for each in-scope asset class, including security settings and approved deviations.
Deploy scanning and policy checks, such as Wazuh Security Configuration Assessment or Fleet policies, against those baselines.
Connect configuration drift findings to change records in the helpdesk or ITSM tool so that remediation is traceable.

How we hand over

Deliver the written configuration standards, asset inventory links and review procedure as documents the organization can maintain.
Provide exported scan and policy results, with dates and owners, that show configurations were monitored over the review period.
Walk the internal team through evidence sampling so they can answer an auditor's questions about specific systems.

How we support

Offer ongoing support, upgrades and continuous testing as a retainer after the fixed-scope engagement ends.
Review baseline exceptions and policy updates on the schedule the organization agrees in its written scope.
Confirm with the organization and its certification body which evidence formats they accept before the audit begins.