Segregation of duties exceptions: the compensating control that compensates for nothing

Every ERP estate has an exception register. It is the document an ITGC auditor samples first, and it is a list of accepted risks whose mitigations are described in prose and evidenced by nothing.

Part of Access governance and certification

Prerequisites

• Your current SoD exception register, exported.
• The ruleset that generated the conflicts, with its version history.
• For a sample of ten exceptions, whatever evidence exists that the compensating control operated in the last quarter.

Step 1 — Age the register

Sort exceptions by approval date and plot the distribution. The shape tells you most of what you need.

The bottom two rows are usually the majority. An exception register that only grows is not managing risk; it is recording the accumulation of it.

Step 2 — Test the compensating controls

Take ten exceptions and ask, for each: what evidence exists that the stated compensating control operated during the last quarter?

Common compensating controls and what evidence typically exists:

Rows one, two and five are where the sampling fails. The control is described as operating and nothing records that it did.

Step 3 — Render the conflict in business terms

An approver signing off an SoD exception is typically shown a rule code and a technical description: SOD-P2P-014: Create Vendor / Post Invoice.

What they need to see is the business consequence: this person can create a vendor and then pay it, without another human being involved. The second formulation produces different approval decisions than the first, and it costs nothing but the description.

Step 4 — The Exception Evidence Standard

{
  "type": "manav-stmt/1",
  "action": "sod_exception_approval",
  "render": [
    "Conflict: [business-language description of what becomes possible]",
    "Ruleset: [id, version]",
    "Individual: [name, role]",
    "Business justification: [text as written]",
    "Compensating control: [named control]",
    "Control cadence: [monthly | per transaction | quarterly]",
    "Expiry: [date]"
  ],
  "approver": "[credential assertion]",
  "control_owner": "[credential assertion]"
}

Two signatures. The approver accepts the risk; the control owner accepts responsibility for operating the mitigation. Today the second person frequently does not know they have been named.

Step 5 — Link the control operations

This is the step that makes the register testable. Each operation of the compensating control emits its own receipt referencing the exception.

{
  "type": "manav-stmt/1",
  "action": "compensating_control_operated",
  "exception": "[reference to the approval receipt]",
  "period": "[month covered]",
  "scope": "[transactions reviewed: count, value]",
  "exceptions_found": "[count]",
  "operator": "[credential assertion]"
}

An auditor sampling the register can now follow an exception to its control operations and verify both. That is a different testing experience from reading a spreadsheet and asking for screenshots.

Failure traps

1. Setting expiry too long. Twelve months means one re-approval per year and re-approvals are rubber-stamped; six months with a business-language rendering produces actual re-examination.
2. Naming a compensating control nobody owns. If the control owner will not sign, the control does not exist and the exception should be re-evaluated.
3. Instrumenting the approval and not the control operations. That produces a well-evidenced record of accepting a risk and no evidence of mitigating it.
4. Keeping structural exceptions in the register. If the conflict is how the business runs, the answer is a process change or a documented risk acceptance at a higher level — not an exception renewed forever.

What a compensating control must have to count

A compensating control that nobody can show operating is a sentence in a register. Auditors accept them because the alternative is a finding on every exception, and the acceptance becomes permanent because nothing triggers a review.

Objections and honest limits

“Exceptions are reviewed annually.” The exception is reviewed — whether the conflict is still needed. The compensating control is usually re-copied rather than re-tested.

“Small teams cannot segregate everything.” True, and that is the legitimate case for exceptions. It is an argument for evidencing the mitigation properly, not for accepting an unverifiable one.

Making exceptions evidential

1. Require a named owner and a frequency. A control without either is a sentence.
2. Require evidence of operation. Per period, not per policy.
3. Sign the acceptance, with the mitigation stated. So the approver owns what they accepted.
4. Expire exceptions by default. Renewal should be a decision, not an inheritance.

Terms used here

Segregation of duties

Splitting a sensitive process so no single person can complete it alone.

Compensating control

An alternative measure accepted where segregation is impractical — and frequently unverified.

Exception register

The record of accepted conflicts, which in most organisations grows and is rarely pruned.

Frequently asked questions

What if the compensating control genuinely cannot be evidenced? Then it is not a control, and the exception is an unmitigated accepted risk. Recording it as such is more honest and escalates it to the right level.

Will this shrink the exception register? Usually, because requiring a control owner's signature surfaces exceptions whose mitigations were nominal. That shrinkage is the point.

Does this replace the GRC platform? No. The receipts sit alongside the platform's records and make them verifiable by a party who does not have access to it.

How does this affect ITGC testing? Sampling becomes verification rather than document review, which shortens testing and strengthens the evidence.

Why are compensating controls rarely tested? Because the register records a description rather than an owner, a frequency and evidence of operation.

Are SoD exceptions inherently bad? No. Small teams legitimately cannot segregate everything. The problem is accepting a mitigation nobody can show operating.

What is the single best change? Expire exceptions by default, so renewal is a decision rather than an inheritance.

Sources and further reading

• PCAOB AS 2201 — An Audit of Internal Control Over Financial Reporting
• ISACA — identity and access management audit resources
• CISA — known exploited vulnerabilities and incident reporting
• NIST SP 800-53 Rev. 5 — access enforcement