Study guide

4.6 Implementing Compensating and Alternate Controls

ISC2 Certified in Governance, Risk and Compliance CGRC

Track your progress as you read

Finished sections get a check mark.

1 Introduction & Exam Overview

0.1 ISC2 CGRC Exam Structure, Logistics & Passing Strategy 0.2 NIST RMF 7-Step Lifecycle & GRC Architecture

2 Chapter 1: Security and Privacy Governance, Risk Management, and Compliance Program

1.1 Enterprise Governance & GRC Frameworks 1.2 Security and Privacy Objectives: CIA, Non-Repudiation and Privacy Concepts 1.3 Multi-Tier Risk Management & Assessment Methodologies 1.4 System Development Life Cycle and Information Life Cycle Management 1.5 Establishing and Operating the Compliance Program 1.6 Legal, Regulatory & Federal Compliance Drivers 1.7 Privacy Governance, Organizational Roles & ISC2 Code of Ethics

3 Chapter 2: Scope of the System

2.1 System Boundary Definition, Architectural Context & Types 2.2 Identifying Information Types with NIST SP 800-60 2.3 System Categorization Process & Impact Analysis (FIPS 199 / SP 800-60) 2.4 Impact and Risk Determination Under Non-Federal Frameworks 2.5 System Registration, Environment & Interconnection Agreements

4 Chapter 3: Selection and Approval of Framework, Security, and Privacy Controls

3.1 Control Catalogs & NIST SP 800-53 Rev. 5 Structure 3.2 Control Allocation & Inheritance Models 3.3 Control Tailoring, Scoping & Overlay Guidance 3.4 Data Handling and Marking Requirements 3.5 Documenting Control Selection and Securing Stakeholder Agreement 3.6 Continuous Monitoring Strategy & Control Selection Approval

5 Chapter 4: Implementation of Security and Privacy Controls

4.1 Developing the Implementation Strategy: Resourcing, Funding and Timeline 4.2 Identifying Control Types: Management, Operational, Technical and Functional Classes 4.3 System Security and Privacy Plan (SSP/SSPP) Development 4.4 Security Engineering Principles & Technical Control Implementation 4.5 Secure Baseline Configuration & System Hardening 4.6 Implementing Compensating and Alternate Controls 4.7 DevSecOps, SDLC Integration & Supply Chain Risk Management 4.8 Documenting Control Implementation: Policies, Procedures, Plans and Risk Registers

6 Chapter 5: Assessment/Audit of Security and Privacy Controls

5.1 Security Assessment Plan (SAP) & Assessor Independence 5.2 Assessment Methods, Objects & Depth/Coverage 5.3 Assessment Execution, Vulnerability Scanning & Testing 5.4 Preparing the Initial Assessment/Audit Report 5.5 Selecting Risk Responses: Avoid, Accept, Share, Mitigate, Transfer 5.6 Stakeholder Collaboration, Corrective Action and Reassessment 5.7 Security Assessment Report (SAR) & Risk Findings Analysis 5.8 Developing the Risk Response Plan: Prioritization and Resources

7 Chapter 6: System Compliance and Authorization

6.1 The Core Authorization Package & Supporting Artifacts 6.2 Plan of Action and Milestones (POA&M) Architecture & Management 6.3 System Risk Acceptance Criteria and Stakeholder Concurrence 6.4 Authorization Decision Process & Decision Types 6.5 Residual Risk Acceptance, Terms of Authorization & Continuous ATO 6.6 Documenting and Communicating the Compliance Decision

8 Chapter 7: Compliance Maintenance and Continuous Monitoring

7.1 Continuous Monitoring Strategy & Operations (NIST SP 800-137) 7.2 Configuration Management & Security Impact Analysis (NIST SP 800-128) 7.3 Incident Response and Contingency Activities in Sustained Compliance 7.4 Awareness, Training, Evidence Collection and Monitoring-Strategy Revision 7.5 Ongoing Remediation, POA&M Sustainment & Annual Reviews 7.6 Event-Driven Reauthorization & System Decommissioning

4.6 Implementing Compensating and Alternate Controls

Key Takeaways Explain This Topic AI

A compensating control is justified only when the baseline control is genuinely infeasible for technical, architectural, or mission reasons — never because it is inconvenient or expensive.

The compensating control must satisfy the intent and rigor of the original requirement and provide comparable protection, not merely some protection.

Compensating controls require documented rationale, an assessment of the resulting risk, and formal acceptance by the Authorizing Official.

A compensating control differs from a scoped-out control: scoping applies when the condition the control addresses is absent, while compensation applies when the condition exists but the specified control cannot be used.

Compensating controls carry higher continuous monitoring obligations because they are bespoke arrangements without the assurance history of the baseline control.

Last updated: August 2026

Implementing Compensating and Alternate Controls

Task 4.2 names two implementation outputs: controls implemented consistently with compliance requirements, and "compensating or alternate security controls implemented." The second exists because real systems contain constraints the catalog authors could not anticipate — legacy platforms, safety-critical timing requirements, vendor-sealed appliances, medical or industrial devices that cannot be modified without voiding certification.

1. When Compensation Is Legitimate

A compensating control substitutes an alternative safeguard for a baseline control that cannot be implemented as specified . The justification must rest on genuine infeasibility:

Legitimate Basis Example

Technical infeasibility A vendor-sealed medical device cannot accept a third-party endpoint agent without voiding its regulatory certification

Architectural constraint An industrial control protocol has no capacity to carry authentication tokens

Mission/safety conflict Automatic session termination would interrupt a continuously running flight-tracking process

Legacy platform limitation An unsupported operating system cannot enforce the required cryptographic module

And the bases that are not legitimate — each a favourite exam distractor:

"It is too expensive." Cost is a factor in risk-based decisions, but budget alone does not make a control infeasible. The correct path is a risk acceptance decision by the Authorizing Official or a POA&M item, not a compensating control.

"It is inconvenient for users." Friction is not infeasibility.

"We have not got round to it." That is a planned implementation belonging in the POA&M, not a compensating control.

"Another baseline control already covers it." A control that is already required cannot be reused as compensation for a different requirement.

Important

The "above and beyond" rule. A compensating control must be something the organization is not already obliged to do. Offering "we run quarterly vulnerability scans" as compensation for a missing control fails, because scanning is itself a baseline requirement (RA-5). Compensation requires additional protection beyond the existing obligations. PCI DSS states this most explicitly in its compensating control worksheet criteria, and the same logic governs NIST tailoring.

2. The Equivalence Standard

The substitute must meet the intent and rigor of the original control and provide comparable protection — a materially higher bar than "provides some security benefit."

Establishing equivalence requires four steps:

State the security objective of the original control. Not its mechanism — its purpose. AC-12 (session termination) exists to limit the window in which an unattended authenticated session can be abused.

Explain precisely why the specified mechanism cannot be used , with technical evidence rather than assertion.

Describe the alternative and show how it addresses the same objective. Restricting access to hardened jump hosts with continuous session monitoring and re-authentication addresses the unattended-session window through a different mechanism.

Analyze the residual difference. Equivalence is rarely perfect. Name what the substitute does not cover and quantify the resulting exposure.

That fourth step separates a credible compensating control from a rationalization, and it is the step assessors probe hardest. An analysis claiming perfect equivalence is usually an analysis that has not been done.

Compensating Controls Are Often Layered

A single substitute rarely reaches equivalence with a baseline control. The air-gapped legacy-system pattern is typical: an isolated physical enclave, plus biometric door access, plus unidirectional data diodes, plus continuous passive network monitoring, plus enhanced personnel vetting — collectively compensating for unsupported multifactor authentication and automated patching. Any one element alone would fail the comparability test.

3. Approval and Documentation

Compensating controls are never a local engineering decision. The path is fixed:

The system owner or ISSO documents the constraint, the proposed alternative, and the equivalence analysis in the SSP , recording the control status as alternative implementation .

The Security Control Assessor independently evaluates whether the substitute genuinely achieves the objective and tests it as implemented. The assessor may find the compensating control inadequate , which returns the item to the system owner.

The Authorizing Official formally accepts the residual risk. Because the system is operating with something other than the prescribed baseline, only the AO can accept that deviation.

Where a regulator, overlay, or framework owner must concur — a FedRAMP authorizing body, a card-brand acquirer, a DoD component — that concurrence is obtained as well.

The complete record contains the original control, why it is infeasible, the alternative and how it achieves the objective, the residual difference and its risk, the monitoring commitment, the assessor's evaluation, and the AO's acceptance. Missing any element makes the compensating control indefensible at audit.

4. Compensating Versus Scoping Out — The Distinction That Decides Exam Items

These are routinely confused and the exam tests them directly.

Scoped Out (Not Applicable) Compensating Control

Situation The condition the control addresses does not exist in the boundary The condition exists , but the specified control cannot be used

Example PE-18 (wireless access) in a system with zero wireless components AC-12 (session termination) on a system that must run continuous background jobs

  • Result No control needed; nothing to protect Alternative safeguard required
  • Documentation Justification that the condition is absent Full equivalence analysis + AO risk acceptance
  • Residual risk None from this control Real, and must be accepted

The test is a single question: does the risk the control addresses exist in this system? If no — scope it out. If yes but the control cannot be implemented as written — compensate. Answering "compensating control" for a system with no wireless interfaces is wrong; there is nothing to compensate for.

Sustainment Obligations Are Higher

A compensating control is a bespoke arrangement without the assurance history of a standard baseline control, so it inherits stronger ongoing obligations. It should be reassessed more frequently than the control it replaces; it must be revisited whenever the constraint changes — when the vendor finally ships MFA support, the compensating control should retire in favour of the baseline control; and it must be re-examined at every reauthorization , since a constraint that was genuine five years ago may simply be deferred modernization today. Compensating controls that quietly become permanent, long after the constraint that justified them has disappeared, are a standard audit finding.

Loading diagram... Compensating Control Decision and Approval Path