How should organisations implement baseline selection?

What baseline selection is trying to achieve

baseline selection is the point where security policy becomes operational. A good baseline turns broad intent into a consistent minimum build standard, so teams can compare systems against the same starting point and avoid ad hoc hardening. It should reflect the asset’s purpose, sensitivity, and environment, rather than forcing one control set across every platform.

That makes baseline selection part risk management as much as configuration management. A workstation, a public-facing application, and a regulated production system should not all inherit the same starting assumptions. The goal is not the most restrictive baseline possible, but the most defensible baseline for the system’s role, exposure, and compliance obligations.

For organisations building around a recognised control catalogue, a strong starting point is the NIST SP 800-53 Guide, because it explains how control families, baselines, tailoring, and overlays fit together in a repeatable selection process.

How to choose the right starting point

Start with a standard control set that is already accepted in your environment, then tailor it to the system’s classification, threat exposure, and business function. The baseline should be measurable, so you can verify whether a build meets it without subjective interpretation. If the system has higher sensitivity, privileged access, external connectivity, or stronger regulatory obligations, the baseline needs to reflect that from the start.

The most common mistake is treating baseline selection as a one-time document exercise. In practice, the right baseline depends on how the system will be deployed and operated. A cloud workload, an internal enterprise service, and an operational environment each introduce different failure modes, so the baseline must be specific enough to survive review, testing, and audit.

When you need a concrete implementation reference for hardened build standards, CIS Benchmarks are a useful external baseline source because they define prescriptive hardening targets for common platforms and services.

In regulated or control-driven programmes, it is also useful to align the chosen baseline with NIST SP 800-53 Rev 5 Security and Privacy Controls, since its control catalogue gives you a defensible way to justify why a particular baseline is stronger, weaker, or tailored for the system.

What makes a baseline defensible in practice

A defensible baseline is one that can be repeated across similar systems, assessed the same way every time, and traced back to a clear rationale. That means the baseline should be documented in terms that operations, engineering, security, and audit can all interpret the same way. It also means the baseline should support exception handling, so teams know when deviations are temporary, approved, and tracked.

Good baseline selection also depends on whether you can actually enforce it. If a control cannot be measured, automated, or verified during review, it is too vague to serve as a baseline. The practical test is simple: can you prove that a system was built to the baseline, can you detect drift, and can you explain why the chosen version is appropriate for this class of asset?

For environments where configuration consistency is the real objective, the most useful benchmark is not “maximum security”, but “repeatable secure build with clear review criteria”. That is why baseline selection works best when paired with standard build images, configuration management, and a controlled exception process.

If your environment also depends on strong crypto configuration, NIST SP 800-57 Key Management is relevant where the baseline must define cryptoperiods, rotation expectations, and key lifecycle rules rather than leaving those choices to individual teams.

Practitioner Guidance

What to verify: Confirm that each baseline version maps to a system class, a risk tier, and a deployment environment. If the same baseline is being used for materially different assets, the selection is too coarse and will usually fail review.

Decision rule: If the system handles sensitive data, privileged functions, or regulated workloads, choose the stronger baseline and justify any relaxation explicitly. If the system is low criticality but widely deployed, prioritise consistency and drift control over bespoke hardening.

What good looks like: Security and engineering can explain why the baseline exists, what it protects against, how it is measured, and what evidence proves a build conforms. Exceptions are rare, time-bound, and visible.

Practitioner takeaway: Baseline selection is only useful when it produces a repeatable standard that is strong enough for the asset, light enough to operate, and precise enough to defend during review.

Related resources from NHI Mgmt Group

• How do organisations implement impact analyses?
• How do organisations implement access restrictions for change?
• How do organisations operationalise NHI ownership at scale?
• When should organisations treat an NHI as a high-priority risk?