Compensating Controls Evidence for SOC 2

Introduction

Compensating controls evidence for SOC 2 is the dated record that shows why a primary control could not operate as designed, what substitute control your team put in its place, who approved that decision, and how you confirmed the substitute actually reduced the risk. Saying "we have a manual check instead" is a description. A risk entry, an approved exception, a written design for the substitute control, and execution records for every period it ran are evidence.

The compensating control glossary entry explains the concept. This guide focuses on the operating side: how to document, approve, run, and retire a compensating control so it holds up when an auditor samples it. It is different from exception management and audit findings remediation, which covers fixing a control after it failed. A compensating control is a deliberate, approved substitute that runs while the primary control cannot.

Here is a labeled hypothetical. A 40-person SaaS company relies on automated branch protection to require peer review before code reaches production. A legacy service lives in a repository that cannot enforce that rule for six months while it is migrated. The team agrees that a weekly manual review of every merged change in that repository, signed off by an engineering manager, will stand in for the automated gate. If the team writes that down, approves it, runs the weekly review, and keeps the records, the auditor has something to test. If the team only mentions it in a meeting, the auditor sees an unprotected repository and no evidence of a substitute.

What Compensating Controls Evidence Means

Compensating controls evidence answers six questions with records rather than descriptions:

1. What could not run? The primary control, the system or scope it no longer covers, and the reason, such as a technical limitation, a migration, or a vendor constraint.
2. What risk does that create? The specific risk the primary control was meant to address, recorded in your risk register or risk assessment.
3. What replaces it? A written design for the substitute control: what it does, how often, who performs it, and what output it produces.
4. Who approved it? A named approver with authority to accept the residual risk, and the date of approval.
5. Did it actually run? Execution records for every occurrence during the period, such as signed review checklists, tickets, or reports.
6. When does it end? A target date or condition for restoring the primary control, and a record of retiring the substitute once that happens.

If any of those six is missing, the substitute control is hard to defend. The fifth question is the one that most often fails during Type 2 testing, because teams approve a workaround and then stop running it.

How Compensating Controls Differ From Exceptions and Remediation

These terms overlap in everyday use, so it helps to separate them before you build evidence.

• An exception is a documented deviation from a policy or control. It may or may not have a substitute control attached. Some exceptions are simply accepted risk.
• A compensating control is a substitute control that addresses the same risk to an acceptable degree when the primary control cannot operate. It is usually tied to an exception, but it is a control in its own right, with an owner, a frequency, and evidence.
• Remediation is the work to fix a control that failed or to restore the primary control. The compensating control often runs while remediation is in progress.

A useful rule of thumb: if an auditor asked "what are you doing about this risk right now," the exception answers why the primary control is not running, the compensating control answers what is running instead, and the remediation plan answers when the primary control comes back.

Why Compensating Controls Matter for SOC 2

The AICPA 2017 Trust Services Criteria, with revised points of focus published in 2022, expect an organization to identify and analyze risks (CC3.2), select and develop control activities that mitigate those risks (CC5.1), and evaluate and communicate control deficiencies in a timely manner (CC4.2). SOC 2 does not prescribe a specific compensating control format. It does expect that when a control you described cannot operate, the risk is still managed and the situation is visible to the people responsible for it.

In a Type 1 report, the auditor evaluates whether the design of your controls, including any substitutes, is suitable at a point in time. In a SOC 2 Type 2 report, the auditor tests whether controls operated effectively across the period. That means a compensating control in place for part of the period is typically tested for that part, and gaps in its execution can be reported as exceptions.

How a specific auditor treats a compensating control depends on your system description, the control wording, and their professional judgment. Talk to your auditor early when you know a primary control will be unavailable for a meaningful part of the period.

Designing a Compensating Control That Holds Up

Tie it to a specific risk

Start with the risk the primary control addressed, not with the workaround you already have in mind. Record it in the risk register with the affected systems, likelihood, impact, and a link to the exception. A substitute control is easier to justify when the risk statement is precise, such as "unreviewed code can reach production in the legacy billing repository," rather than generic, such as "change management risk."

Address the same objective

A good compensating control addresses the same control objective as the primary control. A weekly manual review of merged changes compensates for missing automated review because both aim to catch unauthorized or unreviewed changes. A quarterly security awareness reminder does not compensate for missing code review, even if it is a real control, because it addresses a different risk.

Be honest about residual risk

Most substitutes are weaker than the control they replace. Manual reviews are slower and depend on people. Detective controls catch problems after the fact instead of preventing them. Record the residual risk plainly and have the approver accept it in writing. Overstating the strength of a substitute is a common reason auditors push back.

Name an owner and a frequency

Every compensating control needs a control owner, a frequency, and a defined output. "Engineering reviews changes as needed" cannot be tested. "The engineering manager for the billing team reviews every merged pull request in the legacy repository each Friday and records the review in a ticket" can be.

Set an end date

Compensating controls are meant to be temporary unless you formally redesign the control. Record a target date or condition for restoring the primary control, and a review date to revisit the decision if that target slips.

Approval and Documentation

A compact compensating control record often includes:

• Control ID and name of the primary control that cannot operate
• Scope affected, such as systems, repositories, accounts, or locations
• Reason the primary control cannot run
• Linked risk register entry and exception record
• Design of the substitute control: activity, frequency, owner, inputs, and output
• Residual risk statement
• Approver, approval date, and approval evidence such as a signed ticket or recorded decision
• Start date, target end date, and review date
• Link to the remediation plan for restoring the primary control

Keep this record in the same system you use for other control documentation so it shows up in normal reviews. If your control mapping links controls to criteria, map the compensating control to the same criteria as the primary control for the affected scope.

Running and Monitoring the Substitute

Approval is the easy part. The evidence that matters most during Type 2 testing is the record of the substitute control running on schedule.

• Use a recurring task or ticket. Create one ticket or checklist per occurrence so each run has a date, a performer, and an outcome.
• Capture the inputs. For a manual review, record what was reviewed, such as a list of merged changes or an access listing, so the auditor can see the population.
• Record findings and follow-up. If the review finds a problem, link the follow-up ticket. A review that never finds anything over many months can prompt questions about how thorough it is.
• Watch for missed runs. Assign a backup performer and an escalation path. A missed weekly review in a Type 2 period may be reported as an exception.
• Review the decision. On the review date, confirm the reason still applies, the substitute is still working, and the target end date is still realistic. Record the outcome.

Retiring a Compensating Control

When the primary control is restored, close the loop:

1. Record evidence that the primary control is operating again for the affected scope, such as a configuration screenshot or system export showing the rule is enforced.
2. Record the date the compensating control stopped running and who approved retiring it.
3. Close the linked exception and update the risk register entry.
4. Keep all records from the period the substitute was active. They are still in scope for that part of the audit period.

Do not delete the compensating control record. Auditors testing the full period will want to see both the substitute and the transition back.

Type 2 Sampling: What Auditors Commonly Request

Auditors set their own procedures, but compensating control requests commonly include:

• The exception or decision record explaining why the primary control could not operate
• The linked risk entry and residual risk acceptance
• The written design of the substitute control
• Approval evidence with a named approver and date
• A population of every scheduled occurrence during the period, and a sample of execution records
• Follow-up tickets for anything the substitute found
• Evidence of when the primary control was restored and the substitute was retired, if that happened during the period
• Inquiry with the control owner about how the substitute works in practice

If the substitute ran for only part of the period, expect the auditor to ask for evidence that the primary control operated for the remaining part.

Common Mistakes

• Approving a workaround and never running it. The record says weekly review, and the tickets stop after the second week.
• No link to a risk. The substitute exists, but nobody can explain which risk it addresses.
• A substitute that addresses a different objective. A real control, but not a compensating one for this risk.
• No end date. A temporary substitute becomes a permanent, undocumented design change.
• Approval by the wrong person. The engineer who wanted the exception also approved the residual risk.
• Unclear population. Execution records exist, but nobody can show the full list of scheduled occurrences to sample from.
• Deleting records after restoring the primary control. The auditor still needs evidence for the period the substitute was active.

A Practical Operating Model

1. When a primary control cannot operate, open an exception record within a set number of business days.
2. Link it to a risk register entry that states the specific risk and affected scope.
3. Draft the substitute control design with an owner, frequency, inputs, and output.
4. Have a person with authority to accept risk approve the design and residual risk.
5. Schedule recurring tickets or checklists for every occurrence.
6. Review the decision on a set date, and record the outcome.
7. Restore the primary control, capture evidence, and retire the substitute.
8. Keep the full record for the audit period.

Framework Notes

The AICPA Trust Services Criteria cover risk identification (CC3.2), selection of control activities (CC5.1), and evaluation and communication of deficiencies (CC4.2). They do not define a required compensating control template. PCI DSS has a formal compensating control concept with a documented worksheet, described in its appendices, which is a useful reference for structure even outside payment environments. NIST SP 800-53 Rev. 5 uses the term compensating controls for controls employed in place of baseline controls that provide equivalent or comparable protection. ISO/IEC 27001:2022 clause 6.1.3 covers information security risk treatment and the Statement of Applicability, where substitute controls and justifications are often recorded.

How AuditFlo.co Helps

AuditFlo.co helps teams retain continuous evidence collection and audit-period history for operational artifacts when those records are stored or linked through connected systems and workflows your team already uses, such as GitHub and Jira.

For compensating controls, that can mean dated history for exception tickets, approval records, and recurring review tasks, so you can show the substitute ran across the period without rebuilding it from memory. Your ticketing, code, and documentation tools remain the systems of record. AuditFlo.co does not design or approve your compensating controls, does not issue SOC 2 reports, does not certify compliance, and does not replace auditors.

To see the workflow for your stack, request a demo.

Final Thoughts

A compensating control is only as strong as its records. Tie it to a specific risk, design it to address the same objective, get the residual risk approved by the right person, run it on schedule, and retire it cleanly when the primary control returns. If you can show that chain for the period, a temporary gap becomes a managed decision instead of an audit exception.

For related evidence, see Exception Management and Audit Findings Remediation, Risk Register Evidence for SOC 2, Risk Assessment Evidence for SOC 2, What Is a Key Control?, and how to prepare for a SOC 2 audit.

FAQ

Does SOC 2 require compensating controls?

SOC 2 does not require compensating controls as a specific mechanism. It expects risks to be identified and mitigated and deficiencies to be communicated. When a primary control cannot operate, a documented compensating control is a common way to show the risk is still managed.

Can a compensating control prevent an exception in a SOC 2 Type 2 report?

It depends on your control description, the substitute's design, and the auditor's judgment. A well-documented substitute that ran consistently may support your position, but the auditor may still report the primary control gap. Discuss it with your auditor before fieldwork.

Who should approve a compensating control?

Someone with authority to accept the residual risk, usually a security, engineering, or business leader who is independent of the person requesting the exception. Record the approver and date.

How long can a compensating control stay in place?

SOC 2 does not set a limit. Most teams treat compensating controls as temporary, set a target end date, and review the decision on a schedule. If the substitute becomes permanent, update the control design and system description accordingly.

What is the difference between a compensating control and risk acceptance?

Risk acceptance means deciding to live with a risk without additional mitigation. A compensating control adds a substitute activity that reduces the risk. Many compensating control records also include acceptance of the residual risk that remains.

Does AuditFlo.co approve or run our compensating controls?

No. Your team owns the design, approval, and execution. AuditFlo.co helps organize dated evidence such as tickets, review history, and workflow records from systems you already use, and does not replace your auditors.