Writing a Compensating Control With a Named Owner and Review Date

Every control that survives contact with reality has the same three components. Strip out any one and you have a sentence, not a safeguard.

A specific signal tied to the gap. The signal must move when the exposure grows, and it must come from a system that records it whether or not anyone is looking. Examples: count of privileged accounts unreviewed past the cycle, number of allowed actions taken by an agent outside an approved tool list, percentage of vendor invoices that skipped the second approver. A signal that cannot fail silently is worth more than a clever one that depends on someone remembering to run a query.

A named person who reads it on a cadence. Not a team, not a distribution list, not "the security team." A person whose name appears in the record, with a backup named in the same line. Cadence is explicit: daily, weekly, monthly, per release. "Continuously monitored" is not a cadence; it is a description of a tool, not of a reviewer.

A review date that forces a decision. On that date, the owner chooses one of three outcomes: keep (the control still reduces the risk and the gap still exists), tighten (the control is weakening or the exposure is growing), or retire (the primary control landed or the gap closed). Retiring is a real outcome, and writing it as an option prevents the default of silent renewal.

The greenfield counterexample: a team accepts a gap in phishing-resistant multifactor authentication for a SaaS supplier because the vendor uses an app-based factor. A weak note says "MFA exists; risk accepted." A usable control says: privileged supplier accounts are listed and reviewed monthly against a named-admin allowlist, the review is logged, session elevation requires a ticket, and the acceptance expires in 120 days unless a fresh decision is approved (MTF Institute).

Note what the exit criterion does: it converts a temporary measure into something that can actually end. Without it, "temporary" means "until someone notices," which in practice means forever.

Keep the instrument to one page. If it does not fit, the control is too vague to be tested. The fields below are the minimum set practitioners converge on: service or system, business and technical owner, the standard being bypassed, the reason the control cannot be met, the risk statement in plain language, compensating controls, expiry date, approval authority, review evidence, and a closure or renewal plan (Product Security Handbook).

COMPENSATING CONTROL RECORD
1. Gap: what the environment cannot do now, with counts and dates
2. Exposure: one concrete failure scenario a reader can probe
3. Control: the artifact (rule ID, allowlist, feature flag, queue, review)
4. Signal: name, source system, query or dashboard link, threshold
5. Owner: named person, backup, cadence, escalation path
6. Review date: date plus required decision (keep / tighten / retire)
7. Exit criterion: the event that closes this record

Field 1 deserves care. A gap statement is not a restatement of the control requirement. "Privileged access reviews are not completed on a defined cycle" describes a missing process; "twenty-three privileged accounts have not been reviewed in the current period, and if any belong to a separated employee, there is no mechanism to detect lateral movement from those accounts until the next scheduled review" describes what the environment cannot do, with consequences the signer can test (SC Media).

Field 3 should cite a concrete artifact. A control with no artifact reference cannot be tested, which is why auditor-facing guidance asks for the firewall policy name, rule ID, configuration flag, or feature toggle, plus a coverage scope that lists exclusions (Seal Security).

Field 4 is where most records decay. Write the query, or the exact filter, next to the signal name. If a future owner cannot re-derive the number from the source system, the signal is a memory, not a measurement.

Field 7 should be a closing event, not a date. "Exception closes when the vulnerable package is patched and the scanner shows clean," "when the allowlist has zero additions for two cycles," "when the primary control passes its test." A date can pass; an event has to happen.

The test for a good signal is simple: imagine the risk doubling tonight. Which number changes by tomorrow morning, and would anyone see it? If the answer is "none, until the next annual assessment," you have chosen the wrong signal.

Start from the failure scenario, not from the metric catalog. Write the scenario as one sentence: if a threat happens while the gap exists, then an asset may experience an impact. Then walk the chain and ask where evidence would appear. A leaked credential appears in impossible-travel alerts. Misuse of an agent's tool access appears in tool-call logs with actor and action. A stalled review appears in a count of items older than the cycle. Use two ratings, inherent exposure and residual exposure after verified safeguards, and compute both from the signal, not from the questionnaire average (MTF Institute).

A worked example with real arithmetic on the record, not invented risk scores:

• Gap: 23 privileged accounts unreviewed. Signal: count of accounts past the review cycle, pulled from the identity provider on the first business day of the month.
• Threshold: alert the owner when the count exceeds 10, or when any account is flagged as belonging to a separated employee.
• Cadence: monthly read by the named owner, with a quarterly second read by the risk function.
• Review date: 90 days. Decision options: keep, tighten (reduce the unreviewed ceiling to 5), retire (all accounts reviewed on cycle).
• Exit criterion: two consecutive months at zero unreviewed accounts.

The thresholds do the governing. A ceiling of 10 is a decision someone made and can revisit; "monitor for anomalies" is not.

For agentic systems, the same logic applies to a narrower surface. OWASP's guidance for prompt injection is blunt that fool-proof prevention is unclear, so the control must reduce impact rather than promise immunity: enforce least privilege, keep functions in code rather than giving them to the model, segregate untrusted content, and require human approval for high-risk actions (OWASP LLM01). Each of those is testable. "The agent cannot call the payment tool without an approval ticket" produces a log you can count. "The agent is prompted to be careful" produces nothing.

An agent with untrusted input, access to sensitive systems, and the ability to change state or communicate externally should get per-action human approval under a strict reading of the dual tests OWASP cites, and any agent combining untrusted input with either of the other two calls for a written risk assessment (Anaconda). That written risk assessment is the record above, and the human approval is the control. If you are operating agents at that level of exposure, a governed one-API setup for every model type removes a class of key-sprawl and per-vendor visibility gaps: Quanta Inference routes text, image, video, audio and embedding models through one OpenAI-compatible key, which makes the "which model did what" part of the signal source easier to read.

Ownership has three roles, and collapsing them is a common error.

• The risk owner signs the acceptance and carries the consequence. This is the executive whose name is on the record.
• The control owner operates the signal: reads it, files evidence, escalates. This is the named person in field 5.
• The reviewer challenges the control at the review date. This is usually the risk or security function, and it must not be the control owner.

If the risk owner and the control owner are the same person, the cadence still needs to exist in writing, because the evidence is what an auditor will ask for. If the reviewer is the control owner, the review is self-assessment and will not survive scrutiny.

Cadence follows exposure, not calendar convenience. A reasonable default: weekly reads for signals that can move on a human timescale (privileged access, agent tool calls, payment exceptions), monthly for supply-chain and vendor signals, and per-release for anything tied to a deployment. Whatever the cadence, it must appear with the reviewer's name, the day of the week or day of the month, and the escalation path if the threshold is crossed mid-cycle.

Escalation should have a named trigger and a named destination. "Immediate escalation after any privileged-account incident" is the kind of condition that belongs in the record, next to a suspension or exit trigger for the underlying service (MTF Institute).

Escalation also needs a link into the backlog, not just into a chat channel. Exception systems that do not integrate with the backlog or review cadence are specifically called out as a pattern to avoid, along with exceptions that have no named business owner and renewals approved without asking whether the standard itself is wrong (Product Security Handbook).

The review date is the mechanism that stops a temporary measure from becoming architecture. Make the decision structural: on the date, the record cannot be renewed by silence. Absence of objection is not acceptance, and documented, explicit authorization is the standard that decision records are held to (SC Media).

Three questions carry the review, and each has a required evidence artifact:

An annual review is common, but the interval should be shorter when the environment changes faster than the year. The point of the review is to test whether the compensating control still matches the current system, threat, and business context; the approved workaround may have been reasonable when the asset, data classification, architecture, or operational dependency looked different (NHI Mgmt Group).

Watch for exception sprawl. One undocumented waiver tends to become the template for others under delivery pressure, and a pattern of renewals without evidence is a signal that the standard itself, not the exception, needs revisiting. Track exception age and concentration, not just the total count, and escalate repeated requests from the same service (Product Security Handbook).

Retirement deserves its own line in the record. When the primary control lands, the compensating control should be removed deliberately, with the removal noted and the monitoring that supported it either retired or repurposed. A control that outlives its gap is a false sense of security with a monthly meeting attached, which is precisely the risk that untested compensating controls create (Fortinet).

The test is not "does the control exist" but "does the control block the path." For each record, the evidence set should include the specific attack path the control interrupts and the test output, exploit-attempt log, or rule-hit telemetry dated after deployment, showing exploitation is blocked rather than merely harder (Seal Security).

A lightweight test cadence that works for most teams:

1. Run the signal query manually once, and file the output with the record. This proves it is reproducible.
2. Simulate the failure path in a non-production environment and confirm the control fires and the alert reaches the named owner.
3. Re-test after any change to the environment, the identity provider, or the tool configuration, and date the result.
4. At the review date, attach the most recent test, the recent signal history, and the current scope list to the decision.

Pattern a control after the OWASP checklist entries your design touches rather than all of them, and say why the rest do not apply; for an app that reads user input or outside content, treat prompt injection as something that will get through and make the compensating control about blast radius (Anaconda). The governance checklist from the OWASP GenAI project is built for the same cross-functional audience you will be presenting to, including compliance and legal readers who need to follow the record without translation (OWASP GenAI).

If your organization runs a portfolio of AI controls and you want a second pair of eyes on which signals and thresholds are realistic, a short structured session with people who do this for a living is often faster than another internal template revision: Quanta Consulting offers a free 30-minute discovery call with no obligation.