How to Fill Out and Submit a Risk Acceptance Form

To fill out a risk acceptance form, work through seven standard sections in order: system information, a specific risk description, the justification for not remediating, the compensating controls in place, the residual risk score, a plan of action with milestones, and signature blocks with an expiration or review date. Each field needs concrete detail rather than summary language, because the finished document has to satisfy auditors, insurers, and anyone reviewing the decision after an incident.

The guidance below walks through each section, the scoring math behind the numbers you’ll enter, how to route the form for approval, and where to store it once it’s signed.

When a Risk Acceptance Form Is Warranted

Not every identified risk needs formal acceptance. The form is triggered when someone proposes skipping or deferring a recommended fix and leadership agrees. Common triggers include a cost-benefit mismatch (a $50,000 remediation against a $5,000 potential loss), a vendor with no patch available, legacy systems that cannot support a required control, and time-sensitive deployments where a full fix must wait for a later release.

NIST SP 800-39 lists acceptance as one of four standard risk responses alongside avoidance, mitigation, and transfer. It states that organizations “can accept risk deemed to be low, moderate, or high depending on particular situations or conditions,” but that “a decision to accept risk must be consistent with the stated organizational tolerance for risk.”¹ In plain terms: the acceptance has to fit inside the boundaries your board or executive team has already approved. If it doesn’t, the form is the wrong instrument and the decision needs to go higher.

The Sections You’ll Complete

Templates vary by industry, but the DHS Information System Waiver and Risk Acceptance Request Form illustrates the core structure most organizations follow.² A well-designed form contains:

System information: name, identifier, date, and the requesting unit.
Risk description: the vulnerability, the control it violates, and any audit or scan reference.
Justification: why remediation isn’t feasible.
Compensating controls: alternative measures reducing the residual risk.
Plan of action and milestones: a remediation timeline if the acceptance is temporary.
Approvals: signature blocks for requestor, system owner, information security officer, authorizing official, and any additional executives.
Expiration date or review cycle.

If your organization doesn’t already have a template, adapt these sections. Auditors look for the same fields regardless of format.

Scoring the Risk Before You Write It Down

Likelihood and Impact

NIST SP 800-30 provides the most widely used scale. It assigns both likelihood and impact a qualitative label — very low, low, moderate, high, or very high — each mapped to a semi-quantitative score range. Impact ratings run from “negligible adverse effect” at the low end to “multiple severe or catastrophic adverse effects” at the top.³ Combining the two scores on the publication’s matrix produces an overall risk level. Using this framework rather than an ad hoc judgment gives reviewers an objective reference point.

ISO 31000 is the other common standard. It offers principles and a process framework rather than a specific scoring matrix, so organizations following ISO 31000 still need to define their own scales. Either works. What matters is picking one and applying it consistently, so the risk level on this form is comparable to every other risk in the register.

Residual Risk, Not Inherent Risk

The score you enter on the form is the residual risk: what remains after compensating controls are factored in. The formula is inherent risk minus the effect of controls equals residual risk. Score each factor by likelihood and impact, multiply for an inherent score, then reduce based on existing controls.

An unpatched server might have an inherent score of 20 (likelihood 4 × impact 5). Segmenting it behind a firewall with strict access rules, deploying intrusion detection, and monitoring all traffic drops the effective likelihood to 2. The residual score becomes 10 (2 × 5). That residual figure goes on the form, with a short explanation of how you got there. Reviewers need to see both numbers and the logic connecting them.

Filling In Each Section

Header and System Information

Put the date and organizational unit at the top. If your organization assigns tracking numbers centrally — the DHS form, for instance, has its number added by the compliance team after submission rather than by the requestor — leave that field blank with a note that it will be assigned on receipt.² Include the system name, any internal asset identifier, and a brief description of the system’s purpose and architecture. Attach a network diagram if you have one; it saves reviewers from asking.

Risk Description

Write this section for someone who has never seen the system. Identify the specific vulnerability or control gap, reference the policy it violates by number where possible, and describe the systems, data, or people affected. If the risk came out of an audit finding or a vulnerability scan, include that finding number so the form links back to the original discovery. Vague descriptions like “server has a security issue” will slow every approval in the chain.

Justification

This is where the cost-benefit analysis lives. State the estimated cost of full remediation and compare it to the estimated financial impact of the risk materializing. Include downtime estimates if a fix would take critical systems offline. Be specific. “Upgrading the database engine requires 72 hours of downtime during peak billing season and costs approximately $85,000 in licensing and labor” is far more useful to a reviewer than “the fix is too expensive.”

If the barrier isn’t cost but feasibility — no vendor patch, hardware that cannot support the required encryption standard — say so and cite the vendor’s documentation or support ticket.

Compensating Controls

Compensating controls are the alternative measures you put in place when the standard fix isn’t feasible. They should achieve the same risk-reduction goal or bring the residual risk to an acceptable level. Auditors expect thorough documentation here. A form that says “we accepted the risk” without describing any compensating controls essentially admits the organization left a gap unaddressed.

Typical controls include restricting network access through firewall rules and VPN-only connections, deploying enhanced monitoring and anomaly detection, applying virtual patches at the perimeter while waiting for a vendor fix, and locking down physical access to the affected hardware. For each control, explain what it does and how it reduces likelihood or impact. This section feeds directly into the residual score.

Plan of Action and Milestones

Most acceptances are temporary, so include a remediation timeline. List each milestone, assign a responsible party, and set a completion date. If this form is a renewal of a previous acceptance, include the original scheduled completion date so reviewers can see whether remediation has slipped.

Expiration or Review Date

Set one, even if the acceptance is expected to run long. A form with no sunset can sit in a register unnoticed while the threat landscape shifts underneath it.

Routing the Form for Signature

A completed form triggers a routing chain. The DHS model runs requests through the system owner, information security officer, component chief information security officer, and finally the authorizing official who decides whether to accept the risk. Systems designated as high-value assets or mission-essential need additional approval from the DHS CISO, and systems designated as CFO systems require the component CFO’s signature.²

Your organization’s chain will look different, but the principle is the same: the higher the risk, the higher the approval authority. A low-level vulnerability on a non-critical system may only need a department head. A high-impact risk on a system that handles financial data or personal information will almost certainly need a CIO, CISO, or CFO. Each approver records a recommendation (approve, disapprove, or approve with conditions) along with signature and date.

Electronic signatures are valid for these internal documents. Under the federal ESIGN Act, a signature or record “may not be denied legal effect, validity, or enforceability solely because it is in electronic form.”⁴ Most GRC platforms and document management systems support electronic approval workflows that satisfy this.

After the Signatures: Storage and Review

Once all signatures are collected, save the form in a non-editable format like PDF and upload it to a centralized risk register. The risk register is a master log tracking every identified risk with its description, owner, status, and response plan. Auditors review this register to verify that accepted risks are documented and monitored. If your accepted risk isn’t in the register, it effectively doesn’t exist from a compliance standpoint.

Organizations using GRC software get automated tracking on upload: the tool flags upcoming review dates, notifies risk owners when an acceptance is about to expire, and keeps an audit trail of every change. Smaller organizations without GRC tools should at minimum store the PDF in a shared compliance folder and set calendar reminders for review dates. Emailing the form to a central compliance mailbox works as a backup but is harder to audit.

Retention depends on your regulatory environment. The SEC requires registered accounting firms to keep audit workpapers for at least seven years under rules implementing Section 103 of Sarbanes-Oxley.⁵ The underlying federal statute at 18 U.S.C. § 1520 sets a five-year floor for audit workpapers.⁶ Risk acceptance forms aren’t audit workpapers in the strict sense, but organizations subject to SOX audits often keep them for the same seven-year period because auditors may reference them when evaluating internal controls. If your industry has its own retention mandates (HIPAA, PCI DSS, state privacy laws), follow the longest applicable period.

Acceptance should never be permanent. The OCC’s Corporate Risk Management Policy, filed with the CFTC, requires review of risk appetites and tolerances at least every twelve months to align with changes in the business environment.⁷ Most organizations follow an annual cycle. At each review, the risk owner reassesses whether the threat level has changed, whether remediation costs have dropped, and whether the compensating controls still work. If conditions have shifted, revoke the acceptance and move to remediation.

One Cross-Check Before You Submit

Compare the accepted vulnerability against the representations in your active cyber insurance policies. If you certified on an application that a control was in place across all systems and you’re now accepting an exception, the discrepancy can be treated as a misrepresentation and used to deny a future claim. If there’s a conflict, notify your broker before the form is signed.

Common Mistakes That Get Forms Rejected

Vague risk descriptions. Name the CVE or finding number, the affected component, and the data at risk.
Missing compensating controls. Accepting a risk with no alternative measures reads to an auditor as a control deficiency, not a risk acceptance.
No expiration or review date. Set one even if the acceptance is expected to be long-term.
Wrong approval authority. A department manager signing off on an enterprise-wide financial risk won’t satisfy an auditor. Match approval level to risk level.
Inconsistency with insurance representations. Accepting a gap your application says doesn’t exist creates grounds for claim denial.
No link to the risk register. If the form isn’t uploaded and the register entry isn’t updated at the same time, the acceptance is invisible to governance reporting.

Small data-entry errors — a wrong system ID, a missing date, an unsigned approval block — can also cause problems if the risk eventually produces a loss. Treat the form with the care you’d give a contract, because in a dispute, it functions as one.

1
National Institute of Standards and Technology. NIST SP 800-39 – Managing Information Security Risk
2
U.S. Department of Homeland Security. DHS 4300A ITSSP Attachment B – Waiver and Risk Acceptance Request Form
3
National Institute of Standards and Technology. NIST SP 800-30 Rev. 1 – Guide for Conducting Risk Assessments
4
Office of the Law Revision Counsel. United States Code Title 15 – Section 7001
5
U.S. Securities and Exchange Commission. Retention of Records Relevant to Audits and Reviews
6
Office of the Law Revision Counsel. United States Code Title 18 – Section 1520
7
Commodity Futures Trading Commission. Corporate Risk Management Policy