Risk Acceptance: When to Accept a Risk, Who Signs Off and What to Document

Short answer: Risk acceptance is a documented decision to keep a known risk without further treatment because it falls within your acceptance criteria or because treating it costs more than the exposure. A well-documented acceptance names an accountable owner, records the rationale and any compensating controls, and should carry an expiry date that forces a fresh review.

Related guides:

• ISO 27001 risk treatment plan
• Inherent vs residual risk, with a worked example
• How to use a risk assessment matrix

Key takeaways

• Risk acceptance is one of four treatment options, alongside mitigate, transfer and avoid. It is a decision, not the absence of one.
• ISO 27001:2022 clause 6.1.2 requires you to define risk acceptance criteria before you assess risk, and clause 6.1.3 requires risk owners to approve the treatment plan and accept the residual risks.
• SOC 2 auditors review accepted risks under the CC3 criteria. They want a consistent, approved process, not zero risk.
• Every acceptance should have an owner with real authority, a written rationale, compensating controls where relevant and an expiry date.
• Accepting a risk is not the same as accepting non-compliance with a legal requirement. For HIPAA addressable specifications, the rule asks you to document your reasoning and, where reasonable and appropriate, implement an equivalent alternative.

What is risk acceptance in risk management?

Risk acceptance is the informed choice to retain a risk at its current level instead of reducing, transferring or eliminating it.

Most risk frameworks describe four treatment options. The table below shows how acceptance compares with the others.

Treatment option	What it means	Typical example
Mitigate (modify)	Add or improve controls to reduce likelihood or impact	Enforce MFA on all admin accounts
Transfer (share)	Shift part of the financial impact to a third party	Buy cyber insurance or contract a managed service with liability terms
Avoid	Stop the activity that creates the risk	Retire a legacy feature that stores unneeded patient data
Accept (retain)	Keep the risk and monitor it	Accept a low risk of a brief outage on an internal wiki

Acceptance usually applies to residual risk, the risk that remains after your existing or planned controls. Because no control reduces risk to zero, some acceptance always happens. The question is whether it is explicit and recorded.

When is accepting a risk the right call?

Accepting a risk is appropriate when the residual risk sits within your defined acceptance criteria, or when the cost of further treatment clearly outweighs the expected harm.

Acceptance is often reasonable when:

1. The risk scores low on your risk matrix and falls inside the threshold your leadership approved.
2. Treatment is disproportionate, such as full redundancy for a non-critical internal tool.
3. A fix is pending, so you accept the risk for a fixed period with compensating controls.
4. The risk is inherent to the business model, such as a SaaS product's dependency on its hosting provider.

Acceptance is usually not appropriate for high risks with no compensating controls, for safeguards a law or contract requires, or when the approver lacks authority over the asset or budget.

Risk appetite, risk tolerance and acceptance criteria: what is the difference?

Risk appetite is the broad amount of risk an organization is willing to pursue or retain, risk tolerance is the acceptable variation around specific objectives, and risk acceptance criteria are the concrete rules that decide whether a single risk can be accepted.

Concept	Level	Who sets it	Example
Risk appetite	Strategic, organization-wide	Board or executive team	"We have a low appetite for risks to patient data confidentiality."
Risk tolerance	Per objective or metric	Executives and functional leaders	"Customer-facing availability must stay at or above our committed SLA."
Risk acceptance criteria	Per risk, operational	Risk or security function, approved by management	Illustrative example: "Risks scoring 6 or below on a 5x5 matrix may be accepted by the risk owner. Scores of 7–12 need CISO sign-off. Scores above 12 need executive sign-off and a treatment plan."

Acceptance criteria make appetite consistent to apply. For more on the first two concepts, see our article on risk appetite vs risk tolerance.

What does ISO 27001 require for risk acceptance?

ISO 27001:2022 requires you to define risk acceptance criteria in advance (clause 6.1.2) and to have risk owners formally accept residual risks when they approve the treatment plan (clause 6.1.3).

The relevant requirements in plain terms:

• Clause 6.1.2 a) asks you to establish and maintain information security risk criteria, which include the risk acceptance criteria and the criteria for performing risk assessments.
• Clause 6.1.2 c), in its second point, asks you to identify risk owners for the risks you find.
• Clause 6.1.3 f) asks you to obtain risk owners' approval of the information security risk treatment plan and their acceptance of the residual information security risks.
• Clause 8.3 asks you to implement the treatment plan and retain documented information on the results.

Certification auditors typically check that your criteria existed before the assessment, that each accepted risk meets them, and that the named risk owner recorded the acceptance. Keep justifications consistent with your Statement of Applicability where you exclude an Annex A control. Our ISO 27001 risk treatment plan guide covers how the plan and the acceptance records fit together.

How do SOC 2 auditors view accepted risks?

SOC 2 auditors treat accepted risks as evidence of a working risk assessment process under the CC3 criteria, provided the decisions follow your documented method and are approved by the right people.

The Common Criteria in the CC3 series cover risk assessment. CC3.1 addresses specifying objectives clearly enough to identify risks, CC3.2 addresses identifying and analyzing risks and determining how they should be managed, CC3.3 addresses fraud risk and CC3.4 addresses changes that could affect internal control. Accepting a risk is one legitimate way of "determining how risks should be managed."

What auditors commonly ask to see:

• Your risk methodology, including how acceptance decisions are made.
• The risk register for the period, with treatment decisions and owners.
• Approval evidence, such as a signed form, ticket approval or meeting minutes.
• Evidence that accepted risks were reviewed again at the next risk assessment.

Expect questions when an accepted risk contradicts a control in your system description, such as an MFA exception for a service account.

What should a risk acceptance form contain?

A risk acceptance form should capture enough detail that someone outside the decision can understand what was accepted, why, by whom and until when.

Use this field list as a starting point:

Field	What to record
Risk ID	Unique reference that links to the risk register entry
Risk title and description	The threat, the vulnerability and the asset or process affected
Related requirement	Framework references, such as an ISO 27001 Annex A control, SOC 2 criterion or HIPAA section
Inherent risk score	Likelihood, impact and overall score before controls
Existing controls	Controls already in place that reduce the risk
Compensating controls	Additional measures applied because the preferred control is not implemented
Residual risk score	Likelihood, impact and overall score after controls
Acceptance criteria met	Which threshold in your criteria permits this acceptance
Rationale	Why acceptance is chosen over mitigate, transfer or avoid, including cost or feasibility
Risk owner	Person accountable for the risk and its monitoring
Approver	Person with the authority your criteria require for this risk level
Approval date	When the acceptance was signed
Expiry or review date	When the acceptance lapses and must be renewed or closed
Planned remediation	Target fix and date, if acceptance is temporary
Review history	Each renewal, with date, reviewer and outcome

Setting expiry and review cadence. Tie the expiry to the risk level. One illustrative pattern, not a requirement of ISO 27001 or SOC 2, is up to 12 months for low risks and 3–6 months for medium or high risks, plus early review when the system changes, a related incident occurs or a compensating control fails.

Who should sign off? The approver should own the budget or the asset that would pay for treatment. Many teams use an escalation ladder: team lead for low risks, security lead for medium, an executive for high.

HealthTech example: what you can and cannot accept

In HealthTech, you can accept many ordinary operational risks, but you cannot use risk acceptance to skip a HIPAA requirement without the documentation and alternatives the Security Rule expects.

A risk you can reasonably accept. A telehealth startup finds that its internal marketing analytics dashboard has no SSO and relies on strong unique passwords. It holds no PHI, four people use it and it is due for replacement next quarter. The security lead accepts the low residual risk for 90 days, with an access review as a compensating control and a trigger to re-review if PHI is ever connected.

A risk you should not simply accept. The same company finds that a backup storage location for ePHI is not encrypted at rest. Under the HIPAA Security Rule, encryption at rest is an addressable implementation specification at 45 CFR 164.312(a)(2)(iv). Addressable does not mean optional. Under 45 CFR 164.306(d)(3), the entity must assess whether the specification is reasonable and appropriate. If it is, implement it. If not, document why and implement an equivalent alternative measure if that is reasonable and appropriate. A one-line "risk accepted" entry without that analysis is unlikely to satisfy a regulator.

Required specifications, such as the risk analysis under 164.308(a)(1)(ii)(A), cannot be accepted away at all, and required documentation must be kept for six years under 164.316(b)(2).

Note that HHS published a proposed update to the HIPAA Security Rule in early 2025 that would, among other changes, remove most of the distinction between required and addressable specifications. When this article was published it was still a proposed rule, so check its status before relying on either version. Our HIPAA Security Rule update post tracks the proposal. Our HIPAA risk assessment guide covers the analysis side in more depth.

Which risk acceptance red flags should you avoid?

The biggest red flags are acceptances that never expire, acceptances of legal non-compliance and acceptances signed by people without authority.

Watch for these patterns in your register:

• Permanent acceptance. No expiry date, or an expiry that has been renewed automatically for years without new analysis.
• Accepting regulatory non-compliance. You can accept business risk. You cannot accept your way out of a legal obligation, such as a HIPAA required specification or a contractual security commitment.
• Wrong approver. The person who signed does not own the asset or budget, or sits below the authority level your criteria require.
• No compensating controls on high risks. A high residual risk accepted with nothing else in place usually means the treatment decision was skipped.
• Score drift. The residual score was lowered to fit under the threshold, with no change in controls to justify it.

If you find any of these, reopen and reassess the risk.

How SecureSlate helps

SecureSlate helps you keep the controls around your risk decisions organized. Its control library, mapped across SOC 2, ISO 27001, HIPAA, GDPR, PCI DSS and more, gives you one place to see the controls an accepted risk relates to. Policy management helps you publish and track approval of your risk methodology, including your acceptance criteria. Cloud and identity integrations help you collect evidence for related controls, and vendor risk management helps you track third-party risks. Recording individual acceptances, expiry dates and approvals follows your own risk register process.

Start your free SecureSlate trial

FAQ

Is risk acceptance the same as ignoring a risk?

No. Ignoring a risk means no decision was made. Risk acceptance is a documented decision by an accountable owner, based on defined criteria, with a review date.

Who should approve a risk acceptance?

The risk owner, or a person with authority matching the risk level defined in your acceptance criteria. Higher risks should go to someone who controls the budget or asset involved.

How long should a risk acceptance last?

Neither ISO 27001 nor SOC 2 sets a period. Set your own period in your risk methodology. One illustrative approach is to cap low risk acceptances at 12 months, use shorter periods for higher risks and review them at each annual risk assessment.

Do ISO 27001 risk acceptance criteria need to be numeric?

Not necessarily. The standard asks for consistent, valid and comparable results. Numeric matrix thresholds are common because they are easy to audit, but clearly defined qualitative criteria can also work.

Disclaimer (legal note)

This article is for general information only and is not legal, regulatory or professional advice. Requirements vary by framework, industry and jurisdiction. Consult qualified advisors for your specific obligations.