What it has to decide
- The authoritative baseline per platform, and its source
Name the benchmark you build from and the version. "Hardened in line with best practice" is not auditable and does not survive a question.
- Documented deviations, with owners and expiry
There will be deviations. Untracked ones are indistinguishable from misconfiguration, which is what makes drift undetectable.
- How compliance with the baseline is measured
State the frequency and whether it is continuous or point in time. Configuration proven at build and never re-checked describes the past.
- Change authorisation, including the emergency path
Emergency change will happen. Give it a defined route with retrospective approval, or it will happen with no route at all.
- Segregation between environments
Who can deploy to production, and confirmation that production data does not flow backwards into test without treatment.
- Default credentials and unnecessary services
Explicitly required to be removed before a system reaches production, and verified rather than asserted.
How it is usually got wrong
- A baseline exists as a document, systems are built from an image that diverged from it years ago, and nothing compares the two.
- Drift is measured annually, so a system can sit misconfigured for eleven months and pass.
- Emergency change has no defined route, so urgent work bypasses change control entirely and is never recorded.
- Production data is copied into test environments with weaker access controls and no masking.
- Default credentials remain on appliances and embedded devices that nobody considers systems.
Worked extract
What a decision looks like once it has been madeEach platform is built from a documented baseline derived from the relevant CIS Benchmark, with the benchmark version recorded. Deviations from the baseline are recorded in the configuration exception register with a named owner, a stated reason and an expiry date not exceeding twelve months. Compliance with the baseline is measured continuously by automated assessment, and any system found non-compliant for more than seven days is escalated to the system owner. Changes to production are authorised through the change process; emergency changes may be made without prior authorisation where a Priority 1 incident requires it, and must be submitted for retrospective approval within two business days. Production data is not copied into non-production environments unless it has been masked or tokenised. Default credentials are removed and unnecessary services disabled before a system is released to production, and this is verified by automated check rather than attestation.
