Operational guidance, not legal advice. This page distills named public sources (regulator guidance and industry practice). It is not a legal determination, not a notification decision, and not a substitute for your counsel, insurer, or a retained DFIR firm. Verify applicability and current deadlines for your facts and jurisdiction.
How do you track accepted security risk?
Updated
Tracking accepted risk means recording every not-fixed-now finding as a time-boxed, owner-signed exception, not a silent skip. The record needs a named owner, a justification, any compensating control, and an expiry date. This page describes best practice and framework expectations, not a guarantee. Not legal advice.
Tracking accepted risk, last verified 10 September 2026, against NIST SP 800-30 and SP 800-39, ISO/IEC 27001:2022 Clause 6.1.3 and Clause 8.3, and AICPA SOC 2 Trust Services Criteria CC3 and CC7. It is not legal advice and does not determine that any specific framework's risk-acceptance requirement applies to YOU.
This is a risk-acceptance record, not YOUR risk decision
Audience: a CISO, risk owner, or compliance lead who needs deferred or accepted findings to survive an audit rather than quietly disappear. This page is not legal advice. It does not decide whether any specific finding should be accepted, does not assign YOUR owner, and does not determine that any framework's risk-treatment requirement applies to YOU.
Accepting a risk is a decision, not an absence of one. A finding left open with no due date, no owner, and no record is not 'accepted' — it is unmanaged. A defensible exception record makes the decision, the reasoning, and its expiry visible to the next person who reviews it, whether that reviewer is an internal team lead or an external auditor. Last verified 10 September 2026.
- Framework requirement versus best practice versus SRM-recommendation: NIST SP 800-30 and SP 800-39 are NIST guidance on risk assessment and risk management, not law in themselves. ISO/IEC 27001:2022 Clause 6.1.3 (risk treatment) and Clause 8.3 are framework requirements only if that certified ISMS applies to YOU. AICPA SOC 2 Trust Services Criteria CC3 (risk assessment) and CC7 (monitoring) are framework requirements only if a SOC 2 examination covering them applies to YOU. A recommendation to time-box and sign off every exception in this product is an SRM-recommendation, not a legal determination.
- The vulnerability remediation SLAs, program-checklist, and prove-remediation guides on this site are live or ship alongside this page. A dedicated vulnerability-vs-exploit-vs-risk, CVE-vs-CWE-vs-CVSS, what-is-KEV, how-to-prioritize-vulnerabilities, exploitability-vs-severity, remediation-timeframes, what-is-an-SBOM, end-of-life-dependencies, detect-vulnerable-open-source-packages, handle-zero-day, and how-ShipReadyMetrics-prioritizes-risk guide either ships alongside this page or is not on this site yet; naming any that are not yet live is not a link.
Exception-record template — the fields an auditor expects
The table below lists the fields a defensible accepted-risk exception record typically carries. It is a best-practice template, not a form this page fills out for YOU, and completing it is not itself a determination that acceptance is the right call for any given finding. Last verified 10 September 2026. Not legal advice.
| Field | What it captures | Why an auditor asks for it |
|---|---|---|
| Owner | The named individual who accepted the risk — a person, not a team name or a queue. | A team cannot be held accountable for a review date; a named person can. This is the single most common gap auditors flag. |
| Justification | Why the finding is not being fixed now: cost, operational constraint, low exposure, a planned decommission, or another stated reason — not 'not a priority' left unexplained. | A justification lets a reviewer judge whether the reasoning still holds, rather than trusting that it once did. |
| Compensating control | Any control that reduces the risk in place of the fix — a network restriction, additional monitoring, a WAF rule, or reduced access — or an explicit statement that none exists. | A risk accepted with no compensating control and one accepted with a strong one are not the same risk, and an auditor will ask which applies. |
| Expiry or review date | A specific date by which the exception must be re-reviewed or automatically re-opened — not 'ongoing' or left blank. | An exception without an expiry is a permanent waiver in practice, which is the pattern auditors are trained to distrust most. |
| Sign-off | Confirmation that the named owner, and where required a second approver, actually reviewed and approved the specific exception — a timestamped approval, not an assumed one. | Sign-off is what turns 'someone probably knew about this' into evidence that someone specific decided it. |
| Linked finding identifier | The specific finding or findings the exception covers, referenced by their own identifier rather than described in prose alone. | A record that cannot be traced back to a specific finding cannot be checked against that finding's current state, including whether it has since been fixed anyway. |
Time-boxing and owner sign-off — the two non-negotiables
Of the five fields above, two do the most work: an expiry date and a named sign-off. Without an expiry, an accepted risk becomes an indefinite exemption that nobody revisits until an incident or an audit forces the question. Without a named sign-off, the record shows that a risk existed, not that a specific person weighed it and accepted it — which is a materially weaker claim in a review. Last verified 10 September 2026. Not legal advice.
Time-boxing does not mean every exception gets a short deadline; it means every exception gets a stated one, chosen deliberately, that triggers a re-review rather than lapsing silently. A finding accepted for six months because a dependent system is being decommissioned on a known date is a well-time-boxed exception. The same finding accepted with no date attached is not, regardless of how good the underlying reasoning was.
- Set the expiry to a real event where possible — a decommission date, a contract renewal, a planned migration — rather than an arbitrary interval.
- Re-review at expiry rather than auto-renewing; if the justification still holds, record that explicitly rather than letting the old record silently persist.
- A sign-off from the finding's own owner is a start; a second, independent approver for higher-severity exceptions is stronger evidence of governance, not just of one person's judgment.
- Treat a finding whose expiry has passed with no re-review as functionally open again, not as still-accepted, until someone actually revisits it.
Framework requirement versus best practice versus SRM-recommendation
The table below labels each text this page relies on. Do not treat NIST guidance as a certification standard, and do not treat a product recommendation as a legal requirement. Last verified 10 September 2026. Not legal advice.
| Text | What it is | What this page does not do |
|---|---|---|
| NIST SP 800-30 (Guide for Conducting Risk Assessments) and SP 800-39 (Managing Information Security Risk) | NIST guidance on risk assessment and risk management, not law in themselves. | Does not treat this NIST guidance as a certification requirement or a statute. |
| ISO/IEC 27001:2022 Clause 6.1.3 (risk treatment) and Clause 8.3 (risk treatment implementation) | Framework requirement, only if that certified ISMS applies to YOU. These clauses govern how a risk-treatment plan, including acceptance, is selected and implemented. | Does not determine that Clause 6.1.3 or 8.3 binds YOU, and is not a certification decision. |
| AICPA SOC 2 Trust Services Criteria CC3 (risk assessment) and CC7 (detection and monitoring) | Framework requirement, only if a SOC 2 examination covering those criteria applies to YOU. | Does not determine that CC3 or CC7 binds YOU, and does not represent an auditor's testing procedures. |
| This product's cyber risk register and finding status | ShipReady recommendation: time-box and sign off every accepted or deferred finding. Not a legal determination. | Does not decide whether acceptance is the right call for any specific finding. A named human still owns that decision and its sign-off. |
Common exception-record gaps auditors flag
The gaps below recur across audit types more than any other pattern in an accepted-risk register. Naming them is not a claim that avoiding them guarantees a clean audit — that depends on the specific engagement and framework. Last verified 10 September 2026. Not legal advice.
- An exception with no expiry date, effectively a permanent waiver with no scheduled re-review.
- An owner field naming a team or a distribution list rather than a specific individual.
- A justification that restates the finding ('low priority') rather than explaining why acceptance, rather than remediation, is the right call.
- A compensating control claimed in the justification but never separately recorded or verified as actually in place.
- An expired exception still showing as accepted, with no record that anyone re-reviewed it at the review date.
- A whole class of findings accepted at once with one generic justification, instead of each distinct finding recording its own reasoning.
Accepted risk versus deferred risk — a useful distinction
Not every not-fixed-now finding is the same kind of decision. 'Accepted' typically means a considered judgment that the risk, given its compensating controls, is tolerable for a defined period. 'Deferred' typically means the fix is planned but not yet scheduled or resourced — a queued intention, not a risk judgment. Using one label for both blurs a distinction an auditor is likely to ask about directly. Last verified 10 September 2026. Not legal advice.
- Accepted: a deliberate risk-tolerance decision, with the fields above completed and signed off.
- Deferred: a scheduling decision — the fix is intended, just not yet done — which still needs an owner and a target date, even if the justification is capacity rather than risk tolerance.
- Neither label should be used for a finding nobody has actually looked at yet; an unreviewed finding is neither accepted nor deferred, it is simply open.
- A finding can move between the two states over its life — deferred while awaiting a maintenance window, then accepted if that window keeps slipping and a genuine risk judgment replaces the scheduling one.
What to do now
The list below is operational preparation. It does not decide whether accepting a specific risk is the right call for YOUR organization. Walk it with your risk owner and, where a framework applies, against that framework's own text. Last verified 10 September 2026. Not legal advice.
- Never let a finding sit 'not fixed, not tracked' — every deferred finding gets an exception record, even a minimal one, the moment it is deferred.
- Distinguish acceptance from deferral in the record itself, using the distinction above, rather than one catch-all status for both.
- Assign a named owner, not a team or a queue, to every accepted-risk record.
- Attach an expiry or review date to every record, tied to a real event where one exists, rather than an arbitrary interval.
- Record the compensating control, or explicitly record that none exists, rather than leaving that field implicit.
- Re-review at expiry and record the outcome — renewed, closed, or escalated — rather than letting the record silently lapse or silently persist.
- Keep the accepted-risk register separate from, but linked to, the underlying finding, so a reviewer can trace from either direction.
Where this shows up in ShipReady Metrics
If you already have a session: signed-in app → Security holds a cyber risk register alongside the findings list, where a finding's status can be set to accepted or deferred, with an expiry date, when a named human records that decision. That status feeds visibility elsewhere in the product, such as the obligation map, without becoming a legal filing.
That risk register is not itself a risk-acceptance decision, and it does not decide whether accepting a given finding is appropriate for YOUR organization. It does not enforce compensating controls, does not determine that ISO/IEC 27001:2022 Clause 6.1.3 or SOC 2 CC3 is satisfied, and does not auto-approve or auto-expire an exception without a human action. A named human still owns the owner field, the justification, the sign-off, and the review at expiry. This page does not document a public demo URL.
Primary sources (last verified 10 September 2026)
Every claim on this page is taken from one of these. If a later revision of a source changes the rule, the date above is how you can see we have not re-checked yet.
NIST SP 800-30 Revision 1, Guide for Conducting Risk Assessments, and NIST SP 800-39, Managing Information Security Risk, are NIST guidance, not law in themselves. ISO/IEC 27001:2022 Clause 6.1.3 (information security risk treatment) and Clause 8.3 (implementation of the risk treatment plan) are a framework requirement only if that certified ISMS applies to YOU. AICPA's SOC 2 Trust Services Criteria CC3 (risk assessment) and CC7 (detection and monitoring) are a framework requirement only if a SOC 2 examination covering them applies to YOU. These are not a complete world list. Not legal advice.
The vulnerability remediation SLAs, program-checklist, and prove-remediation guides on this site ship alongside this page. The vulnerability-management glossary entry on this site is the education page under glossary. A dedicated CRA-cluster or EU AI Act risk-acceptance walkthrough is not this page; those clusters have their own risk-register material where it exists.
Every figure and clause reference above is checked against the cited source's own current text, not a paraphrase carried over from an earlier revision.
Frequently asked questions
Is this legal advice?
No. It is a best-practice exception-record template distilled from NIST SP 800-30/800-39, ISO/IEC 27001:2022 Clause 6.1.3 and 8.3, and AICPA SOC 2 Trust Services Criteria CC3/CC7. Whether any of those frameworks applies to YOU, and whether accepting a specific risk is appropriate, is a question for your own risk owner and, where relevant, counsel. This page is not legal advice.
Is leaving a finding open with no due date the same as accepting the risk?
No. An unmanaged finding with no owner, no justification, and no expiry is not an accepted risk — it is an untracked one, and it is the pattern most likely to draw an audit finding of its own. An accepted risk is a deliberate, signed, time-boxed decision, not the absence of a decision.
Does an accepted-risk record need an expiry date?
Yes, as a best practice. An exception with no expiry functions as a permanent waiver in practice, which most frameworks and most auditors treat as a governance gap even when the underlying technical reasoning was sound at the time. Set a real date, tied to an event where possible, and re-review at that date.
Who can accept a risk?
This page does not decide who at YOUR organization can accept a risk. As a best practice, the record should name a specific individual — not a team or a queue — and higher-severity exceptions typically warrant a second, independent approver alongside the finding's own owner.
Does ShipReady Metrics decide which risks to accept?
No. Signed-in app → Security holds a cyber risk register where a finding's status can be set to accepted or deferred with an expiry, but only when a named human records that decision. It does not decide whether acceptance is appropriate for any specific finding, does not enforce compensating controls, and does not auto-expire an exception without a human action.
What is the difference between accepting and deferring a risk?
Accepting is a deliberate risk-tolerance judgment: the finding will not be fixed for a defined period, given its compensating controls. Deferring is a scheduling decision: the fix is planned but not yet resourced. Both need an owner and a date; conflating them under one label makes it hard to tell a risk decision from a backlog item at a glance.
Does a compensating control have to exist for a risk to be accepted?
No. A risk can be accepted with no compensating control if the justification supports that on its own — but the record should say so explicitly rather than leaving the field blank. An accepted risk with a documented compensating control and one with none are different risk profiles, and a reviewer should be able to tell which is which without guessing.
Published by ShipReady Metrics, an evidence-based technology and compliance intelligence platform. This guide is educational and vendor-neutral.