Writing a risk acceptance record the accepting executive can sign

Picture an acceptance record signed eighteen months ago. An auditor asks the signing VP to walk through what she accepted. She cannot name the control. She cannot describe the gap. She signed a form that said "residual risk: medium" and moved on. The record is now the evidence and it proves she did not understand what she accepted. That failure belongs to whoever prepared the record. A risk acceptance record is not a filing mechanism; it is the formal instrument by which an accountable executive takes personal ownership of a known gap and its consequences for a defined period. If the record cannot be explained by the person whose name is on it, it is not a valid acceptance — it is a signature on a document she was not equipped to evaluate. NIST SP 800-37 Rev. 2 makes this explicit: the authorization decision must be documented and conveyed as an explicit act by the authorizing official, not inferred from silence or a lack of objection (Source: NIST SP 800-37 Rev. 2, https://csrc.nist.gov/publications/detail/sp/800-37/rev-2/final). The same principle applies to control-level acceptance decisions. Absence of rejection is not acceptance. GRC's role is to prepare a record the signer can interrogate, not one that makes the signer's job easier by hiding complexity. Every field that cannot be verified by the signer is a field that will not hold under audit, litigation, or regulatory review. Stating the gap without restating the control The gap statement is the single most frequently miswritten field in acceptance records. GRC teams often paste in the control description and mark where it falls short — which tells the signer what the control was supposed to do, not what is actually missing. The gap statement must describe what the environment cannot do right now, in terms that have observable consequences. "Privileged access reviews are not completed on a defined cycle" is not a gap statement — it is a restatement of the control requirement. The gap statement is: "Twenty-three privileged accounts have not been reviewed in the current period. If any of those accounts belong to a separated employee or a compromised credential, the environment has no mechanism to detect lateral movement from those accounts until the next scheduled review." This formulation gives the signer something she can test. She can ask: how many accounts? When were they last reviewed? What would we see if one was misused? The acceptance record receives that handoff and translates it; it does not re-author the test. Gap statements may benefit from a one-sentence scope qualifier — the specific system, environment, or population affected — so the signer does not inadvertently accept a gap that is broader or narrower than she intends. The risk the gap creates in terms the signer can test Risk language in acceptance records defaults to the abstract: "may result in unauthorized access," "could impact confidentiality." These formulations are not testable. A signer cannot verify whether "may result in unauthorized access" is accurate, how likely it is, or what it would cost. Translate the gap into at least one concrete failure scenario the signer can probe. Not a threat model but a plausible chain: who could exploit this gap, through what mechanism, to achieve what outcome, affecting what system or data population. The scenario does not need to be exhaustive. It needs to be specific enough that the signer can ask a follow-up question and get a verifiable answer. The acceptance record should carry the severity conclusion forward, not re-derive it. If the classification is contested or has changed since testing, note the current status explicitly. Regulatory mapping belongs here as well, because it tells the signer which external obligation the gap touches. If the gap maps to a control under a framework the organization is audited against, that mapping should appear in the record so the signer understands the audit exposure and not only the operational one. A signer who learns at audit that the gap she accepted was also a reportable control failure was not given the record she needed. Compensating controls named and qualified A compensating control is only as useful as its tested status. Listing compensating controls without stating whether they have been tested, what period they cover, and whether any deficiencies exist in those controls tells the signer that coverage exists. It does not tell her that coverage works. Each compensating control entry in the acceptance record should carry: the control name and owner, the most recent test result and test date, the period covered, and a plain-language statement of what the compensating control actually reduces — not what it is supposed to reduce. "Network access logging is enabled and reviewed weekly" is not qualified. "Network access logging captures lateral movement attempts at the perimeter; it does not capture account activity within the privileged tier where the gap exists" is qualified, and it is honest. Compensating-control testing in a control-assurance context is a distinct discipline. GRC-EXC-PRAC-010 owns that testing process; do not conflate it with the record's documentation of tested status. The signer's test question for this section: "If the compensating control failed tomorrow, what would I lose?" If the record cannot answer that, the compensating controls section is incomplete. Residual risk as a statement not a score Risk scores in acceptance records create a specific failure mode: the signer signs the number without understanding what the number represents. A residual risk rating of "medium" carries no operational content. It cannot be defended in an audit without the underlying rationale, and the rationale is usually in a methodology document the signer has never read. Replace the score — or supplement it — with a plain statement of what risk remains after compensating controls, expressed in terms the signer can evaluate. The statement should name the scenario that compensating controls do not fully prevent, the population or system exposed to that scenario, and the expected consequence if the scenario occurs. If the program's risk scoring methodology requires a numeric or categorical rating, retain it for register consistency but do not let the score substitute for the statement. Auditors and regulators can interrogate a statement. They can also interrogate a score — and if the signer cannot explain what produced it, the score becomes evidence of a process she did not engage. The named accountability that cannot be delegated GRC prepares the record. GRC does not accept the risk. The distinction is not procedural — it is the entire point of the acceptance record. The IIA Three Lines Model is explicit: accountability for achieving objectives, including accountability for risk, remains with management and the governing body. It is not transferred by the provision of assurance, analysis, or advisory work from a second or third line (Source: IIA Three Lines Model, https://www.theiia.org/en/content/position-papers/2020/the-iias-three-lines-model-an-update-of-the-three-lines-of-defense/). A GRC manager who signs an acceptance record on behalf of an executive — or who prepares a record so opaque that only GRC can explain it — has inverted the model. The named accepting executive field must carry the specific individual's name and title, not a role or a committee. Committees do not accept risk in a way that produces personal accountability; they deliberate, and a named individual ratifies. That individual is the person auditors will ask to explain the record. The acceptance period is a decision the accepting executive makes, not a default the record template provides. The period should reflect the timeline for remediation, the organization's risk appetite, and any regulatory cadence that governs re-review — for example, some control frameworks require that accepted exceptions be reviewed at a defined interval determined by policy, not by the template. What drives that interval is the combination of remediation feasibility, threat exposure, and the organization's documented tolerance for the gap. GRC should present the rationale for a proposed period; the signer should confirm it. Re-review dates are not optional. An acceptance without a re-review date is an indefinite acceptance, which is not an acceptance at all — it is an exemption with a signature. What makes a record unsignable A record is unsignable when any of the following are true: the signer cannot identify the gap from the gap statement; the compensating controls listed have no tested status; residual risk is expressed only as a score with no supporting rationale the signer can evaluate; the accepting executive field names a role rather than a person; or the acceptance period has no defined re-review date. During audit, an acceptance record that cannot be explained by the signer functions as evidence of a deficient process, not as evidence of a managed risk. The record either demonstrates that a real decision was made by an accountable person, or it demonstrates that the program generates paper. Acceptance Record Field Table | Field | What It Must Establish | What Makes It Signable | Weak Form | What The Signer Cannot Verify If It Is Weak | |---|---|---|---|---| | Gap Being Accepted | What the environment cannot do right now, scoped to the affected population or system | A plain-language description with a named scope — not the control requirement restated | "Control XYZ is not fully implemented" | Whether the gap affects her environment, her systems, or her team | | Risk The Gap Creates | A plausible failure scenario with a named actor, mechanism, and consequence | Specific enough that the signer can ask a follow-up question and get a verifiable answer | "May result in unauthorized access" | Whether the risk is material to her accountability, or what a bad outcome would look like | | Compensating Controls And Tested Status | Each control named, owned, tested, and scoped to what it actually reduces | Tested status with test date and period; honest statement of what is and is not covered | "Compensating controls are in place" | Whether the compensating controls work, and whether any of them have their own deficiencies | | Rationale For Acceptance Over Remediation | Why remediation is not the chosen path for this acceptance period | Named constraints — cost, feasibility, dependency, sequencing — with a realistic remediation horizon | "Remediation is planned" | Whether the rationale is genuine or the control is simply deprioritized with no plan | | Residual Risk | What risk remains after compensating controls, in terms that can be evaluated | A statement naming the scenario compensating controls do not fully prevent, and the exposed population | A categorical score with no supporting explanation | What the score means, how it was derived, or whether it reflects the actual gap | | Acceptance Period And Re-Review Date | The bounded window within which the gap is accepted, with a specific re-review date | A defined end date tied to a remediation milestone or a mandatory re-review cycle | No end date, or a re-review date set by template default | Whether the acceptance is bounded at all, or whether it will persist beyond any reasonable window | | Named Accepting Executive | The specific individual who owns the risk for the acceptance period | Full name and title; confirmed by the individual's signature on the final record | Role name, committee name, or delegate signature | Who is personally accountable, and who auditors should address questions to | Sources - NIST SP 800-37 Rev. 2: https://csrc.nist.gov/publications/detail/sp/800-37/rev-2/final - IIA Three Lines Model: https://www.theiia.org/en/content/position-papers/2020/the-iias-three-lines-model-an-update-of-the-three-lines-of-defense/