How to Keep Your Systems Secure, Consistent, and Under Control
ISO 27001 Control 8.9 – Configuration management – is all about making sure your IT estate is deliberately configured, not left in whatever state the last person happened to leave it in.
If you don’t manage configurations properly, you get:
- servers with forgotten open ports
- cloud resources deployed with insecure defaults
- admin accounts everywhere
- “temporary” settings that never get rolled back
Attackers love misconfigurations. This control is about making them much harder to find – and making your environment easier to run and easier to audit.
What ISO 27001 Control 8.9 Is Really Asking For
In plain terms, ISO 27001 Control 8.9 – Configuration management expects you to:
- Define who owns configuration management and what “good” looks like
- Use standard, secure baselines for systems, services and networks
- Keep a record of actual configurations and any changes over time
- Make sure changes are done through a controlled process (not ad-hoc tweaks)
- Monitor and enforce configurations so systems don’t quietly drift out of compliance
- Extend all of this to cloud, on-prem, network and application configurations
An auditor will typically ask:
- “Show me your build standards / baseline configurations.”
- “How do you know systems still match those baselines?”
- “What happens if someone changes a setting directly on a server or in the cloud console?”
The guidance below gives you a practical way to answer those questions.
Step 1 – Define Your Configuration Management Policy, Scope and Roles
Start by being very clear about what’s in scope and who’s responsible.
I recommend your configuration management approach covers at least:
- Servers (on-prem and cloud)
- Endpoints (laptops, desktops, mobiles where relevant)
- Network devices (firewalls, routers, switches, VPNs, WAFs)
- Cloud services (IaaS, PaaS, key security controls like IAM and logging)
- Core applications and platforms (databases, identity providers, email, etc.)
For ISO 27001 Control 8.9, make sure your policy and procedures:
- Name clear owners
- IT operations for infrastructure
- Security for configuration standards and security options
- Application owners for app-specific settings
- State that:
- All systems must be built from approved configuration templates/baselines
- No configuration changes are made outside the change management process (linking to Control 8.32)
- Every asset must have a named technical owner
- Require:
- Approval for configuration changes that affect security, performance or availability
- Documentation of configurations (or templates) somewhere central
- Regular reviews of configuration standards to keep up with threats and vendor guidance
This doesn’t need to be a huge document – just clear, specific and enforceable.
Step 2 – Build Secure Baseline Configurations
Baseline configurations are at the heart of ISO 27001 Control 8.9. They’re the “known good” starting point for each type of system.
I’d recommend:
Use recognised hardening guidance
Base your templates on:
- Vendor security benchmarks
- Independent guidance (e.g. CIS Benchmarks, NCSC patterns, vendor secure-by-default docs)
Then adapt them to your environment and risk appetite.
Include key security settings as standard
For each platform or device type, your baseline should cover things like:
- Accounts and privileges
- Minimal number of local admin/privileged accounts
- No generic admin accounts where you can avoid them
- Clear rules for service accounts
- Services and features
- Disable unused or insecure services, ports and protocols
- Turn off remote access methods you don’t actually need
- Access and session controls
- Session timeouts and automatic log-off for idle sessions
- Screen lock policies for endpoints
- MFA enforced for privileged access
- Security and logging
- Standard anti-malware and EDR settings
- Logging, audit and time synchronisation configured
- Security agent deployment (AV, EDR, backups, monitoring) as default
- Vendor defaults
- All default passwords changed on first use
- Default SNMP communities, web consoles and management interfaces hardened or disabled
- Data protection
- Encryption at rest enabled where appropriate
- Secure protocols enforced (e.g. TLS only, no legacy SSL or insecure ciphers)
- Compliance and hygiene
- Licence key / software compliance tracking where needed
- Automatic updates/patching configured (aligned with your patch management process)
Store these baselines as version-controlled documents or configuration-as-code, so you can see what changed and when.
Step 3 – Control and Document Configuration Changes
ISO 27001 Control 8.9 and Control 8.32 (Change management) should fit together cleanly.
Practically, that means:
- Every configuration change is traceable
- Recorded in a ticketing system or change tool
- Linked to a specific asset or configuration item (CMDB entry if you have one)
- Configuration records include:
- Asset identifier and owner
- Current version or profile applied
- Date of last change and who made it
- Link to change request / incident / problem record
- Any non-standard settings and the justification
- Use tools where you can
- Configuration management databases (CMDBs)
- Infrastructure as Code (IaC) repositories for servers/cloud
- Group Policy / MDM profiles / configuration profiles for endpoints
- Restrict who can change configurations
- Use role-based access control for consoles and management tools
- No shared “admin” accounts making manual tweaks with no attribution
- Prefer changes through pipelines and management tools, not direct console hacking
- Protect your configuration records
- Store templates and IaC in version control (Git, etc.)
- Lock down write access to configuration repos and tools
- Back up configuration data regularly
The aim is that if something breaks, you can ask “what changed?” – and get a clear answer.
Step 4 – Monitor for Configuration Drift and Enforce Compliance
It’s not enough to set a baseline once and hope for the best. ISO 27001 Control 8.9 expects ongoing monitoring and review.
I recommend you:
Use automated tools where possible
- System management / configuration tools (e.g. MDM, GPO, desired state configuration, cloud security posture tools)
- Vulnerability scanners that also detect common misconfigurations
- Cloud security tools that compare your settings to security baselines
These can:
- Report on compliance with your baselines
- Detect unexpected changes (especially on critical systems)
- Automatically remediate some deviations
Regularly review and audit configurations
- Run periodic configuration reviews (e.g. quarterly) on:
- Critical servers and databases
- Firewalls, VPNs, network gear
- Cloud control planes (IAM, logging, storage permissions)
- Check for:
- New admin accounts or privilege creep
- Disabled security features (AV, logging, firewalls)
- Open ports, weak ciphers, exposed management interfaces
- Cloud resources with public access or overly broad permissions
Investigate unauthorised changes
If your tools detect a change that didn’t go through the change process:
- Treat it as a potential security incident
- Investigate who made the change, from where, and why
- Decide whether you need to roll back to a known good state
- Capture lessons learned – update your templates or controls if needed
This is exactly the kind of behaviour auditors like to see under ISO 27001 Control 8.9.
Step 5 – Apply Configuration Management to Cloud and Hybrid Environments
Cloud does not magically remove the need for configuration management – if anything, it increases it.
For cloud services under ISO 27001 Control 8.9:
- Define your shared responsibility model
- What the cloud provider secures
- What you must configure and maintain (IAM, network rules, storage access, logging, encryption, etc.)
- Use Infrastructure as Code (IaC)
- Templates (e.g. Terraform, ARM/Bicep, CloudFormation) become your baseline configurations
- Changes go via version control and pull requests, not point-and-click in a browser
- Easier rollback and repeatable deployments
- Use cloud security baselines
- Vendor security benchmarks and “secure by default” recommendations
- Predefined policies for:
- Storage encryption and access
- Logging and monitoring
- Network segmentation and security groups
- Identity and access management guardrails
- Monitor continuously
- Enable and review cloud activity logs (who changed what, where, and when)
- Use cloud security posture management tools to detect drift and misconfigurations
- Alert on high-risk changes (e.g. storage buckets made public, disabling logging, privilege escalation)
Treat cloud configurations like code: reviewed, tested, versioned and monitored.
Step 6 – Link Configuration Management to Incident Response and Vulnerability Management
Configuration management isn’t just housekeeping – it’s a key part of how you prevent and respond to incidents.
To align with ISO 27001 Control 8.9:
- Include misconfigurations as common incident root causes in your incident response plans
- Use incident findings to:
- Update configuration baselines
- Add new checks or alerts
- Tighten change processes where needed
- Use vulnerability and threat intelligence to adjust configurations
- For example, disabling a protocol or tightening a cipher suite in response to a new vulnerability
- Raising the baseline for certain system types following attack trends
- Implement safe rollback mechanisms
- Ability to revert to last known good configuration quickly
- Documented playbooks for rolling back high-risk changes that cause instability
This makes configuration management an active part of your defence, not just a static document.
Step 7 – Document, Train and Continuously Improve
Finally, ISO 27001 Control 8.9 expects configuration management to be embedded in how you work, not treated as a one-off project.
Make sure you:
- Maintain clear, accessible documentation for:
- Configuration standards / baselines
- Tools and processes used to enforce them
- Roles and responsibilities
- Integrate configuration management with:
- Asset management (you can’t manage what you don’t know you have)
- Change management and release processes
- Supplier management where third parties manage part of your estate
- Train relevant staff
- Admins, engineers and developers on:
- Your configuration standards
- How to request and implement changes properly
- Why “quick fixes” on live systems are a risk
- Admins, engineers and developers on:
- Use metrics and KPIs
- Percentage of systems compliant with baseline
- Number of unauthorised configuration changes detected
- Time taken to remediate configuration drift
- Incidents caused by misconfigurations (aiming to see this fall over time)
- Review and refine regularly
- Update templates and standards as technology and threats evolve
- Retire settings and practices that no longer make sense
Quick Implementation Checklist for ISO 27001 Control 8.9
You’re in a good place for ISO 27001 Control 8.9 – Configuration management if you can say “yes” to most of these:
- We have a configuration management policy/standard that defines scope, roles and expectations.
- We maintain secure baseline configurations for key platforms (servers, endpoints, network, cloud, applications).
- All new systems are built from those approved baselines, not ad-hoc builds.
- All configuration changes go through a formal change process and are recorded.
- We keep records of actual configurations (or IaC/templates) and who changed them, when and why.
- We use tools to monitor configuration compliance and detect drift or unauthorised changes.
- Misconfigurations are treated as potential security incidents and feed back into continuous improvement.
- Cloud configurations are managed via IaC and guardrails, not just manual console changes.
- Staff who can change configurations are trained in our standards and processes.
- We review configuration standards and results regularly and can show auditors real examples.
If you can back those points up with screenshots, reports and change records, you’ll have strong, practical evidence that ISO 27001 Control 8.9 isn’t just on paper – it’s how you actually run your environment.
Explore the ISO 27001 Control Group Purposes