A verified reference state for a system, including expected files, configurations, and authorized settings. Security teams use it to spot drift quickly and to show whether later changes were planned or unexpected. In regulated environments, it strengthens auditability and supports change integrity evidence.
Expanded Definition
A known-good baseline is the documented, verified reference state that security teams treat as the authoritative comparison point for a system. It usually includes approved files, configurations, services, permissions, hardening settings, and other properties that should remain stable unless a controlled change has been made. The concept sits close to configuration management and integrity monitoring, but it is narrower than generic documentation because the baseline must be validated, not simply recorded.
In practice, a baseline is only useful when the organisation can prove two things: what the system should look like, and how that state was established. That makes it an important operational concept in the NIST Cybersecurity Framework 2.0 context, where asset visibility, change control, and continuous monitoring all depend on a reliable reference point. Definitions vary slightly across vendors and toolsets, especially when baselines are generated automatically from scans or learned over time, so governance teams should distinguish between a provisional baseline and a formally approved one.
The most common misapplication is treating a current snapshot as a known-good baseline, which occurs when recent compromise, shadow changes, or unreviewed drift are mistaken for an approved state.
Examples and Use Cases
Implementing a known-good baseline rigorously often introduces maintenance overhead, requiring organisations to balance fast operational change against the cost of keeping the reference state accurate and defensible.
- A Windows server baseline defines approved local policies, installed agents, registry settings, and firewall rules so drift can be flagged during routine scans.
- A cloud workload baseline records expected instance metadata, startup scripts, IAM role assignments, and storage encryption settings before a production deployment is accepted.
- A golden image for endpoint builds becomes a known-good baseline after security review, then serves as the reference for fleet-wide integrity checks and rebuilds.
- An application container baseline captures approved packages, file hashes, and runtime parameters so defenders can distinguish expected patching from unauthorised tampering.
- A regulated financial environment uses a baseline to demonstrate that a configuration change was planned, approved, and traceable during an audit cycle, aligning with the broader change-integrity approach described in the NIST Cybersecurity Framework 2.0.
Why It Matters for Security Teams
Known-good baselines matter because they turn vague concern about “something changed” into a defensible security signal. Without a trusted baseline, monitoring tools can detect differences but cannot reliably judge whether those differences are authorised, risky, or evidence of compromise. That weakens incident response, complicates vulnerability management, and makes audits harder to defend because teams cannot show what state was considered acceptable at a given point in time.
The concept also supports identity and access governance when baseline content includes privileged accounts, service principals, API keys, certificates, or other secrets associated with a system. In those cases, the baseline is not just about operating system hardening. It becomes part of the control evidence for who or what was allowed to exist in the environment. A baseline should therefore be versioned, reviewed, and tied to change approval, not left as a static file that drifts out of date. Guidance in the NIST Cybersecurity Framework 2.0 reinforces that monitoring and governance only work when the reference state is trustworthy.
Organisations typically encounter the cost of a weak baseline only after an incident review, at which point the missing reference state becomes operationally unavoidable to reconstruct.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST CSF 2.0 provides the primary governance reference for this term.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | DE.CM-7 | Baseline monitoring supports detection of configuration drift and unauthorized changes. |
Continuously compare systems to approved reference states and investigate unexpected drift.
