When a baseline creates a business constraint, teams should review the change formally, assess security impact, and decide whether to update the baseline or add compensating controls. The key is not to bypass the process with a quick fix. Any approved exception should be documented, risk assessed, and promoted through the same controlled change path.
When should a baseline be changed instead of worked around?
A baseline should be changed when the business requirement is legitimate, recurring, and the current standard would otherwise force repeated exceptions or shadow configurations. At that point, the baseline is no longer serving its purpose if it blocks normal operations, but the change still needs formal review so the security posture is adjusted deliberately rather than eroded informally.
This is usually a sign that the baseline was either set too narrowly, or the environment has evolved faster than the standard. The practical question is whether the requirement is a one-off outlier or a stable operating need that deserves to be built into the approved standard.
How should organisations handle exceptions without weakening control?
Exceptions should be treated as controlled deviations, not informal permissions. The organisation should record the business justification, assess the security impact, assign an owner, define an expiry or review point where possible, and decide whether compensating controls are needed while the exception remains in place.
That approach keeps the change auditable and prevents exceptions from turning into permanent drift. If the same exception appears repeatedly, it is usually better to update the baseline than to keep re-approving the same temporary workaround.
When the constraint affects hardened configurations or secure defaults, the decision should also consider whether the baseline is still aligned to the real deployment pattern. Good baselines are enforceable in practice, not just desirable on paper.
What does a good controlled change path look like?
A sound process separates business need, security review, approval, implementation, and follow-up validation. The change should be assessed through the same governance route used for other controlled configuration changes, so the organisation can see what changed, why it changed, and whether the new state still meets policy expectations.
Where the approved change reduces security strength, the record should state what was accepted, what compensating control was added, and who accepted the residual risk. Where the change improves usability without materially increasing exposure, the baseline can often be revised so teams do not keep relying on exceptions.
The most important operational test is whether the resulting configuration is still measurable and supportable. If the team cannot tell which systems diverge from baseline, or cannot prove that the exception was reviewed, the process is already failing.
Risk and Threat Considerations
Uncontrolled baseline exceptions create configuration drift, and drift is where hidden exposure accumulates. A quick fix may restore functionality, but it can also bypass hardening assumptions, weaken auditability, and leave a fragile configuration in place long after the original business need has passed.
Failure mechanism: Teams bypass formal review to restore service quickly, then leave the deviation undocumented or indefinitely approved, which slowly turns a one-off workaround into an accepted but unassessed security state.
Impact: The environment can drift away from the intended security baseline, making it harder to detect weak settings, prove accountability, and understand the true blast radius if the altered configuration is later abused or fails.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
CIS Controls v8 and NIST SP 800-53 Rev 5 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| CIS Controls v8 | CIS-4 — Secure Configuration of Enterprise Assets and Software | Baselines and exceptions are configuration-control concerns. |
| Recommendation — Review and maintain secure baselines, and document approved deviations with compensating controls. | ||
| NIST SP 800-53 Rev 5 | CM-2 — Baseline Configuration | The question is explicitly about changing a baseline configuration. |
| CM-3 — Configuration Change Control | Approved exceptions and baseline updates require formal change governance. | |
| Recommendation — Update the baseline only through controlled review and approval when business needs change. Route baseline changes and exceptions through formal configuration change control. | ||
| ISO/IEC 27001:2022 | A.8.9 — Configuration management | Baseline exceptions and compensating controls sit within configuration management. |
| Recommendation — Record, assess, and approve configuration deviations before implementation. | ||
Practitioner Guidance
What to prioritise: Distinguish a genuine business requirement from a convenience request. If the change is operationally necessary and likely to recur, update the baseline; if it is temporary, contain it with documented compensating controls and a review date.
What to verify: Confirm that the exception has an owner, a recorded security assessment, and an auditable approval path. Also verify that monitoring still covers the altered setting, because exceptions that cannot be observed are usually exceptions that cannot be managed.
Common mistake: Treating “approved once” as equivalent to “safe indefinitely.” The better rule is that every exception should either expire, be revalidated, or be folded into the standard baseline once the business need proves durable.
Practitioner takeaway: The goal is not to preserve the baseline at all costs, but to keep configuration changes intentional, traceable, and security-reviewed so business flexibility does not become unmanaged drift.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 25, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
