Risk Acceptance in Cyber Security Needs a Ledger
A worked example shows how to record who accepted a cyber risk, why the business is carrying it, and when to reopen the decision.
Every organization carries cyber risk. Some decide what they are willing to carry. Others keep pushing the decision into the next meeting.
Deliberate acceptance is a business decision. Someone with authority looks at a specific exposure, chooses to carry it for a reason, and sets a date to reconsider. A heat map can give the same color to that exposure and to the one nobody has decided on. The board needs a way to tell the difference.
Acceptance is a decision with a shelf life
The phrase I pay attention to is for now. The threat can change. The asset can become more important. A control that once reduced the exposure can stop working while the wording in the register stays exactly the same.
Cyber risk appetite gives leadership a broad direction. Risk acceptance applies it to a specific choice. What are we exposed to, why are we willing to carry it, and for how long?
What a risk acceptance ledger should contain
A colored square can show a rating. A ledger captures the decision, the people responsible for it, and what would cause them to reconsider. A spreadsheet is enough if someone owns it and keeps the entries current.
Consider a fictional SaaS company moving an internal reporting job to a new platform. The job still uses a long-lived API token. A replacement is planned. The company has to decide whether to retire the job early or carry the token risk while the migration finishes.
| Ledger field | Illustrative entry |
|---|---|
| Issue | A legacy reporting job uses a long-lived token to read support data. |
| Business reason | Operations uses the reports to manage its backlog. The sponsor agrees to keep the job until the replacement is running. |
| Residual exposure | The token has read access to the reporting dataset. It lives in a restricted vault and the team reviews its usage logs. Someone who obtains it could still use it to read the dataset. |
| Accountable owner | Head of Support Operations. |
| Authorized approver | COO under the company’s delegated risk policy. |
| Decision date | May 6. |
| Expiry | June 30. Review before then if the migration slips. |
| Reopen early if | The token scope expands, usage logging stops, or someone suspects the token has been exposed. |
The owner is responsible for the job and the conditions of the acceptance. The approver has authority to make the business tradeoff. Security can verify the evidence and advise both people. Put the names of the people who hold those roles into the real record so the next reviewer knows who made the decision.
Expiration dates change behavior
An expiry gives the owner a reason to bring back current evidence. Is the job still running? Are the conditions still met? Did the replacement get tested? If the business wants more time, put a new decision in front of someone with authority and record the reason.
Repeated extensions tell you where to look. One may reflect a dependency. Several on the same issue may point to a funding decision nobody is making. A cybersecurity board report can show that pattern and the material decisions that need attention. Management can keep the full ledger.
Put the decision back on the record
Pick one exception your team has extended twice. Find the name of the person who accepted it, the reason the business is carrying it, and the evidence you will look at before the next review. If you can’t find those things, you have your next decision.
Maintaining that connection between evidence, owners, and decisions is part of fractional CISO leadership.
