Skip to content
compliancebase
ISO 27001A.8 — Configuration management

A.8.9

Configuration management

ISO 27001 · ISO/IEC 27001:2022 · Last verified July 2026

Objective

Establish, document, implement, monitor, and review configurations — including security baselines — for hardware, software, services, and networks.

Points of focus

  • Security baselines defined for cloud accounts, container images, and OS builds
  • Configuration changes go through version control and peer review, not console clicks
  • Drift between declared and running state is detected automatically
  • Baselines are updated when new services or regions are onboarded
  • Emergency out-of-band changes are logged and reconciled back into IaC

Implementation notes

Treat every production surface — cloud accounts, Kubernetes clusters, VM images, network ACLs, and SaaS platform settings (e.g. GitHub org policies, Okta tenant config) — as code with a single source of truth. Build golden images and base container layers from a documented hardening checklist (CIS or your own distilled version) and rebuild them on a fixed cadence rather than patching running instances by hand. Wire drift detection into the same alerting pipeline used for security incidents so unauthorized changes get triaged, not archived in a dashboard. When engineers must make an emergency console change, require a same-week follow-up pull request that reconciles the state; track these as a named exception category so the volume itself becomes a signal at management review. Extend the same discipline to SaaS-of-SaaS configuration — identity provider policies, CI/CD runner permissions, and data-warehouse access grants — since these are frequently the systems attackers target first and the ones most often left to manual, undocumented tweaks.

Audit tip: Bring up a real Terraform module for a production resource, show the linked pull request with an approving reviewer, and then show the drift-detection dashboard covering the same resource for the last 90 days — that three-part chain is far stronger than a written policy alone.

Evidence auditors typically request:

  • Terraform/CloudFormation modules with a CODEOWNERS-approved baseline for prod accounts
  • CIS Benchmark or internal hardening checklist applied to golden AMIs or base container images
  • Drift-detection tool output (AWS Config, driftctl, or Terraform plan diffs) from the last quarter
  • Kubernetes admission-controller policy (OPA/Gatekeeper or Kyverno) blocking non-compliant pod specs
  • Pull request history showing reviewer approval for a sampled infrastructure change

Common gaps

  • Console changes made directly in AWS/GCP during an incident are never back-ported into Terraform, so the repo silently diverges from production
  • A hardening checklist exists for the base AMI but new services get spun up from unpatched community images
  • Drift-detection alerts fire into a channel nobody monitors, so weeks-old unauthorized changes go unnoticed

Cross-Framework Mapping

FrameworkRequirementImplementation note
ISO 27001A.8.9This control
SOC 2CC8.1Related Trust Services Criteria themes — map in your crosswalk; not identical requirements.

Primary sources

Frequently Asked Questions

It's necessary but not sufficient. Auditors also want proof the declared state matches the running state — drift detection output, not just the module source — and evidence that changes went through review before merge.

Document them as a known exception with a remediation plan and compensating controls (change tickets, periodic manual configuration review) rather than pretending they're covered by the same automated baseline.

Tenant-level security settings — SSO enforcement, sharing defaults, API scopes — count. Export or screenshot the settings panel on a schedule and version those exports so you can show what changed and when.

A short policy stating ownership, tooling, and review cadence is useful, but the substance auditors sample is the IaC repo, review history, and drift reports — write the policy to match what engineering actually does, not the reverse.

Framework versions referenced in this page:

  • ISO/IEC 27001 — ISO/IEC 27001:2022

Last verified: July 2026 · Primary sources linked above