Hardening Exceptions and Compensating Controls Template: a register and procedure for baseline deviations

Every hardening baseline rollout produces settings that cannot be applied to some systems, and without a documented exception procedure those gaps become silent, permanent and invisible to the people who carry the risk. This template gives you a procedure and a register for deviations from a secure configuration baseline such as a CIS Benchmark, a DISA STIG or the Microsoft security baselines. It covers how a deviation is raised, assessed, contained with compensating controls, approved, monitored and closed. It is written for platform, endpoint and security engineering teams who own baselines, and for the risk and audit functions that need evidence. It goes deeper on configuration baselines than our general Security Exceptions and Risk Acceptance Guide, which covers the wider risk acceptance process.

How to use this template

• Replace text in square brackets, such as [Organisation], [Baseline owner] and [Risk committee], with your own terms.
• "Must" is a mandatory requirement; "should" is a recommended practice where a documented reason allows another approach.
• The section headings follow an incident-style lifecycle on purpose: a deviation is treated as a known weakness that has to be found, triaged, contained, removed and reviewed, with the same discipline as an incident.
• Use the register fields in section 3 as the columns of your exception register, in a GRC tool, a ticketing system or a controlled spreadsheet. Your scanner's suppression list must reference the register ID, never replace it.
• Align approval levels with your existing risk acceptance delegation. Section 2 gives a starting point.
• Review the procedure at least annually, and whenever the baseline version changes (for example a new CIS Benchmark release or STIG update).

1. Scope and triggers

This procedure applies to every system in scope of a [Organisation] configuration baseline, including servers, endpoints, network devices, cloud services, container images and golden images.

A hardening exception must be raised when any of the following occurs:

1. A baseline setting cannot be applied because it breaks a business application, a vendor support condition or an operational process.
2. A configuration assessment (for example CIS-CAT, an SCAP scan, a cloud posture tool or Intune compliance) reports a failed setting that will not be fixed within the remediation timescale in [Configuration standard].
3. A system cannot run a supported baseline at all, such as an appliance, an end of life operating system or an operational technology controller.
4. A team applies a setting that is weaker than the baseline, including a temporary change made during troubleshooting that is not reverted within [5 working days].
5. A new baseline version introduces a setting that existing systems cannot meet by the adoption date.

Out of scope: choosing a different baseline profile for a whole system class (for example CIS Level 1 instead of Level 2 for general workstations). That is a baseline tailoring decision recorded by the [Baseline owner] in the baseline itself, not an exception. See the CIS Benchmarks Guide.

Some settings must never be excepted without [CISO] approval and a remediation date within [30 days]: disabled endpoint protection, disabled audit logging, local accounts with shared or default passwords, legacy authentication protocols exposed to untrusted networks (for example SMBv1, NTLMv1, Telnet) and internet-exposed management interfaces.

2. Roles and contacts

Delegation table (starting point):

3. Detection and triage

Deviations reach the register in two ways: a request raised before the change, or a finding from configuration assessment. Both follow the same triage.

1. Log the request in [ticketing system] with the register fields below. A scanner finding with no request after [10 working days] is escalated to the system owner's manager.
2. Confirm the setting. The baseline owner records the baseline name, version and recommendation ID (for example the CIS Benchmark recommendation number or the STIG rule ID and its CAT I, II or III severity) and the security purpose of the setting.
3. Test the claim. The assessor confirms that the setting really causes the stated problem, ideally by applying it in a test environment. A large share of requests fail this step.
4. Look for a narrower fix. Prefer a scoped change (one registry value, one firewall rule, one group policy object targeted at one security group) over disabling a whole policy.
5. Rate the residual risk using [Organisation] risk methodology, taking account of exposure (internet facing, privileged, holds sensitive data) and whether the gap maps to a known attack technique.

Register fields:

4. Containment: compensating controls

A compensating control reduces the risk left by the missing setting. It must address the same threat as the original setting, not just add an unrelated control. PCI DSS uses a demanding test that is a useful model even outside card data: a compensating control must meet the intent and rigour of the original requirement, provide a similar level of defence, go beyond other requirements already in place, and be proportionate to the extra risk (PCI DSS Appendix B, with the Appendix C worksheet).

Compensating controls that depend on another system (a firewall rule, an EDR policy, a SIEM alert) must be recorded so that a change to that system triggers a review of the exception. See the Security Control Types Guide.

5. Eradication: remediation and closure

1. Every exception must have a remediation plan unless the approver records that remediation is not feasible for the life of the asset, in which case the asset's retirement date becomes the expiry.
2. The requester must report remediation progress at each review. A missed remediation date without a new approval is a breach of this procedure and is reported to the approver.
3. When the setting is applied, the requester closes the entry with evidence: a passing assessment result for the named assets.
4. The register administrator removes the related scanner suppression on the same day the entry closes.

6. Recovery: expiry and return to baseline

1. The register sends alerts to the owner at [60, 30 and 7 days] before expiry.
2. At expiry, the exception lapses. The setting reverts to the baseline through the normal enforcement mechanism (group policy, Intune, configuration management) unless a renewal has been approved.
3. A renewal is a fresh decision: new evidence of the constraint, new risk rating, retested compensating controls. Third and later renewals go to the next approver level up.
4. If reverting would cause an outage the owner accepts, the owner must raise an emergency change through [Change management procedure], not leave the setting in place informally. See the Change Management Policy Template.

7. Communication and notification

• Monthly: the register administrator reports open, expiring, overdue and expired exceptions to [Security leadership], grouped by baseline and business unit.
• Quarterly: High and Critical exceptions are reported to [Risk committee], with aggregate risk where several exceptions affect the same asset or the same attack path.
• On change: the baseline owner notifies requesters when a new baseline version changes or removes a setting they have an exception for.
• Audit: the register, approvals and validation evidence are provided to internal and external auditors on request. Exceptions affecting regulated scope (for example the PCI DSS cardholder data environment) are flagged for the compliance lead.

8. Post-incident review: periodic review of the register

At least [quarterly] the baseline owner and the assessor review the register as a whole:

1. Reconcile every scanner suppression and every policy exclusion group against register IDs. Anything without an ID is an unrecorded exception.
2. Identify recommendations with many exceptions. If the same setting is excepted on a large share of a system class, the baseline itself may need tailoring.
3. Retest a sample of compensating controls.
4. Check that exceptions for decommissioned assets have been closed.
5. When a security incident involves an excepted setting, review that exception and its compensating controls as part of the incident review.

Implementation guidance

Rollout order. Start with an amnesty: export every current suppression, exclusion group and known deviation, record each in the register with a short expiry, and assess them by risk. Then make the register the only route for new deviations, and finally enforce expiry by linking the register to your enforcement tooling. See the Configuration Drift and Baseline Enforcement Guide.

Small and large organisations. A small team can run this in a ticketing system with a single approver for Low and Medium risk and the CISO or managing director for the rest. A large organisation should hold the register in a GRC platform integrated with its assessment tools so that a suppression cannot be created without an exception ID.

Identity exceptions. Many baseline deviations are identity settings in disguise: service accounts excluded from "deny log on locally" or password expiry, accounts excluded from conditional access, local administrator accounts kept for a vendor. Record the account as an asset in the register and link it to its owner. See the Remediation SLAs and Vulnerability Exceptions Guide for the vulnerability side of the same process.

Metrics. Track the number of open exceptions by baseline and risk; the percentage past expiry; the median age of exceptions; the number of suppressions without a register ID (target zero); and the percentage of compensating controls retested on schedule.

Framework mapping.

Standards and references

• NIST: SP 800-53 Rev. 5 Security and Privacy Controls
• NIST: Cybersecurity Framework 2.0
• CIS: CIS Benchmarks
• PCI Security Standards Council: Compensating Controls
• ISO: ISO/IEC 27001:2022 Information security management systems

Related NHI Mgmt Group resources: Security Exceptions and Risk Acceptance Guide · CIS Benchmarks Guide · DISA STIG Guide · Risk Register Template