SOC 2 Risk Treatment and Mitigation Planning Process

Learn how to perform SOC 2 Risk Treatment and Mitigation Planning under CC3.3, including documentation, tools, and audit-ready evidence.

SOC 2 Processes
SOC 2 Risk Treatment and Mitigation Planning Process

Overview

Risk Treatment and Mitigation Planning is the process of deciding how identified risks will be addressed through remediation, acceptance, transfer, or avoidance and documenting actionable mitigation plans. It ensures that SOC 2 CC3.3 requirements are met by assigning ownership, timelines, and tracking progress on risk responses.

Step-by-Step Process

  1. Review approved risk assessment results

    The Security Lead reviews the most recent approved risk assessment to identify risks that require treatment decisions. This includes confirming risk ratings, affected systems, and business impact. The output is a confirmed list of risks requiring mitigation planning.

    Role: Security Lead

  2. Determine risk treatment approach

    For each identified risk, the Security Lead determines whether the risk will be mitigated, accepted, transferred, or avoided based on organizational risk tolerance. Decisions should align with documented risk appetite. The output is a defined treatment decision per risk.

    Role: Security Lead

  3. Define mitigation actions

    For risks marked for mitigation, the Security Lead defines specific, measurable remediation actions such as control implementation or process changes. Actions must include a clear description of what will be done. The output is a documented list of mitigation actions per risk.

    Role: Security Lead

  4. Assign risk owners and due dates

    Each mitigation action is assigned to a responsible owner with a realistic due date. Ownership should align with operational control of the affected system or process. The output is an accountable mitigation plan with named owners and timelines.

    Role: Security Lead

  5. Document risk treatment plan

    The Security Lead documents treatment decisions, mitigation actions, owners, and deadlines in the system of record. Documentation must be complete and internally consistent. The output is a finalized risk treatment plan.

    Role: Security Lead

  6. Track mitigation progress

    Mitigation actions are monitored at least quarterly to confirm progress and identify delays or blockers. Status updates are recorded with evidence where applicable. The output is an up-to-date mitigation status for each risk.

    Role: Security Lead

  7. Review and update treatment decisions

    On a quarterly basis, the Security Lead reviews open risks and updates treatment plans based on changes in risk level or business context. Any changes are re-documented and approved as needed. The output is a current and accurate risk treatment record.

    Role: Security Lead

What You Need Before Starting

  • Approved risk assessment report for the current quarter
  • Documented organizational risk appetite or risk tolerance statement
  • Access to risk management tool (Drata, Jira, or spreadsheet)
  • List of system and process owners

Evidence Your Auditor Expects

  • Risk treatment plan showing treatment decisions, owners, and due dates, dated within the audit period
  • Screenshot or export from tool showing mitigation status with last updated timestamps
  • Quarterly risk review meeting notes or approval record with date
  • Completed mitigation task records with completion dates

How This Looks In Your Tools

Drata

Navigate to the Drata dashboard and select Risk Management from the left-hand menu. Open the applicable risk assessment and click into an individual risk to view details.

Under the Risk Treatment or Response section, select the treatment option (Mitigate, Accept, Transfer, Avoid), then add mitigation actions, assign an owner, and set a due date. Save changes and ensure the risk status updates.

Use the Evidence or Activity Log tab to upload supporting documents and confirm timestamps. Review the Risk Overview page quarterly to verify mitigation progress and export the risk register for audit evidence.

Jira

Create or use an existing Jira project dedicated to Risk Management. For each risk, create a Jira issue using a custom Risk or Task issue type and include risk ID, description, and rating in the issue fields.

Set the issue status to reflect the treatment decision (e.g., Mitigation Planned, Accepted) and create sub-tasks for each mitigation action. Assign owners and due dates using the Assignee and Due Date fields.

Track progress by updating issue statuses and adding comments with evidence attachments. Use Jira filters or dashboards to show open mitigation items during quarterly reviews.

Spreadsheet

Open the risk register spreadsheet and ensure columns exist for risk ID, description, risk rating, treatment decision, mitigation actions, owner, due date, and status. Enter treatment decisions and mitigation details for each applicable risk.

Assign owners and due dates directly in the spreadsheet and use status fields such as Open, In Progress, or Completed. Update the spreadsheet during quarterly reviews and record the last updated date.

Save the file with a date-stamped filename and retain version history or change logs to demonstrate ongoing tracking for audit purposes.

Common Audit Findings

Risks identified but not treated
This occurs when risk assessments are completed but no formal treatment decisions are documented. Prevent this by requiring treatment fields to be completed before a risk assessment is marked final.
Mitigation actions lack owners or due dates
Auditors commonly see mitigation plans without accountability, which weakens effectiveness. Assign a named owner and due date for every mitigation action to avoid this issue.
Outdated mitigation status
Risk treatment plans are often not updated after initial creation. Perform and document quarterly reviews to ensure statuses and timelines remain current.
Risk acceptance not justified
Accepted risks may lack documented rationale or approval. Document the reason for acceptance and align it with the organization’s risk appetite.

Related Processes

Key Roles

Security Lead