Decide what good looks like, build it that way, and notice when it drifts

A baseline is the agreed secure configuration for a class of system: a Linux server, a laptop, a database, a cloud account, a firewall. It lists the settings that matter and the value each must have. You do not need to invent one from nothing. Public hardening guides, such as the CIS Benchmarks or a vendor's own security guide, give a sensible starting set; you then record where you deviate and why.

Baseline

The approved settings for a system type, with a version and an owner.

Hardened image

A machine or container image built with the baseline already applied.

Infrastructure as code

Configuration held in files under version control, applied by a tool, so the file is the record.

Drift

Any difference between the baseline and what is actually running.

A baseline in a document is a start. A baseline built into an image or a template is better, because every new system inherits it. Teams running in the cloud often go further and manage most configuration as code: a reviewed pull request becomes both the change record and the evidence that the baseline was applied.

Configuration management and change management (control 8.32) meet here. When a setting changes, there should be a change record that explains it. When a setting differs from the baseline and there is no record, that is drift, and it needs either a fix or a documented exception. Changing the baseline itself is a change too, and goes through the same approval.

1. Compare running systems to the baseline on a schedule, or continuously.
2. Route each difference to the system owner.
3. Match it to an approved change, or treat it as a finding.
4. Fix it, or record an exception with a reason, an approver and a review date.
5. Keep the output of each run, so the audit period is covered.

Cloud security posture management tools fit neatly into this loop. They read your cloud accounts and flag settings that break a rule set, such as public storage or logging switched off. They are a drift detector for the cloud layer. They do not replace baselines for operating systems, databases or network devices, and their default rules are someone else's baseline until you review and adopt them.

• Adopting a benchmark wholesale. Hundreds of settings nobody reviewed, half of them failing, none with an owner.
• Baselines that never change. No version history suggests nobody has looked since it was written.
• Console changes in a code-managed estate. Manual edits bypass review and leave the code out of step with reality.
• Posture alerts nobody closes. A long list of open findings reads as an ineffective control.
• Forgetting SaaS. Identity provider, email and collaboration tools have security settings too.

Sources: ISO/IEC 27001:2022 Annex A controls 8.9 and 8.32 (cited by number and name only); ISO/IEC 27002:2022 for the existence of guidance on control 8.9; NIST SP 800-53 Rev. 5, Configuration Management (CM) family; the CIS Benchmarks as an example of public hardening guidance. The baseline table is our own.