Introduction
Most organizations have a risk register. Far fewer have a document that answers the harder questions sitting right behind it: what are we actually doing about each risk, who is accountable, and by when?
That gap is where risk materializes. A risk register catalogs exposure. A risk treatment action plan (RTAP) turns that catalog into decisions with owners, deadlines, and measurable outcomes.
According to the 2025 NC State ERM Initiative and AICPA State of Risk Oversight report, 61% of executives report rising risk complexity while only 32% rate their risk oversight as mature or robust. When complexity outpaces oversight maturity, undocumented treatment decisions stop being a process gap and start being a board liability.
This guide is written for boards, executives, and risk leaders in regulated industries who need to convert risk assessments into decisions that can be executed and inspected. It covers:
- The four treatment strategies and when to apply each
- A step-by-step process for building an RTAP
- Required plan elements and ownership structure
- Execution failures that make well-documented plans fall apart under pressure
TL;DR
- An RTAP records what your organization will do about each risk above its appetite threshold — strategy, actions, owner, timeline, and residual risk
- It sits between risk assessment and monitoring — the execution layer that connects scoring to action
- The four strategies are: avoid, reduce, transfer, and accept — most organizations use a mix
- An RTAP without named owners, target dates, and residual risk ratings is a list, not a plan
- Boards must approve the plan, not just receive it — that distinction separates governance from compliance theater
What Is a Risk Treatment Action Plan?
A risk treatment action plan is a formal document that records, for each identified risk above an appetite threshold:
- The treatment strategy chosen (avoid, reduce, transfer, or accept)
- The specific actions required to implement that strategy
- The individual accountable for those actions
- The target completion date
- The residual risk expected after treatment is applied
The residual risk rating is the verification step. Without it, there is no basis for confirming the treatment worked — or for telling a board or auditor that it did.
How It Differs from Adjacent Documents
The RTAP is commonly confused with two other artifacts:
| Document | Purpose | Scope |
|---|---|---|
| Risk register | Catalogs and scores identified risks | Ongoing repository |
| Risk management plan | Governs the overall risk process | Framework-level |
| Risk treatment action plan | Assigns decisions, owners, and timelines to prioritized risks | Execution layer |
| Risk response plan | Defines what to do after a risk event triggers | Reactive, project-focused |
The line between an RTAP and a risk response plan is where governance separates from incident management. A response plan activates after something goes wrong. An RTAP is prospective — it defines what the organization commits to doing before harm materializes, with named owners and signed-off deadlines.
For regulated organizations, the RTAP is audit evidence — not optional documentation. Key requirements include:
- ISO/IEC 27001:2022 clause 6.1.3: Documented treatment decisions, risk owner approval, and residual risk acceptance
- NIST CSF 2.0: Equivalent requirements framed under the "Respond" function's risk response activities
- SEC cybersecurity rules: Board-level disclosure obligations that require demonstrable oversight of material risks
The Four Core Risk Treatment Strategies
Every risk in the RTAP must be assigned one of four strategies. Choosing a strategy is a business decision, not a security decision — it should reflect the organization's defined risk appetite and the cost-benefit tradeoff for each risk.
Avoid
The organization eliminates the activity, process, or system that creates the risk entirely.
A practical example: a retailer chooses not to store payment card data internally, routing all transactions through a third-party payment processor. That decision removes PCI DSS scope rather than attempting to secure it. Avoidance is appropriate when the risk-reward tradeoff is clearly negative and the activity is not core to the business.
Reduce (Mitigate)
The organization implements controls to lower the likelihood the risk occurs, the impact if it does, or both.
Two types of controls serve different purposes:
- Preventive controls lower likelihood — for example, deploying multi-factor authentication to reduce credential compromise risk
- Detective and corrective controls lower impact — incident response plans, backup validation, and breach containment procedures fall here
Most cybersecurity investment goes into reduction. This makes sense: if the activity is core to operations, avoidance isn't on the table.
Transfer
The organization shifts the financial or operational consequences of a risk to a third party through insurance, outsourcing, or contractual indemnification.
Purchasing cyber liability insurance to cover breach notification costs is the most common example. One critical boundary: transfer does not eliminate accountability. The organization still owns the risk outcome; it has only shifted financial exposure. Boards and management retain governance responsibility regardless of what an insurance policy covers.
Accept
The organization makes a deliberate, documented decision to retain a risk — because it falls within risk appetite, treatment costs exceed expected loss, or prior treatment has already reduced it to an acceptable residual level.
Acceptance is governance when it is documented with explicit sign-off at the appropriate authority level. It is neglect when it happens by default or inaction.
The practical test: if an exception doesn't expire with a named owner and compensating controls, it isn't an exception — it's the real operating model.
How to Build a Risk Treatment Action Plan: Step-by-Step
The RTAP is built on top of a completed risk assessment. Organizations that skip likelihood scoring, impact scoring, and risk rating cannot build a credible plan — they have no basis for prioritization.
Step 1: Define Your Risk Appetite
Risk appetite is the threshold at which a treatment decision becomes required. Without it, every risk looks equally urgent or equally ignorable.
Appetite should be expressed in measurable terms, not abstract language. Tyson Martin's advisory work helps boards define specific thresholds such as:
- Maximum hours of customer portal downtime before escalation to the board
- Maximum confirmed fraud loss per quarter before treatment is required
- Data sensitivity tiers that trigger different review requirements
His three-tier decision rights model clarifies which risks management can accept without escalation, which require executive approval, and which must reach the board or audit committee. This removes ambiguity when pressure is on.
Step 2: Pull Prioritized Risks from Your Risk Register
The RTAP does not address every catalogued risk — only those that exceed the appetite threshold from Step 1. Pull these risks with their inherent risk ratings (likelihood × impact before controls are applied).
Risk categories most relevant to regulated industries:
- Cybersecurity and data protection
- Compliance and regulatory exposure
- Operational continuity
- Third-party and vendor risk
Step 3: Select a Treatment Strategy for Each Risk
For each prioritized risk, select one of the four strategies based on the risk's nature, available controls, and cost-benefit tradeoff. Document rationale alongside the strategy label — not just "mitigate," but why mitigation was chosen over transfer or acceptance. Auditors and boards need the reasoning, not just the decision.
Step 4: Define Specific Actions, Owners, and Deadlines
Most RTAPs fail here. A treatment strategy without specific actions is a label, not a plan.
Good action definition follows a clear pattern: action verb + measurable outcome + named individual owner. Not "the security team will implement MFA" — but "Maria Chen, Director of IT, will deploy MFA across all administrative accounts by March 31."
Ownership must sit with a person, not a department. When a risk is owned by a team, no one is accountable. Target dates must be realistic and tracked, not symbolic.
Step 5: Assess Residual Risk
Residual risk is what remains after treatment actions are implemented. Rate it using the same likelihood/impact scale as inherent risk so the comparison is direct.
If residual risk still exceeds the appetite threshold, the plan is incomplete. It requires one of two responses:
- Additional treatment — identify and assign new or strengthened controls
- Explicit board-level acceptance — documented with a date and a review trigger
Step 6: Document, Review, and Get Leadership Sign-Off
The RTAP must be formally approved at the appropriate authority level. Risks above the escalation threshold require board or audit committee approval, not just CISO sign-off.
A board-ready RTAP summary should answer five questions per risk:
- What is the risk? (plain English, not technical jargon)
- What strategy was chosen and why?
- Who owns the treatment actions?
- What is the target completion date?
- What is the residual risk status?
Tyson Martin's board reporting work builds this into a stable dashboard format that tracks trend — whether residual risk is improving over time — rather than counting activity.
Review cadence should be quarterly at minimum, with out-of-cycle reviews triggered by material events: new system deployments, M&A activity, regulatory changes, or incidents.
Key Elements Every Risk Treatment Action Plan Must Include
The fields below represent the minimum required for an RTAP to be both operationally useful and audit-ready under ISO 27001, NIST CSF, and SOC 2.
Core identification fields:
- Risk ID — unique identifier that enables traceability across the register and links back to the original assessment
- Risk description — plain-English statement of the risk, written for a business audience, not a technical one
- Inherent risk rating — likelihood and impact before any controls are applied, establishing the baseline for treatment decisions
Treatment fields:
- Treatment strategy — avoid, reduce, transfer, or accept
- Specific mitigation actions — what will be done, written in actionable terms with clear scope
- Applicable controls — technical, administrative, or physical controls being implemented, linked to framework requirements
Accountability fields:
- Named owner — the individual accountable for execution, not a department or job title
- Target completion date — realistic, tracked, and tied to review cycles rather than arbitrary deadlines
Outcome fields:
- Residual risk rating — likelihood and impact after treatment, demonstrating what the control investment actually achieved
- Status — open, in progress, complete, or accepted with documented sign-off
Store the RTAP centrally — not in a personal spreadsheet — versioned and linked to the risk register. That creates an auditable trail from identified risk to treatment decision to outcome. When regulators or auditors look closely, that trail is what defensible governance actually looks like.
Common Mistakes That Undermine Risk Treatment Action Plans
Ownership Assigned to Teams, Not People
Assigning a risk to "the security team," "IT," or "the CISO" creates the appearance of accountability without the substance. When everyone owns a risk, no one does.
Every treatment action needs one named individual who is answerable to leadership if execution stalls. Accountability and responsibility are different things — the RTAP must make accountability visible, not just assigned.
Acceptance Without Governance
Writing "accepted" as a treatment strategy without formal sign-off at the appropriate authority level is documentation, not governance. Acceptance recorded only in the security team's spreadsheet has no governance weight.
For regulated industries, each accepted high-rated risk needs to meet a minimum standard of governance. That means documenting:
- A named approver with the authority level to accept that risk
- The date of acceptance and a defined review trigger
- Compensating controls, where applicable
- Evidence of periodic review, as HHS OCR guidance expects for HIPAA-covered entities
Regulators increasingly look for evidence of who accepted which risk and when — not just whether a risk register exists.
The Static Plan Problem
An RTAP built once and never reviewed creates the appearance of control while the actual risk landscape has moved on.
A plan showing all risks as "complete" with no updates in 18 months is a red flag, not a clean bill of health. The plan should have a defined review cadence tied to material events: system changes, vendor incidents, M&A activity, regulatory shifts, or actual incidents. Residual risk ratings must be updated as controls are implemented or conditions change — if they aren't, the plan becomes a historical artifact that active regulators and auditors will treat as one.
Frequently Asked Questions
What is a risk treatment action plan?
A risk treatment action plan is the document that records what an organization will do about each risk exceeding its appetite threshold. It specifies the treatment strategy, specific actions, a named owner, a deadline, and the expected residual risk after treatment is applied.
What are the steps of risk treatment?
Risk treatment covers five steps within the broader risk management lifecycle: define risk appetite, identify and prioritize risks above that threshold, select a treatment strategy, implement controls with named owners, and assess residual risk. Documentation is required at every step.
What are the 5 steps of the risk management process?
The full risk management lifecycle includes five stages:
- Identify risks
- Analyze and assess risks
- Select and implement treatment
- Monitor and review
- Communicate and report
The risk treatment action plan is produced in step three and tracked through step four.
What is an example of risk treatment?
A company identifies phishing as a high-likelihood, high-impact risk. The treatment decision is to reduce it by deploying email filtering and mandatory phishing awareness training, with a named IT leader as owner, a 90-day completion target, and a residual risk rating that drops from high to medium.
What is the difference between a risk treatment plan and a risk response plan?
A risk response plan (common in project management) is reactive: it defines what to do after a risk event triggers. A risk treatment action plan is prospective and governance-driven — it defines what the organization will do to prevent or limit harm before a risk materializes. The response plan is a temporary project artifact; the treatment plan is a standing governance document with ongoing oversight obligations.
Who is responsible for a risk treatment action plan?
Overall ownership sits with the CISO, Chief Risk Officer, or equivalent executive, while each individual risk requires a named business or technical owner accountable for execution. The board or audit committee approves high-risk acceptance decisions and receives progress reporting on a defined cadence.
