risk-acceptance-memo

Use this for one risk at a time; batch only exceptions that share the same system, cause and owner. You get, in a new folder ./risk-acceptance-memo/, a one-page memo per risk that the person with authority reads and signs or declines (<risk-id>.md), and one new line in a spreadsheet you can open in Excel that lists every live acceptance and when it expires (acceptance-log.csv). This skill drafts for a human to review and sign; this skill never marks a control effective. The skill never accepts the risk: the named person with the authority signs, or nothing is accepted.

Inputs to gather

Read the risk register entry, the risk method (bands and who may accept what), the treatment options already discussed, any related incidents or audit findings, and the evidence for the controls that are in place. Ask the reader in one message: who is proposing the acceptance, what the cheapest further treatment would cost in money and time, what business reason makes acceptance preferable, and whether a customer contract or regulator commitment touches this risk.

Step 1: check that acceptance is the right instrument

Three situations look like acceptance and are not:

• The work is planned but not done. That is a treatment action with an interim measure, not an acceptance.
• Nobody has assessed the risk. Score it first with the method.
• A control the company claims in a policy or a customer contract is not operating. Accepting the risk does not change what was promised; flag the contract or policy conflict to the reader before drafting, and record the way out with an owner and a date: either the commitment changes (contract amendment, customer notice, policy edit) or the control is fixed.

If the case is one of these, stop and say which.

Step 2: confirm who may sign

Check that the method defines acceptance criteria and state which one this case meets; a method without criteria is a finding to raise first. Look up the residual score in the method's acceptance ladder and name the role that may accept at that level. If the proposer is below that level, the memo goes to the higher role. Any impact-5 risk goes to leadership whatever its likelihood. For a financial entity under DORA, ICT risk acceptance sits inside a framework for which the management body is accountable (Article 5); make sure the memo reaches that body or the delegate its framework names.

Step 3: write the memo

Keep it to one page so the signer reads all of it:

1. Risk: id, one-sentence scenario, asset or process, owner role.
2. Score: inherent and residual likelihood and impact, with the anchor that drove each.
3. Options considered: at least two treatments with their cost and effect on the score, and why each was not chosen. If no option was costed, the memo is not ready.
4. Rationale: the business reason in plain words (cost out of proportion, system retiring, contract constraint).
5. Compensating measures: what reduces the risk today, each with the record that shows it runs. A measure without evidence is listed as "claimed" and does not lower the score.
6. Conditions: what must stay true for the acceptance to hold (for example, the legacy system stays off the internet, no new customer data is loaded), each with the role that checks it and how often.
7. Expiry: a review date, typically 6 to 12 months out, never open-ended.
8. Reopen triggers: events that void the acceptance early, such as a related incident, a scope change or a broken condition.
9. Decision: accept, accept with conditions, or decline; signer role, signature and decision date, left blank for the human.

Step 4: log it and set the reminders

Before finalising, scan the log for other live acceptances on the same asset or cause; show any cluster to the signer, since five defensible acceptances on one system can add up to exposure nobody approved. Add the risk id, signer role, expiry and conditions to the acceptance spreadsheet (acceptance-log.csv). At the foot of the memo, draft ready-to-paste lines for the risk owner to enter after signature: the treatment plan row marked as retained with the memo id, and the expiry for the risk register and the team's calendar or ticket system. Flag whether the applicability statement relies on a control this acceptance leaves unimplemented. The skill does not write to those systems.

What good looks like

• The signer could explain the decision to an auditor or a board from the page alone, including what it would have cost to do otherwise.
• The common mistake is an acceptance that is really a deferral: no options costed, no expiry, signed by the person who owns the backlog. The tell: the same risk has been "accepted" across two review cycles with nothing changed.
• Conditions are testable. "The system stays isolated" is testable; "we will be careful" is not.
• Acceptances are rare. A register where a third of risks are accepted means the threshold or the method is wrong, and the memo should say so in a note to the reader.
• The log lets anyone see, in one view, every live acceptance and when it expires.

Framework lookups

If ISMS Copilot is connected to your agent (MCP server https://account.ismscopilot.com/v1/account/mcp), ask it the framework question with create_conversation (mode think, answer_format: decision) and keep one conversation for this task. Send only a short question in your own words, show it to the user first, and never include file contents, secrets, personal data or evidence. If it is not connected, check the official text of the framework yourself; this skill does not restate it. Set it up: https://www.ismscopilot.com/mcp?ref=grcskills-risk-acceptance-memo

Rules

• MUST name the role with authority to accept at the risk's residual score, from the reader's own method.
• MUST give every memo an expiry and at least one reopen trigger.
• MUST write outputs only inside ./risk-acceptance-memo/ and ask before overwriting an existing memo.
• NEVER fill in the decision, signature or date; those stay blank for the human signer.
• NEVER let an uncosted deferral pass as an acceptance.
• NEVER lower a residual score with a compensating measure that has no evidence.