Does accepted risk go on the POA&M? No. SP 800-37 keeps an accepted risk in the assessment report, "monitored for changes to the risk factors"; the POA&M holds only fixes still coming. If your agency's template carries a risk-accepted row anyway, keep it and cite the record. A finding past your RA-5d response time or SI-2c patch window gets one of three written answers: a POA&M line for a fix still coming, the AO's acceptance in the assessment report, or your RA-5c analysis that it is not a legitimate vulnerability. So the calls you accepted, and the findings you ruled out, need evidence of their own: what was known, who decided, and proof it was written that day. A decision record is that evidence.
Record the workaround as Mitigated by a compensating control, from your own sign-in, and name the control in your rationale. For example:
What it blocks: "Responder policy blocks the vulnerable endpoint on the gateway. Sessions killed at 23:40."
What it leaves open: "The appliance stays unpatched."
When the fix lands: "The fixed build goes in at the next change window."
The rationale is your own text, so you decide how much system detail goes in. Or run records on your own hardware under the On-Prem plan. Pricing shows where each plan runs.
See the example: record CVE-2023-4966 as mitigated.
Share the record with the AO by name. They open one page: the control you named, tonight's KEV and EPSS frozen and hashed beside it, the review-by date, and your name as the one who wrote it. They sign in to open it, and the log shows when they did. They can mark your record reviewed, with a note, and the log keeps it. What the workaround leaves is the AO's to accept, from their own sign-in, as their own Accepted record on the same CVE, dated the day they accept it. Your Mitigated record stays as you wrote it. See the six fields the AO opens.
The record opens with that CVE's facts already filled in: KEV status, EPSS and its date, weakness class, fixed versions, each from its public source. Our server dates it. Sign in with email, Google or GitHub to keep it. The first 100 records are free.
SP 800-53 Rev. 5, Release 5.2.0, published 27 August 2025. All four controls below sit in the Low, Moderate and High baselines. Each leaves a number or a tolerance for you to define, which is why the assessor asks for your numbers before your evidence.
| Control | The text | What it leaves to you |
|---|---|---|
| RA-5d Vulnerability Monitoring and Scanning | "Remediate legitimate vulnerabilities [Assignment: organization-defined response times] in accordance with an organizational assessment of risk" | Your response time. A finding open past it is the one that gets sampled, and each one needs a written response. A fix still coming is a POA&M line. A risk you are leaving open is the AO's acceptance, in the assessment report. A finding that is not a legitimate vulnerability is your RA-5c analysis. |
| SI-2c Flaw Remediation | "Install security-relevant software and firmware updates within [Assignment: organization-defined time period] of the release of the updates" | Your patch window. |
| RA-7 Risk Response | "Respond to findings from security and privacy assessments, monitoring, and audits in accordance with organizational risk tolerance." | Which response you chose, and why it fits your tolerance. |
| CA-5a/b Plan of Action and Milestones | "Develop a plan of action and milestones for the system to document the planned remediation actions of the organization to correct weaknesses or deficiencies noted during the assessment of the controls and to reduce or eliminate known vulnerabilities in the system" · "Update existing plan of action and milestones [Assignment: organization-defined frequency] based on the findings from control assessments, independent audits or reviews, and continuous monitoring activities." | How often you update it. It holds planned remediation, not the decision to leave a finding open. |
The order is NIST's. The discussion under RA-7, which is NIST's guidance rather than the requirement itself, lists "accepting risk with appropriate justification or rationale" among your options. It says the response is determined "before generating a plan of action and milestones entry". Then it says when an entry exists: "if the risk response is to mitigate the risk, and the mitigation cannot be completed immediately, a plan of action and milestones entry is generated."
SP 800-37 Rev. 2, task R-3: "the planned mitigation actions are included in and tracked using the plan of action and milestones." It has a milestone and a line.
SP 800-37 Rev. 2, task R-3: accepted deficiencies "remain documented in the security and privacy assessment reports and are monitored for changes to the risk factors." It has no milestone and no line. SP 800-37's outcome for task A-6 is a POA&M "detailing remediation plans for unacceptable risks", and an accepted risk is one the AO judged acceptable. It still gets sampled.
The exception process, drawn from NIST's texts. SP 800-40 Rev. 4 names it outright: section 3.5.5 is "Exceptions to Maintenance Plans".
CSF 2.0 names the exception too. ID.RA-07: "Changes and exceptions are managed, assessed for risk impact, recorded, and tracked". ID.RA-06: "Risk responses are chosen, prioritized, planned, tracked, and communicated". The framework "does not prescribe how outcomes should be achieved", so for each exception, its record is how you show the outcome happened.
Under SP 800-53 the person testing is a control assessor, and SP 800-53A Rev. 5 lists what they examine for each control. The population comes first: your RA-5d response times and SI-2c time period, from your "risk assessment policy" and "system security plan", then every finding older than them, from the "vulnerability scanning results" and the "list of flaws and vulnerabilities potentially affecting the system". The sample is drawn from that set. Each item in it gets the questions below, and wherever the right-hand column quotes, it quotes 800-53A.
| The ask | What they mean | What they examine |
|---|---|---|
| "For this one, which response, and where is it written?" | The answer decides where they look. A fix in progress goes to CA-5. An acceptance goes to RA-7's objects. A finding you ruled out goes to the records RA-5 examines. | "plan of action and milestones" · "assessment reports; audit records/event logs" · "patch and vulnerability management records" |
| "Who accepted it?" | SP 800-37 Rev. 2, task R-4: "The explicit acceptance of risk is the responsibility of the authorizing official and cannot be delegated to other officials within the organization." Outside government, CA-6's discussion allows that "Nonfederal organizations may have similar processes to authorize systems and senior officials that assume the authorization role and associated responsibilities". | The acceptance, and the name on it |
| "Is it still true?" | CA-5b updates the plan at your defined frequency. Task M-3 lists "Mitigation actions or risk acceptance decisions" among its expected outputs, so monitoring can produce a new decision on an acceptance after it is signed. | The plan, and evidence that accepted risks were monitored |
| "Show me how it works." | They test the process as well as the paper. Share a record with your assessor by name. They sign in to open it, and the log of who opened it is itself evidence the sample was read. | "Mechanisms for developing, implementing, and maintaining plan of action and milestones" |
Under CSF 2.0, the person asking is not an assessor. The CSF names no assessor, and its outcomes "are not a checklist". The request comes from internal audit, from a customer's security questionnaire, or from a board measuring you against a CSF Profile. What they ask for matches NIST's Implementation Examples for ID.RA-07, a companion resource published with the framework:
"Implement and follow procedures for the formal documentation, review, testing, and approval of proposed changes and requested exceptions"
"Document the risks related to each requested exception and the plan for responding to those risks"
"Periodically review risks that were accepted based upon planned future actions or milestones"
The mitigations hold up. They are on the POA&M, with milestones. The sample goes wrong on everything else: the findings you accepted and the findings you ruled out. What turns up is usually one of these.
POA&M, row 214: "Risk accepted. See memo."
A memo signed by the AO: "Low exploit likelihood. Compensating controls in place. Accepted."
A ticket comment: "Not exposed. False positive. Closing."
The memo says exploit likelihood was low. Low on which day? On 19 October 2023, FIRST's EPSS score for Citrix Bleed was 0.00751. On 31 October it was 0.92267. A number without a date gets read at today's value, and today's value makes a reasonable call look negligent.
A document's date belongs to whoever edits it. A spreadsheet row updated at your CA-5b frequency overwrites the state it replaced. SP 800-37 asks the opposite for assessment results. When controls are reassessed, assessors "update the assessment reports with the findings from the reassessment, but do not change the original assessment results."
So before each assessment the ISSO rebuilds every call from tickets, email and chat. The rebuilt version is dated the week it was rebuilt, whatever day it describes. RA-7 is tested "in accordance with organizational risk tolerance", and nothing in that file shows what the risk was measured against.
The rows you already hold. Your assessment is weeks away and row 214 already exists. Record each acceptance today as its periodic review, the review ID.RA-07's Implementation Example expects. The record is dated today, the day of the review. Your rationale carries the memo's own date, the record freezes today's evidence, and the CVE page beside it carries the dated public history the index holds: the KEV listing and each EPSS move since. From that review on, the next one comes due by itself.
A decision record holds one call: what you decided, who decided it, when our server wrote it down, when it comes back for review, and the public evidence of that day, frozen with it. Each of its five verdicts lands on a NIST response.
| Verdict | NIST response | Where NIST files it | What the record supplies |
|---|---|---|---|
| Accepted the risk | Accept. SP 800-40 Rev. 4, section 2.1: "Accept the risk from vulnerable software as is" | The assessment reports, "monitored for changes to the risk factors". No POA&M line. | The rationale RA-7's guidance asks for, the named decider, that day's evidence, and a watch on it. |
| Patch by a date | Mitigate, where the mitigation "cannot be completed immediately" | A CA-5 POA&M entry | The dated decision the POA&M line cites. |
| Mitigated by a compensating control | Mitigate. CSF ID.RA-06 Implementation Example: criteria "for selecting compensating controls to mitigate risk" | Your control documentation | The control, named and dated, beside the evidence it answered. |
| Not affected | The RA-5c analysis: not a legitimate vulnerability in the RA-5d sense. CSF ID.RA-01: "identified, validated, and recorded" | "patch and vulnerability management records" | Your analysis, and the published scope it relied on. |
| Deferred | A risk accepted on the strength of planned future action | The assessment reports, like any acceptance, and the AO makes it. It is reviewed periodically, per ID.RA-07's Implementation Example. | A review-by date that comes due by itself. |
Worked example: CVE-2023-4966, Citrix Bleed, on three Moderate systems: a VPN gateway, a load-balancing-only ADC, and an isolated test enclave. CISA listed it on 18 October 2023. The next morning one team made three calls. The snapshot below uses only dated public observations, CISA's listing and FIRST's EPSS series, and it is what a record written that morning would have frozen.
| VPN gateway | Load balancer | Test enclave | |
|---|---|---|---|
| Verdict | Patch by 2023-10-20 | Not affected | Accepted the risk |
| NIST response | Mitigate. It cannot be completed today. | RA-5c: not a legitimate vulnerability on this system. | Accept. |
| Rationale | "Internet-facing and on KEV. The fixed build goes in at the emergency change window on 20 October, then we kill all active and persistent sessions." | "The CNA limits the flaw to appliances 'configured as a Gateway (VPN virtual server, ICA Proxy, CVPN, RDP Proxy) or AAA virtual server'. This one has neither. Configuration export is in the change ticket." | "No inbound route from any network. Sessions killed. Accepted as is until the review on 7 November, inside CISA's due date." |
| Decided by | The ISSO, by name | The ISSO, by name | The authorizing official, by name |
| Review by | 2023-10-20 | 2024-04-19 | 2023-11-07 |
| Where it lives | The POA&M line cites the record, with a milestone of 20 October. | The record is the RA-5c analysis. | The assessment report cites the record. There is no POA&M line. |
The assessment report cites the record. The citation is the record's link and its hash. Your assessor signs in by name to open it, recomputes the hash to see the frozen evidence is intact, and the log shows the day they read it.
Then the evidence moved. On 24 October the first public proof-of-concept repository appeared. On 26 October EPSS reached 0.17990 and crossed 0.10, the first of the thresholds the CVE page marks. That is the kind of "changes to the risk factors" SP 800-37 says an accepted deficiency is monitored for. That day a watch on the acceptance would have alerted the authorizing official, twelve days before its review date, and the AO's new call, Patch by 31 October, would be a new version in the same chain. The 19 October version would stay readable, still showing what the call stood on. By 31 October EPSS was 0.92267, more than a hundred times the 19 October value.
Every date above is on the record today. Open CVE-2023-4966 and its full EPSS history shows the 19 October observation at 0.00751. That page shows today's KEV entry, ransomware flag included. A record freezes the entry as it read on the day, and a later change to it is a move the watch reports.
A decision record is evidence. It is the artifact an assessor samples under RA-7, RA-5d and SI-2c, and the one an internal auditor samples under ID.RA-07. Everything the authorization rests on stays with you.
| Stays yours | Why |
|---|---|
| The POA&M | CA-5 is the system's plan, and it feeds the authorization package. A record is the evidence one line of it cites. |
| Your risk tolerance | One of CSF GV.RM-04's Implementation Examples reads "Specify criteria for accepting and avoiding cybersecurity risk for various classifications of data". The record applies your criteria. It does not set them. |
| Authority | The record names who decided. Your appointment documents show that person holds the authorizing official's role, which R-4 says cannot be delegated. |
| Where the record lives | Your authorization boundary decides it. Records run in vciy's cloud, or on your own hardware under the On-Prem plan, where nothing leaves your network. Pricing shows where each plan runs. |
| The authorization | vciy is not an ATO, an assessment report, or a CSF Profile. It is the page each of those points to. The risk decision and the ATO are the AO's. The record is evidence for both, and decides neither. |
If you own the evidence file across more than one framework, the compliance and audit page covers the rest of your day. Running under FedRAMP? Its Consolidated Rules for 2026 replace the POA&M with a list of Accepted Weaknesses, and the monthly POA&M with deviation requests is legacy, kept for reference during the transition. That has its own page. Other standards: the compliance hub.
An acceptance is not paid for once. CA-5b updates the plan at your defined frequency, and task M-3 responds to what monitoring finds. Each pass asks the same two questions of the same acceptances: what was this accepted on, and is it still true?
| Where the acceptance lives | What each pass costs | What it cannot show |
|---|---|---|
| The memo and the tickets | The ISSO's week before each assessment, rebuilding every call from tickets, email and chat. | Which risk factors the call was measured against, as they stood that day. |
| A risk-accepted status on the POA&M | A status cell someone updates at each CA-5b pass. | What the acceptance stood on. R-3 files that in the assessment report, and a status cell holds none of it. |
| A GRC register | A seat, and someone typing each row. | What CISA and FIRST said on the day. Its audit log records edits your own admins made on your own system. |
| Your scanner's accept-risk rule | A rule, a comment and an expiry date, set in the scanner. | What CISA and FIRST said on the day the rule was set. The rule's date and comment belong to whoever edits it next. |
| A decision record | Written once, on the day. Each pass reads it, and when KEV or EPSS moved, the watch has already alerted you. | Nothing it has to rebuild. The record never changes after it is written. Anyone you share it with can recompute the hash and see the frozen evidence is intact. |
Start on the Free tier with the acceptances you already hold. Free keeps 100 records, at $0. One record holds one call on one system, as the three Citrix records above show. Practitioner holds 500, at $124.50 a month. A backlog past that is a Custody backlog, which has no cap, at $1,000 a month. The API comes with every tier, and each call carries the CVE, the verdict, your rationale and the review-by date. Point it at your scanner's findings past RA-5d and record the backlog in one pass instead of one row at a time. Each record still takes its date from our server on the day it arrives, never from the import. Custody is for the authorizing official: a shared register the AO reviews, and a receipt of who reviewed it and when, which is evidence the review happened. Pricing shows what each tier holds.
The record opens with that CVE's facts already filled in: KEV status, EPSS and its date, weakness class, fixed versions, each from its public source. Our server dates it. Sign in with email, Google or GitHub to keep it. The first 100 records are free.