Risk Management
The organization performs periodic risk assessments covering security, availability, confidentiality, privacy, fraud, vendors, customer integrations, AI/LLM workflows, and material technology changes.
Use this guide to put the control into operation, decide what records to retain, and check that an auditor can trace the evidence back to the work your team performed.
Maintained by GreenHat Security · Reviewed August 21, 2026
Management has a current, defensible view of the scenarios that could prevent the company from meeting its security and service objectives, with prioritized treatment decisions and accountable owners.
First SOC 2 program
Run a focused annual workshop with the founder, engineering, security, product, legal, and operations leads. Build a practical risk register from real systems, customer commitments, vendors, incidents, and planned changes, then assign treatment owners and dates.
As the company scales
Use a consistent scoring method across business processes and services, connect risks to assets and controls, add targeted assessments for material changes, fraud, vendors, privacy, and AI-enabled workflows, and obtain documented management review of residual risk.
Define the services, customer commitments, systems, data, locations, business processes, and trust categories included in the assessment.
You should end up with: An approved assessment scope with stated business and service objectives.
Use assets, data flows, incidents, threat information, vendor dependencies, fraud possibilities, customer integrations, AI-enabled activity, and planned changes to describe specific events and impacts.
You should end up with: A risk register containing clear cause-event-impact scenarios rather than one-word topics.
Define likelihood and impact scales, relevant impact dimensions, time horizon, and criteria for inherent and residual ratings, then record the rationale for each score.
You should end up with: A documented scoring method and consistently rated risks with supporting rationale.
Identify the controls and operating measures that reduce each risk, consider available performance information, and avoid giving credit where the safeguard does not address the stated scenario.
You should end up with: Risk-to-control mappings and a supported residual-risk conclusion.
Decide whether to mitigate, transfer, avoid, or accept each risk, then assign an owner, target state, actions, resources, milestones, and due date.
You should end up with: A prioritized treatment plan linked to each risk and approved acceptance records where applicable.
Have management challenge the results and treatment priorities, then update the assessment after material product, technology, vendor, regulatory, customer, or threat changes.
You should end up with: Dated management review and targeted reassessments showing what changed and why.
Build the evidence set in three layers: what defines the control, who approved or reviewed it, and what proves it operated. Collect operating records when the work happens so they remain dated, attributable, correctly scoped, and traceable to the underlying activity.
Before sharing, remove unrelated personal or customer data, never expose passwords, tokens, or secret values, preserve enough source context to authenticate the record, and use the secure exchange approved for the engagement.
Documents that define the control, its scope, ownership, and expected way of working.
Confirm what the record proves
Individual cause-event-impact scenarios are rated, linked to safeguards, assigned to owners, and tracked through treatment or approved acceptance.
Include this context
risk identifier and scenario
Include this context
affected service or objective
Include this context
inherent and residual rating
Include this context
control or safeguard linkage
Include this context
risk and treatment owners
Include this context
treatment status and due date
Weak evidence to avoid
A list containing phishing, ransomware, and vendors with all risks marked medium and no impact scenario, control linkage, owner, treatment, or rationale.
Confirm what the record proves
Risk ratings follow defined likelihood, impact, time-horizon, inherent-risk, and residual-risk criteria that trained reviewers can apply consistently.
Include this context
likelihood scale
Include this context
impact dimensions and scale
Include this context
rating calculation or matrix
Include this context
inherent and residual definitions
Include this context
acceptance and escalation thresholds
Include this context
version and approval date
Weak evidence to avoid
A red-yellow-green matrix with no definitions for likelihood, customer impact, financial impact, residual risk, or when management approval is required.
Records showing that an accountable person reviewed, approved, challenged, or accepted the work.
Confirm what the record proves
Management assessed relevant security, availability, confidentiality, privacy, fraud, vendor, integration, AI-enabled, and technology-change scenarios across the defined service scope.
Include this context
assessment scope and objectives
Include this context
assessment period and date
Include this context
participants
Include this context
risk themes and conclusions
Include this context
material changes considered
Include this context
management approval
Weak evidence to avoid
A generic cyber-risk summary that does not identify the assessed products, data, vendors, fraud scenarios, planned changes, participants, or management conclusion.
Confirm what the record proves
Management challenged risk scope, ratings, treatment priorities, accepted risks, resources, and overdue actions rather than merely receiving the assessment.
Include this context
review date and attendees
Include this context
assessment version reviewed
Include this context
material risks discussed
Include this context
challenge or decision
Include this context
accepted risk authority
Include this context
actions and due dates
Weak evidence to avoid
A slide-deck distribution email with no meeting record, attendee list, rating challenge, priority decision, accepted risk, or assigned action.
Confirm what the record proves
Material product, vendor, architecture, data-use, threat, or AI-enabled changes received focused risk analysis outside the annual cycle.
Include this context
assessment trigger
Include this context
change and affected scope
Include this context
scenarios and ratings
Include this context
reviewers
Include this context
treatment decision
Include this context
approval and completion date
Weak evidence to avoid
A launch checklist with risk reviewed checked but no described change, scenarios, affected data, rating, reviewers, or treatment decision.
Type 1
The current risk methodology, latest approved enterprise risk assessment and register, and current treatment plan as of the examination date. Include a targeted assessment tied to an actual qualifying trigger when one exists; if a complete query of product, architecture, vendor, incident, and AI-enabled change triggers returns no qualifying occurrence, retain the zero-result query and walkthrough a realistic trigger through the current scoring, treatment, and approval path.
Type 2
All enterprise risk assessments scheduled or completed, all risks added, rescored, accepted, closed, or assigned new treatment, and all material-change events requiring targeted assessment during the review period.
Reconcile the risk register to the approved assessment report, then reconcile material product, architecture, vendor, incident, and AI-enabled change records to targeted-assessment decisions and explain every excluded trigger.
Use this checklist to prepare for procedures an auditor may perform. The exact steps and sample selection depend on your engagement scope and the service auditor's professional judgment.
Determine whether the control is designed to achieve this result: Management has a current, defensible view of the scenarios that could prevent the company from meeting its security and service objectives, with prioritized treatment decisions and accountable owners.
Compare the documented owner with the intended role (Executive Management / CISO), then compare dated records with the stated cadence: At least annually and upon material change.
Reconcile the risk register to the approved assessment report, then reconcile material product, architecture, vendor, incident, and AI-enabled change records to targeted-assessment decisions and explain every excluded trigger.
The current risk methodology, latest approved enterprise risk assessment and register, and current treatment plan as of the examination date. Include a targeted assessment tied to an actual qualifying trigger when one exists; if a complete query of product, architecture, vendor, incident, and AI-enabled change triggers returns no qualifying occurrence, retain the zero-result query and walkthrough a realistic trigger through the current scoring, treatment, and approval path.
All enterprise risk assessments scheduled or completed, all risks added, rescored, accepted, closed, or assigned new treatment, and all material-change events requiring targeted assessment during the review period.
Documents that define the control, its scope, ownership, and expected way of working.
For each selected record, confirm it demonstrates Individual cause-event-impact scenarios are rated, linked to safeguards, assigned to owners, and tracked through treatment or approved acceptance.
For each selected record, confirm it demonstrates Risk ratings follow defined likelihood, impact, time-horizon, inherent-risk, and residual-risk criteria that trained reviewers can apply consistently.
Records showing that an accountable person reviewed, approved, challenged, or accepted the work.
For each selected record, confirm it demonstrates Management assessed relevant security, availability, confidentiality, privacy, fraud, vendor, integration, AI-enabled, and technology-change scenarios across the defined service scope.
For each selected record, confirm it demonstrates Management challenged risk scope, ratings, treatment priorities, accepted risks, resources, and overdue actions rather than merely receiving the assessment.
For each selected record, confirm it demonstrates Material product, vendor, architecture, data-use, threat, or AI-enabled changes received focused risk analysis outside the annual cycle.
Use the categories that apply to this control: connect any policy or design artifact to its approval or review record, then trace a selected operating record through execution, result, and any exception or remediation.
These identifiers help you navigate related Trust Services Criteria. They do not reproduce the criteria or prove that this control fully addresses them in your environment.
Confirm final scope, mappings, and testing expectations with your service auditor. SOC 2® is an AICPA trademark; GreenHat Security is not affiliated with or endorsed by AICPA.