Skip to content
compliancebase
SOC 2CC9 — Risk Mitigation

CC9.1

Risk Mitigation

SOC 2 · 2017 TSC (2022 Revised Points of Focus) · Last verified August 2026

Objective

Identify risks that could disrupt objectives and select mitigation activities, including insurance, diversification, acceptance, or changes to operations.

Points of focus

  • Connect each material risk to a named response and owner
  • Consider mitigation choices beyond preventive security controls
  • Track residual risk after the selected response operates

Implementation notes

Tie product, infrastructure, financial, and dependency risks to concrete response tickets; require an accountable executive to approve residual exposure and revisit it after architecture or customer-volume changes. Operationalize connect each material risk to a named response and owner in ticketing, IdP, or GRC workflows with named owners — not only in a static policy PDF. Retain risk register showing response, owner, due date, and residual rating with reviewer identity, population scope, dates, and remediation outcomes auditors can sample. A recurring failure mode is that high risks remain listed with no funded treatment or explicit acceptance Revisit after material architecture, vendor, data-flow, or leadership changes and document the decision.

Audit tip: Sample risk register showing response, owner, due date, and residual rating with dates and named reviewers. Be ready to walk through how you detect and correct: high risks remain listed with no funded treatment or explicit acceptance

Evidence auditors typically request:

  • Risk register showing response, owner, due date, and residual rating
  • Executive risk acceptance or mitigation approval records
  • Business continuity, insurance, or concentration-risk review artifacts

Common gaps

  • High risks remain listed with no funded treatment or explicit acceptance
  • Insurance is cited as mitigation without checking exclusions against the SaaS loss scenario

Cross-Framework Mapping

FrameworkRequirementImplementation note
SOC 2CC9.1This control
ISO 27001A.5.29, A.5.30ISO business continuity and ICT readiness themes support mitigation planning.
HIPAA§164.308(a)(1)HIPAA risk analysis informs which residual risks are reasonable to accept.
GDPRArticle 32GDPR accountability expects documented risk treatment for personal-data processing.

Primary sources

Frequently Asked Questions

Risk Mitigation applies to the systems and commitments in your Trust Services Criteria scope. Translate the requirement into concrete operating workflows — connect each material risk to a named response and owner — with evidence stored where auditors and customers can sample it.

Lead with risk register showing response, owner, due date, and residual rating and pair it with executive risk acceptance or mitigation approval records. Samples should show who performed the control, when, against which population, and what changed as a result.

Teams often fail because high risks remain listed with no funded treatment or explicit acceptance Close the loop with dated operating records and test the control on a realistic production path.

Control operation can often be shared across SOC 2, ISO 27001, GDPR, and HIPAA — but each framework uses different vocabulary and accountability. Maintain an explicit crosswalk rather than assuming equivalence.

Review at least annually and after material product, vendor, or data-flow changes. High-risk or privileged paths may need quarterly sampling even when the criterion does not prescribe a cadence.

Framework versions referenced in this page:

  • SOC 2 — 2017 TSC (2022 Revised Points of Focus)

Last verified: August 2026 · Primary sources linked above