What is ISO 27001 Annex A 8.9 – Configuration Management?
ISO 27001 Annex A 8.9 focuses on establishing, documenting, implementing, monitoring, and maintaining appropriate configurations for information systems and technology assets.
Configuration management is about making sure that systems are configured securely, consistently, and according to approved requirements.
It can apply to:
- Servers
- Laptops and desktops
- Network devices
- Firewalls
- Routers and switches
- Databases
- Applications
- Cloud infrastructure
- Virtual machines
- Containers
- Kubernetes environments
- Security tools
- SaaS platforms
- Mobile devices
- Identity systems
- Backup systems
Configuration settings can include:
- Authentication settings
- Access permissions
- Firewall rules
- Network ports
- Encryption
- Logging
- Monitoring
- Security controls
- Operating-system settings
- Application settings
- Database settings
- Cloud security settings
- Backup settings
- Remote-access settings
Simple Explanation
Know how your important systems should be configured, make those configurations secure, control changes, and periodically check that the actual configuration remains appropriate.
Why is Configuration Management Important?
A system can have the latest security patches and still be insecure because of an incorrect configuration.
For example:
- A cloud storage bucket is publicly accessible.
- A firewall allows unnecessary internet traffic.
- An administrator account does not have MFA.
- Logging has been disabled.
- A database is accessible from unnecessary networks.
- An unnecessary service is running.
- A production server allows unrestricted administrative access.
- A security control was accidentally turned off.
These are configuration-related security risks.
Example
Approved Security Configuration
↓
Implementation
↓
Controlled Changes
↓
Monitoring
↓
Configuration Drift?
↙ ↘
No Yes
↓ ↓
Continue Investigate
↓
Correct / Approve
↓
Verify
Simple Principle
Security is not only about what software you use. It is also about how that technology is configured.
What Does Annex A 8.9 Require?
The organization should establish, document, implement, monitor, and review configurations for relevant:
- Hardware
- Software
- Services
- Networks
- Applications
- Cloud environments
- Information-processing systems
Configuration requirements should consider:
- Information-security requirements
- Business requirements
- Risk
- Asset criticality
- Information sensitivity
- Technology architecture
- Vendor recommendations
- Security standards
- Legal requirements
- Regulatory requirements
- Contractual/customer requirements
Configurations should also be protected against:
- Unauthorized changes
- Accidental changes
- Incorrect changes
- Insecure changes
- Configuration drift
The organization should use a level of configuration management that is appropriate and proportionate to its risks.
ISO 27001 does not require one specific configuration-management product or tool.
What is a Secure Configuration?
A secure configuration is an approved configuration that applies appropriate security settings to a particular system.
For example, a company laptop may have:
- Supported operating system
- Disk encryption
- Automatic screen lock
- Endpoint protection
- Host firewall
- Security updates
- Restricted administrator privileges
- Approved software
- Secure authentication
A production database will have different security requirements.
Therefore:
A secure configuration depends on the purpose, technology, risk, and information being processed.
What is a Configuration Baseline?
A configuration baseline defines the approved configuration or minimum security requirements for a system or technology category.
For example:
Production Server Baseline
| Configuration | Expected Requirement |
|---|---|
| Operating System | Supported version |
| Firewall | Enabled |
| Unnecessary Services | Disabled |
| Administrative Access | Restricted |
| Authentication | Appropriate authentication controls |
| Logging | Enabled |
| Encryption | Applied where required |
| Remote Access | Restricted |
| Security Updates | Managed |
| Configuration Changes | Controlled |
The baseline becomes the reference point for configuration reviews.
What is Configuration Drift?
Configuration drift occurs when the actual configuration of a system gradually differs from the approved configuration.
For example:
Approved Configuration
↓
Secure Firewall Rules
↓
Administrator Makes Temporary Change
↓
Temporary Rule Remains
↓
Additional Service Enabled
↓
Logging Configuration Changed
↓
Actual Configuration ≠ Approved Configuration
Configuration drift can happen because of:
- Manual changes
- Emergency troubleshooting
- Software installations
- Infrastructure changes
- Incorrect automation
- Different administrators
- Cloud-console changes
- Temporary exceptions
- Poorly documented changes
Why is drift dangerous?
Because an organization may believe that a system is securely configured when the actual configuration has changed.
Configuration Management vs Configuration Drift
| Term | Meaning |
|---|---|
| Configuration Management | Overall process for managing system configurations |
| Configuration Baseline | Approved configuration |
| Configuration Change | Modification to a configuration |
| Configuration Monitoring | Checking configuration status |
| Configuration Drift | Difference between approved and actual configuration |
Activities Required to Implement Annex A 8.9
1. Identify Systems That Require Configuration Management
Start by identifying important technology.
Examples:
- Production servers
- Cloud infrastructure
- Databases
- Firewalls
- Network devices
- Employee endpoints
- Identity platforms
- Security tools
- Applications
- Containers
- Kubernetes clusters
- Backup systems
Not every device necessarily needs the same level of configuration control.
A critical production database should generally receive more attention than a low-risk office device.
2. Identify Security-Relevant Configuration Settings
Determine which settings are important from an information-security perspective.
Server
Consider:
- Firewall
- Network ports
- Services
- Authentication
- Administrative access
- Logging
- Encryption
- Remote access
Cloud
Consider:
- IAM permissions
- Public access
- Security groups
- Encryption
- Logging
- Network exposure
- Storage permissions
- Security monitoring
Endpoint
Consider:
- Disk encryption
- Screen locking
- Endpoint protection
- Firewall
- OS version
- Administrator privileges
- Application installation
3. Establish Configuration Baselines
Create appropriate baseline standards for important technology.
For example:
Cloud Production Baseline
MFA for privileged users
+
Least-privilege IAM
+
Restricted network access
+
Encryption
+
Security logging
+
Monitoring
+
No unintended public exposure
The baseline should be documented and approved by the appropriate owner.
4. Use Appropriate Security Standards
Organizations may use external security benchmarks or internal standards.
Examples include:
- CIS Benchmarks
- Vendor hardening guidelines
- Cloud-provider security recommendations
- Operating-system security baselines
- Internal security standards
The organization should select standards appropriate to its technology and risk.
5. Control Configuration Changes
Configuration changes should be appropriately controlled.
A typical process is:
Change Request
↓
Business / Security Requirement
↓
Risk Assessment
↓
Approval
↓
Testing
↓
Implementation
↓
Verification
↓
Documentation
Emergency changes may require an expedited process, but should still be documented and reviewed appropriately.
6. Restrict Configuration Privileges
Only authorized personnel should be able to modify critical configurations.
For example:
| Configuration | Typical Responsible Role |
|---|---|
| Firewall | Network/Security Administrator |
| Cloud IAM | Authorized Cloud Administrator |
| Production Database | DBA |
| Endpoint Security | IT/Security Administrator |
| Kubernetes | DevOps/SRE |
| Production Application | Authorized Development/Operations Team |
This is closely connected with A.8.2 – Privileged Access Rights.
7. Protect Configuration Information
Configuration information can itself be sensitive.
Examples:
- Network diagrams
- Firewall configurations
- Infrastructure-as-Code
- Application configuration
- Database configuration
- Security configuration
- Deployment configuration
Some configuration files may contain sensitive information such as:
- API keys
- Passwords
- Tokens
- Certificates
- Connection strings
Secrets should not be stored insecurely in configuration files or source-code repositories.
8. Use Infrastructure as Code Where Appropriate
Cloud-native organizations can use Infrastructure as Code (IaC) to manage configurations.
Examples include:
- Terraform
- CloudFormation
- Ansible
- Kubernetes manifests
IaC can improve:
- Consistency
- Repeatability
- Version control
- Reviewability
- Auditability
A typical workflow can be:
Infrastructure Code
↓
Pull Request
↓
Peer Review
↓
Security Checks
↓
Approval
↓
Automated Deployment
↓
Verification
However:
Automation does not automatically make a configuration secure.
The code and resulting infrastructure still need appropriate security controls.
9. Monitor Configuration Changes
Important systems should be monitored for relevant configuration changes.
Possible mechanisms include:
- Cloud audit logs
- Configuration-monitoring tools
- Endpoint-management systems
- SIEM
- Infrastructure monitoring
- Security alerts
- Configuration-compliance tools
The objective is to identify:
- Unauthorized changes
- Unexpected changes
- Security-control changes
- Configuration drift
10. Detect Configuration Drift
Organizations should periodically or continuously compare actual configurations with approved requirements where appropriate.
For example:
Approved Baseline
+
Actual Configuration
↓
Comparison
↓
Deviation Found
↓
Risk Assessment
↓
Authorized?
↙ ↘
Yes No
↓ ↓
Record Correct
A difference is not necessarily a security incident.
It may be:
- Authorized
- Temporary
- Planned
- Required for business purposes
- Incorrect
- Unauthorized
The organization should assess the difference appropriately.
11. Manage Temporary Changes
Temporary changes are a common source of configuration drift.
Example:
A firewall port is opened temporarily for troubleshooting.
A better process is:
Temporary Change → Expiry Date → Review → Remove/Revert
Temporary security exceptions should not become permanent simply because nobody remembered to remove them.
12. Review Configurations Periodically
Critical configurations should be reviewed according to risk.
Reviews may cover:
- Firewall rules
- Cloud IAM
- Security groups
- Database settings
- Endpoint policies
- Logging
- Encryption
- Network configurations
- Security tools
- Public exposure
The review frequency should be appropriate to the organization’s environment and risk.
Startup Example
50-Person SaaS Startup
Imagine a startup using:
- AWS
- GitHub
- Kubernetes
- PostgreSQL
- Cloudflare
- Google Workspace
- Windows/Mac endpoints
- EDR
- CI/CD
Initially, administrators manually configure the environment.
Over time:
Administrator 1
↓
Changes Firewall
Administrator 2
↓
Changes AWS Security Group
Developer
↓
Changes Kubernetes Configuration
DevOps
↓
Changes Production Database Setting
After several months, nobody has a clear answer to:
What is the approved production configuration?
This creates configuration-management risk.
Improved Approach
The startup establishes:
- Configuration baselines
- Configuration ownership
- Infrastructure as Code
- Change management
- Restricted administrative access
- Configuration monitoring
- Periodic reviews
Now the company can demonstrate:
What should the configuration be?
What is the configuration today?
Who changed it?
Why was it changed?
Was the change authorized?
Example Cloud Configuration Baseline
A startup may define requirements such as:
| Area | Example Requirement |
|---|---|
| IAM | Least privilege |
| Privileged Access | MFA |
| Storage | No unintended public access |
| Encryption | Enabled where required |
| Logging | Security-relevant logging enabled |
| Network | Restricted inbound access |
| Security Groups | Only required ports |
| Admin Access | Restricted |
| Secrets | Stored in approved secret-management solution |
| Monitoring | Security-relevant events monitored |
| Backup | Configured according to business requirements |
These are examples, not universal ISO 27001 requirements.
Configuration Management Register
A simple register can be sufficient for a startup:
| ID | System | Owner | Baseline | Criticality | Review |
|---|---|---|---|---|---|
| CM-001 | AWS Production | DevOps | Cloud Baseline | Critical | Monthly |
| CM-002 | Production DB | DBA | Database Baseline | Critical | Monthly |
| CM-003 | Firewall | IT/Security | Network Baseline | High | Monthly |
| CM-004 | Employee Devices | IT | Endpoint Baseline | High | Quarterly |
| CM-005 | Kubernetes | DevOps | Container Baseline | Critical | Monthly |
Configuration Change Register
| Change ID | System | Change | Reason | Approval | Status |
|---|---|---|---|---|---|
| CH-001 | Firewall | Add rule | New application | Approved | Completed |
| CH-002 | AWS | Modify security group | Application deployment | Approved | Completed |
| CH-003 | Database | Parameter change | Performance requirement | Approved | Completed |
| CH-004 | Kubernetes | Configuration update | New release | Approved | Completed |
Configuration Review Checklist
| Configuration Area | Review Question |
|---|---|
| Authentication | Are appropriate authentication controls enabled? |
| Privileged Access | Is administrative access restricted? |
| Firewall | Are firewall rules appropriate? |
| Network Ports | Are unnecessary ports disabled? |
| Encryption | Is required encryption enabled? |
| Logging | Is required logging enabled? |
| Monitoring | Is security monitoring operational? |
| Public Exposure | Is there unintended internet exposure? |
| Cloud Storage | Is access appropriately restricted? |
| Secrets | Are secrets protected? |
| Software | Are approved versions/configurations used? |
| Changes | Are configuration changes controlled? |
| Baseline | Is the baseline current and approved? |
Audit Evidence for Annex A 8.9
An auditor may request evidence such as:
Policies
- Configuration Management Policy
- Configuration Management Procedure
- Secure Configuration Standard
- Change Management Procedure
Baselines
- Server configuration baseline
- Endpoint configuration baseline
- Network configuration baseline
- Cloud configuration baseline
- Database configuration baseline
Registers
- Configuration register
- Asset inventory
- Software inventory
- System inventory
Technical Evidence
- Configuration reports
- Cloud configuration reports
- Infrastructure-as-Code repositories
- Security configuration screenshots/reports
- Configuration monitoring reports
Change Evidence
- Change requests
- Approvals
- Pull requests
- Deployment records
- Emergency change records
Review Evidence
- Configuration review reports
- Configuration-drift reports
- Corrective-action records
- Exception records
ISO 27001 Annex A 8.9 Audit Checklist
| Question | Yes/No | Evidence |
|---|---|---|
| Are important systems identified? | Asset inventory | |
| Are security-relevant configurations identified? | Configuration register | |
| Are configuration baselines established? | Baselines | |
| Are secure configuration standards defined? | Security standard | |
| Are configuration changes controlled? | Change records | |
| Are configuration changes authorized? | Approvals | |
| Is configuration access restricted? | Access records | |
| Are configuration files appropriately protected? | Repository/access controls | |
| Are important configurations monitored? | Monitoring reports | |
| Is configuration drift identified? | Drift reports | |
| Are temporary changes controlled? | Change records | |
| Are configurations periodically reviewed? | Review reports | |
| Are unauthorized changes investigated? | Investigation records | |
| Are exceptions documented? | Exception register | |
| Are configuration owners defined? | Configuration register |
Common Mistakes
1. No Configuration Baseline
If there is no approved configuration, it becomes difficult to determine whether a system is configured appropriately.
2. Everyone Has Administrative Access
Too many people being able to modify critical configurations increases the risk of accidental or unauthorized changes.
3. Manual Changes Without Documentation
Undocumented manual changes are a major source of configuration drift.
4. Temporary Changes Become Permanent
Temporary firewall or security exceptions should have an owner and appropriate expiry/review mechanism.
5. Ignoring Cloud Configuration
Cloud environments can change rapidly.
Cloud configuration management is therefore particularly important for SaaS startups.
6. Secrets Stored in Configuration Files
API keys, passwords and tokens should be appropriately protected.
7. No Configuration Monitoring
Having a baseline without checking the actual environment can leave configuration drift undetected.
8. Configuration Knowledge Exists Only With One Person
Configuration information should be documented and accessible to appropriately authorized personnel.
9. Configuration Management Is Confused With Change Management
These controls are related but different.
Configuration management establishes and maintains appropriate configurations.
Change management controls how changes are introduced.
Configuration Management for Startups
A startup does not need a large enterprise configuration-management program to implement A.8.9 effectively.
Start with the systems that matter most.
Step 1 — Identify Critical Systems
Focus on:
- Production infrastructure
- Cloud accounts
- Databases
- Firewalls
- Identity systems
- Security tools
- Critical endpoints
Step 2 — Define Baselines
Document the important security settings.
Step 3 — Restrict Access
Only authorized administrators should modify critical configurations.
Step 4 — Control Changes
Connect configuration changes with the organization’s change-management process.
Step 5 — Automate Where Practical
Use:
- Infrastructure as Code
- Version control
- Configuration-management tools
- Cloud-security tools
- Automated security checks
Step 6 — Monitor
Identify unexpected or unauthorized configuration changes.
Step 7 — Review
Periodically verify that configurations remain aligned with approved requirements.
Cloud-Native Startup Approach
For a cloud-first SaaS company, A.8.9 can be integrated into DevSecOps.
Architecture
↓
Security Baseline
↓
Infrastructure as Code
↓
Pull Request
↓
Security Validation
↓
Approval
↓
Deployment
↓
Configuration Monitoring
↓
Drift Detection
↓
Corrective Action
This provides a practical connection between:
Security + Development + Operations + Compliance
Configuration Management and DevSecOps
Configuration management should ideally become part of the normal technology-development process rather than a separate compliance exercise.
For example:
Code
↓
Infrastructure Configuration
↓
Security Checks
↓
Peer Review
↓
Approval
↓
CI/CD
↓
Deployment
↓
Monitoring
This allows configuration security to be considered before and after deployment.
A.8.9 vs A.8.8 – Management of Technical Vulnerabilities
These controls are closely related.
| Control | Primary Focus |
|---|---|
| A.8.8 | Technical vulnerabilities |
| A.8.9 | Configuration management |
Example
A server is running vulnerable software:
A.8.8
The server has an unnecessary service enabled or an insecure firewall rule:
A.8.9
A single security issue can involve both controls.
A.8.9 vs A.8.2 – Privileged Access Rights
| Control | Focus |
|---|---|
| A.8.2 | Who has privileged access |
| A.8.9 | How technology is configured |
For example:
A DevOps engineer has production administrator access:
A.8.2
That administrator changes a production security configuration:
A.8.9
A.8.9 vs A.8.32 – Change Management
| Control | Focus |
|---|---|
| A.8.9 | Establishing and maintaining appropriate configurations |
| A.8.32 | Managing changes |
Example:
Configuration requirement: Production database logging must remain enabled.
Change management: A change disabling that logging must be appropriately assessed, authorized, implemented, and reviewed.
A.8.9 vs A.8.14 – Redundancy of Information Processing Facilities
| Control | Focus |
|---|---|
| A.8.9 | Configuration |
| A.8.14 | Redundancy |
Securely configuring a production environment is part of A.8.9.
Creating redundant infrastructure to maintain availability is related to A.8.14.
Questions an Auditor May Ask
1. What are your critical systems?
Show the asset and configuration inventory.
2. How do you define a secure configuration?
Show the applicable configuration baseline.
3. Who can change production configurations?
Show privileged-access controls.
4. How are configuration changes controlled?
Show change records and approvals.
5. How do you identify unauthorized changes?
Show monitoring, alerts, or review mechanisms.
6. How do you manage cloud configurations?
Show cloud security baselines and configuration monitoring.
7. How do you prevent configuration drift?
Show automation, monitoring, or periodic reviews.
8. How do you manage emergency changes?
Show the emergency-change process and subsequent review.
9. How do you protect configuration files?
Demonstrate access restrictions and protection of sensitive configuration information.
10. How often do you review configurations?
Show the organization’s defined review approach and completed reviews.
Useful Resources
Organizations implementing Annex A 8.9 may maintain:
- Configuration Management Policy – [Insert Draft Document Link]
- Configuration Management Procedure – [Insert Draft Document Link]
- Secure Configuration Standard – [Insert Draft Document Link]
- Server Hardening Checklist – [Insert Draft Document Link]
- Endpoint Configuration Baseline – [Insert Draft Document Link]
- Cloud Security Configuration Baseline – [Insert Draft Document Link]
- Network Configuration Baseline – [Insert Draft Document Link]
- Database Security Configuration Baseline – [Insert Draft Document Link]
- Configuration Register – [Insert Draft Document Link]
- Configuration Review Checklist – [Insert Draft Document Link]
- Configuration Exception Form – [Insert Draft Document Link]
- Configuration Management Audit Checklist – [Insert Draft Document Link]
Startup-Focused Quick Summary
A startup can implement Annex A 8.9 with a simple lifecycle:
Identify → Baseline → Restrict → Change → Monitor → Review → Correct
Identify
Know which systems and configurations are important.
Baseline
Define the approved security configuration.
Restrict
Limit configuration privileges.
Change
Use appropriate change management.
Monitor
Look for unexpected configuration changes.
Review
Compare actual configurations with approved requirements.
Correct
Fix configuration drift and document legitimate exceptions.
Startup-Focused Final Takeaway
ISO 27001 Annex A 8.9 is fundamentally about maintaining control over how technology is configured.
A startup should be able to answer:
What should our important systems look like?
What do they actually look like?
Who can change them?
How do we know when they change?
A mature configuration-management process connects:
Configuration Baseline → Privileged Access → Change Management → Monitoring → Drift Detection → Verification
For a cloud-native SaaS company, this can be implemented efficiently using secure configuration baselines, Infrastructure as Code, version control, pull-request reviews, cloud-security monitoring, and periodic configuration assessments.
The objective is not to document every technical setting in the organization.
The objective is to ensure that security-critical configurations are defined, controlled, monitored, and maintained according to risk.
One-Line Summary
ISO 27001 Annex A 8.9 ensures that security-relevant technology configurations are defined, controlled, monitored, and maintained so systems remain securely configured over time.