CC3.2 risk identification and analysis: SOC 2 evidence

What SOC 2 CC3.2 asks you to identify and analyze

CC3.2 asks you to identify risks to your objectives across the whole entity, analyze them, and use that analysis to decide how to respond. It restates COSO Principle 7 in SOC 2 terms. An auditor testing it will want to see a documented process that starts from the objectives you set under CC3.1, finds what could stop you reaching them, judges how serious each risk is, and records the response you chose. The criterion's points of focus cover analyzing internal and external factors, involving managers at the right levels, estimating significance, determining responses, identifying threats and the vulnerability of system components, and analyzing threats from vendors, business partners and other parties. Those points of focus are prompts for designing your process, not a checklist you must complete item by item.

The criterion is hard because most risk registers fail it in one of two ways. Some are a list of generic risks with no owner, no likelihood or impact rating, and no link to a treatment decision, so the auditor cannot see analysis. Others sit apart from the rest of the program: they do not mention the system boundary described in the system description, the components that handle customer data, or the objectives the organization committed to. Confirm with your auditor how they expect the register to connect to the description and to your control matrix before you build it. In practice, ask who approves the risk rating scale, how often the assessment is refreshed, and which third parties appear as risk sources. Vendor and partner threats deserve particular attention, since CC9.2 covers the same ground from the contract side. Tools such as the open-source CISO Assistant can hold risk scenarios and link them to controls, but the assessment itself still needs management judgment and a record of it.

Which assets, threats and third parties the risk identification must cover

The system boundary decides what the risk identification must examine. Each decision below changes which assets, threat sources and third parties enter the analysis, and each one is easy to get wrong in ways an auditor will test.

System boundary and system description

The system description defines which services, infrastructure, people and data the report covers, and CC3.2 risk identification must follow that boundary. A narrow boundary keeps the analysis focused but can leave out components that customers rely on through shared tooling. A wide boundary adds more assets, more threat scenarios and more owners who must take part. Check that the risks you identified match the systems named in the description, and that no in-scope component appears in the description without a corresponding risk entry.

In-scope infrastructure and components

Identify the servers, containers, databases, networks, endpoints and management consoles inside the boundary, then analyze the threats and vulnerabilities for each class. A wider scope means more asset classes to inventory and more vulnerability sources to monitor. A narrower scope may exclude a shared identity provider or logging pipeline that the in-scope systems depend on, which still creates risk to the report. Confirm that every component has an owner and an inventory record, because an asset missing from the inventory is an asset missing from the risk assessment.

Data classes and processing paths

List the categories of data the system stores, transmits and processes, such as customer records, credentials, payment details or operational logs. The sensitivity of each class drives how severe a threat to it is judged, and the path data travels between components shapes where threats can enter. Wider scope adds data classes and more paths to analyze. If the report covers confidentiality or privacy, those categories bring their own criteria and their own data risks. Check that each data class maps to at least one identified threat and one response.

Teams and roles in risk discussions

CC3.2 expects the risk assessment to involve appropriate levels of management, so identify who owns the objectives, who runs the systems and who approves risk responses. A wider scope usually means more teams must contribute, including engineering, operations, support and product owners. A narrow scope may let a small leadership group decide, but the decisions still need documented sign-off. Record attendees, dates and decisions so an assessor can see who evaluated each risk and who accepted the residual exposure.

External threat sources

Identify the external actors and events that could affect the objectives, including criminal groups, targeted attackers, natural hazards, supply chain compromise and regulatory change. Analyze both the internal and external factors the points of focus describe. A wider scope exposes more attack surface and more threat categories, while a narrower scope can hide threats that enter through shared infrastructure. Document the source of each threat intelligence input, such as vulnerability advisories or incident reports, so the analysis can be refreshed rather than repeated from memory.

Vendors and business partners in scope

List the vendors, cloud providers, subservice organizations and business partners that store, process or can reach in-scope data or systems. Each third party brings threats of its own, such as outages, access misuse or weak security practices, and these feed the same risk analysis as internal threats. Wider scope adds more vendors to assess, and vendor risk is also covered by CC9.2. Confirm which vendor reports you rely on, which controls they cover and which remain your responsibility.

How an assessor tests CC3.2 in a Type 1 and Type 2 examination

This table compares how a service auditor tests each part of CC3.2 in a Type 1 examination, which looks at design as of a date, and in a Type 2 examination, which looks at operation over a period. Read each row as a question the assessor asks, the evidence they request, and the gaps they most often raise. The main takeaway is that a risk assessment must be documented, repeatable and visibly reviewed by management, not just written once.

Test area	Type 1 focus and evidence requested	Type 2 focus and common findings
Risk assessment policy and methodology	Review the written policy and method for identifying and analyzing risks. Confirm it exists and was approved as of the examination date.	Confirm the method was followed throughout the period. Common finding: a methodology that changed mid-period without documented approval.
Documented risk assessments	Obtain the most recent risk assessment and confirm it covers the system described in the report.	Sample documented assessments across the period. Common finding: assessments performed late, skipped in a cycle, or not refreshed after major system changes.
Traceability to objectives	Check that each identified risk links to a defined operational, reporting or compliance objective (CC3.1).	Test whether the link held over time. Common finding: risks listed with no stated objective, or objectives changed without updating the risk register.
Significance and response decisions	Check that each risk has a recorded significance rating and a chosen response such as accept, mitigate, transfer or avoid.	Sample risks and trace each response to a control or owner. Common finding: ratings with no rationale, or responses that point to controls that do not exist.
Threats and component vulnerabilities	Check that threats to the system and vulnerabilities of its components, including infrastructure, software and data stores, are considered.	Compare the assessment with inventory and vulnerability records for the period. Common finding: new assets or open vulnerabilities absent from the assessment.
Vendor and business partner risk	Check that risks from vendors, subservice organizations and business partners are analyzed and linked to CC9.2 activities.	Sample vendor risk analyses and confirm they were refreshed when contracts or data flows changed. Common finding: critical vendors missing from the analysis.
Management review of results	Confirm that appropriate levels of management reviewed and approved the assessment before the examination date.	Obtain dated review and approval records for sampled periods. Common finding: approvals missing, undated, or signed by someone without authority.

Running a CC3.2 risk identification and analysis cycle

This sequence turns CC3.1 objectives into a documented risk register, a significance ranking and a recorded set of management responses. Each step produces an artifact an assessor can trace from objective to decision.

Confirm objectives from CC3.1
Start by re-reading the documented operations, reporting and compliance objectives and the sub-objectives that apply to the systems in scope. Compliance lead and the system owner confirm that each objective is stated clearly enough to test whether a risk could prevent it. The output is a short, dated objectives list that the risk register references by ID. The step is done when every risk later in the cycle can be traced to at least one confirmed objective.
Gather internal and external factors
Collect the inputs that could change risk: internal factors such as new products, staffing changes, prior incidents, audit exceptions and changes in management, and external factors such as regulatory updates, customer contract requirements, threat intelligence and the technology market. Compliance lead collects the inputs and records the source of each. The output is a factors log with a date and owner per entry. The step is done when leadership has reviewed the log and confirmed nothing material is missing.
Build the asset and component inventory
Build a list of the system components that support the in-scope objectives, including hosts, containers, databases, network equipment, endpoints, cloud accounts and the software running on them. Platform engineering can draw much of this from existing sources such as GLPI for asset records or Wazuh Syscollector for hardware, operating system, software, open ports and services collected from endpoints. The output is an inventory with a named owner and classification for each component. The step is done when a sample of live systems matches the inventory.
Identify threats and vulnerabilities per component
For each component in the inventory, the engineering team and security staff list the threats that could affect confidentiality, integrity or availability and the vulnerabilities that threats could exploit, such as unpatched software, misconfigured access or weak logging. Scanner and penetration test findings can be imported into a tool such as DefectDojo, which deduplicates findings using per-tool hashcode fields. The output is a draft risk register with one row per component and threat pair. The step is done when every component has been reviewed at least once.
Identify vendor and partner threats
Compliance lead and procurement list the vendors, business partners, subservice organizations and hosting providers that the system depends on, then note the risks each one introduces, such as a vendor outage, a weakened security posture or a breach in its environment. Review the vendors' own SOC reports and contract terms where available. The output is a vendor risk section of the register that links to the vendor management records covered under CC9.2. The step is done when every critical dependency has at least one documented risk entry.
Estimate significance with a stated method
Score each risk using the significance scale the organization has defined, typically a combination of likelihood and impact on the confirmed objectives. The scale, its levels and the thresholds that trigger escalation are set by the organization, documented in the risk assessment policy, and applied the same way across all entries. Two reviewers score each high-impact risk where practical. The output is a scored register with the method and reviewer recorded. The step is done when the scoring rules are written down and every row has a score.
Decide the response for each risk
For each scored risk, management chooses one response: accept, mitigate, transfer or avoid. Mitigated risks are linked to the control that addresses them, and accepted risks record who approved the acceptance and why. The output is a response log that shows the decision, the rationale and any linked control or ticket. The step is done when no scored risk lacks a response.
Assign owners and record management review
Each risk and each planned response receives a named owner who is accountable for it. Senior management reviews the register, the scores and the response log, then records its review, approvals and any challenges in dated minutes or sign-off. The output is an approved register with owners and a management review record that an auditor can sample. The step is done when the review is recorded and the register is version-controlled for the next cycle.

Which risk assessment records satisfy an auditor's sample

An auditor testing CC3.2 looks for a traceable chain from objectives to risks to treatment decisions, and each record below is one link in that chain. The auditor selects samples from these records, and in a Type 2 examination the organization must be able to produce them for the whole observation period, not only at the end.

Risk assessment methodology and significance scale

This document defines how the organization identifies threats, estimates likelihood and impact, and rates significance, so the auditor can judge whether the assessment was done the same way every time. Check that it names who performs the assessment, which internal and external factors it considers, and how significance levels map to required responses. Keep it under version control with dated revisions and a review cadence the organization sets and follows. An auditor will ask which version was in force on each sampled date.

Risk register mapped to objectives

The risk register lists each identified risk, the objective it threatens, its likelihood, impact and rating, and the control or owner assigned to it. The auditor traces sampled risks back to stated objectives and forward to treatment, so gaps in either direction are common exceptions. Confirm that every risk has an identifiable owner, a rating from the approved scale and a last-reviewed date. Export and archive dated snapshots between audits so historical states can be reproduced.

Threat and vulnerability records per component

These records tie threats and weaknesses to specific system components such as production hosts, databases, identity providers and deployment pipelines. The auditor looks for evidence that the inventory was current when the assessment ran and that vulnerabilities were analyzed, not just listed. Asset inventories and scanner output can supply much of this, provided each finding is dated and linked to a risk entry. Ask your team to confirm which tool is the source of truth for each component class.

Vendor and business partner risk records

CC3.2 expects analysis of threats arriving through vendors, business partners and other third parties, and the auditor will sample these entries against the vendors actually in use. Each record should show the service provided, the data or access involved, the risk identified and how it was assessed. Because CC9.2 covers vendor management in more depth, make sure these records and the vendor review records describe the same relationships. Confirm the list is refreshed when a vendor is added, changed or removed.

Response decisions with owners and approval

For each analyzed risk, the organization records whether it accepts, mitigates, transfers or avoids it, who owns the decision and who approved it. The auditor checks that responses follow from the significance rating and that approvals came from someone with authority for that risk. A treatment without a dated approval or a named owner is a frequent sampling exception. Track due dates and status changes so the register shows what happened after the decision.

Management review minutes and sign-offs

Minutes, meeting invitations or signed approvals show that management reviewed the risk assessment and took part in deciding responses, as the CC3.2 points of focus describe. The auditor samples these to confirm the review happened at the stated cadence and that the right levels of management attended. Store them with the risk register version they reviewed, so each sign-off points to a specific document state. Confirm the cadence you commit to is one you can meet every period.

What CC3.2 costs in staff time, tooling and outside review

This table compares the cost components of the CC3.2 risk identification and analysis work, showing who is paid, whether each cost is one-time or recurring, what drives it, and how to reduce it. Read it as a checklist for a written quote: most of the effort sits in internal staff time, and open-source licenses reduce only part of the spend.

Cost component	One-time or recurring	What drives it	How to keep it down
Internal staff time for the first assessment	One-time (repeats when the scope changes)	Number of systems, vendors and business units in scope; how many people must agree on objectives and threats	Limit the first pass to the production system boundary, reuse existing architecture and threat documents, and set a dated decision meeting
Recurring staff time for reviews	Recurring	How often the risk register is reviewed, and how many risks change owners or ratings each cycle	Tie reviews to existing change and incident processes, and review only risks whose ratings or systems changed
Tooling or licenses	Recurring (subscription or support) or none for community editions	Choice between a GRC platform, a register kept in documents, and separate scanners or inventory tools; hosting and support tiers	Self-hosted open-source tools remove license fees but still need hosting, upgrades and administration time; confirm each tool's license terms with its publisher
Engineering time to produce inventory and scanner data	Setup one-time, then recurring upkeep	Number of endpoints, cloud accounts and network devices; whether an agent is deployed and how findings are imported	Automate asset discovery and agent-based inventory, and import scanner output into one place rather than copying results by hand
External facilitation or review	One-time for facilitation, periodic for review	Whether internal staff have done a formal risk assessment before; how much independent challenge is requested	Ask for a fixed-scope facilitation with written deliverables, and separate it from any work the auditor performs
Auditor sampling effort	Recurring each examination period	Number of risks and controls tested, the observation period for a Type 2, and the quality of the risk register and its evidence	Keep a dated, complete risk register with owners and review records so the auditor can select samples without long follow-up requests

Open-source tools that feed the CC3.2 risk register

CC3.2 asks the organization to identify risks to its objectives and analyze them, and that work depends on knowing what assets exist, what they run, and what weaknesses have been found. The four tools below each supply one of those inputs, but none of them decides what a risk is worth or how to respond to it.

CISO Assistant for the register

CISO Assistant (AGPL-3.0-only) ships more than 200 frameworks, including SOC 2, and can run assessments with automatic mapping between frameworks. Use it to hold the risk register, link each risk to the criteria it affects, and track the responses chosen. Confirm that its SOC 2 content matches your own criteria selection and wording before you rely on the mapping. Check the AGPL-3.0-only obligations with counsel if you plan to modify and host it for others.

GLPI as the asset source

The GLPI Assets module records computers, monitors, software, network equipment, peripherals, printers, phones and racks. Native inventory, built into GLPI since version 10, can receive data pushed automatically by the GLPI Agent, so the asset list is not kept by hand alone. Each asset is a component that a threat or vulnerability can affect, so the inventory is where CC3.2 analysis starts. Check that owners and criticality are recorded for each asset class. GPL-3.0-or-later applies to GLPI itself, so review its terms if you distribute modified copies.

Wazuh for component data

The Wazuh Syscollector module collects hardware, operating system, installed software, network interfaces, open ports, running processes, services, users and groups, and Windows updates from each endpoint. This data describes the vulnerability surface of system components, which is what CC3.2 asks you to analyze. Confirm which endpoints report and how often, because gaps in coverage become gaps in the risk picture. Wazuh is GPL-2.0-only, so confirm that your deployment model and any modifications fit that license.

DefectDojo for vulnerability input

DefectDojo imports and reimports findings from more than 500 security tool report formats through its UI or API, and a generic findings import covers the rest. It deduplicates findings using per-tool hashcode fields, so one weakness reported by several scanners appears once in the analysis. Use it to consolidate scanner output before you judge significance and response. Confirm that each scanner's format is supported in the open source edition for your tools. DefectDojo is BSD-3-Clause licensed, which allows broad reuse with attribution and notice obligations.

Who identifies and decides risks, and what a partner can prepare

Your leadership and control owners decide what the organization is trying to achieve and which risks matter enough to act on. Those decisions belong to management and cannot be delegated to a consultant, a tool or an auditor. CC3.2 restates COSO Principle 7, which asks the organization to identify risks to its objectives across the entity and analyze them as the basis for deciding how to manage them, so the people who own those objectives must stand behind the result. The AICPA 2017 Trust Services Criteria set out the points of focus that management should weigh.

Objectives and tolerances: Executives confirm the operational, reporting and compliance objectives from CC3.1 that the risk assessment is measured against.
Significance and response: Control owners estimate how significant each risk is and decide whether to accept, reduce, transfer or avoid it.
Threat and vulnerability input: Engineering and operations staff know which components are exposed, which vendors hold data and where the system changes most often. Their knowledge fills the register.
Sign-off: A named owner approves the register and the response decisions, and the approval is dated and kept as evidence.

Check that every risk in the register has a named owner who can explain, in their own words, why the chosen response is adequate.

Where CC3.2 risk assessments usually fall short

Most SOC 2 risk assessments contain a risk register but cannot show how risks were judged, linked to objectives, or acted on. Assessors test CC3.2 by sampling individual risks and following each one from its source to a documented decision, so the gaps below tend to surface in the same place: the sample.

Risks listed without significance

A register that names threats but gives no likelihood, impact or significance rating leaves the assessor unable to see why one risk received a control and another did not. CC3.2 expects significance to be estimated, so the assessor picks a risk and asks for the rating and the reasoning behind it. To check this, confirm each entry carries a documented scale, a rating for every risk, and the date the rating was set. Ratings written only in a spreadsheet cell, with no method, usually fail the sample.

Risks not traced to objectives

CC3.2 asks for risks to the entity's objectives, so a risk that cannot be tied to a stated objective looks like a generic list rather than an assessment. The assessor will start from a documented objective and ask which risks could prevent it. Confirm that each risk references the objective it threatens, and that the objectives themselves are the ones set under CC3.1. Ask whether the link runs in both directions.

Vendor threats analyzed only under CC9

Many teams record vendor risk once, in the third-party review under CC9.2, and never analyze how a supplier's failure could threaten the system under CC3.2. The CC3.2 points of focus ask for threats from vendors, business partners and other parties. Check that the risk register includes entries for critical suppliers, such as hosting, identity and support providers, with the threat, the affected objective and the response. Keep the CC9.2 review as the place for due diligence and contracts.

Vulnerabilities not linked to assets

A vulnerability finding that names no system component cannot be assessed for significance or responded to in a traceable way. CC3.2 expects the vulnerability of system components to be considered, so the assessor will pick a vulnerability and ask which asset it affects and whether that asset is in the inventory. Confirm that each finding maps to an inventory record and that the scanner, the asset list and the register use the same identifiers. Imported scan results should keep their asset references.

Assessment run once, never revisited

A risk assessment completed before the audit window and left untouched through the Type 2 observation period suggests the process does not operate. Assessors testing a Type 2 report look for evidence that risks were reviewed across the period, including after significant changes. The distinction with CC3.4 matters here: CC3.4 covers identifying changes that affect control, while CC3.2 needs the register itself to be re-analyzed. Confirm dated review records exist at the intervals the organization set, and that updates to the register are visible in its history.

No record of response decisions

Listing a risk and a control is not enough. CC3.2 asks the organization to determine how to respond, so an assessor will look for the decision: accept, mitigate, transfer or avoid, the owner who approved it, and the management involvement behind it. Missing sign-off is one of the most common findings in this area. Confirm each risk has a recorded response, an accountable owner, and evidence of review by the appropriate level of management. Fraud-related risks belong to CC3.3 and should be cross-referenced, not repeated here.

How buyers ask about cost, effort and timing for CC3.2

Can our own team complete the CC3.2 risk identification and analysis without a partner?

Yes, in most organizations the people who run the business and the systems can do CC3.2 themselves, provided someone owns the process and the results are documented. CC3.2 asks you to identify risks to your objectives across the entity, analyze them, estimate their significance and decide responses. Nothing in the criterion requires an outside firm. What usually decides whether an internal team succeeds is time and independence: someone must maintain the risk register, involve the right managers and keep it current after the first cycle. A partner can help with method, facilitation and evidence preparation, but the organization still owns the risks, the decisions and the sign-off. The independent CPA firm tests the result and never writes it for you.

How much staff effort does a CC3.2 risk assessment take, and what drives it?

Effort depends mainly on how many systems, vendors and business processes fall inside the SOC 2 scope and how many objectives they serve. Four factors move it most: the number of in-scope services and their data flows, how many teams must be consulted, whether an inventory of assets and vendors already exists, and how mature your existing risk records are. An organization starting from scratch will spend far more time on the first cycle than one that already keeps a register. Ask any provider to break the estimate into workshops, analysis, documentation and review, and to state which of those tasks your own staff will perform. No figure is given here because effort varies widely by environment.

Is paying an outside partner for CC3.2 worth the cost?

A partner is worth considering when internal staff lack time, have not run a formal risk assessment before, or need an independent facilitator to bring out risks that managers would otherwise leave out. The value lies in method and speed, not in certification, because no partner can issue an assessment result. Weigh the fee against the cost of rework: a register that the auditor rejects, or risks that were never linked to real system components, will cost more to repair later. Ask for a written scope listing deliverables, the workshops included and what the organization must supply. Partners that do not publish prices will provide a quote after that scope is agreed.

How long does the first SOC 2 risk assessment take, and what sets that timeline?

The first cycle usually takes longer than later cycles because the organization must define objectives, build an inventory of system components and vendors, and agree on how risks are scored. The main drivers are the size and clarity of the in-scope system, the availability of managers for workshops, the state of asset and vendor records, and how many rounds of review leadership needs before approving the register. Plan around your audit window: the risk assessment must be in place and operating before the examination period begins. Request a timeline from any provider that lists each milestone, the dependencies on your staff, and the review points. No duration is stated here because it depends on your environment.

What does CC3.2 need from engineering and leadership?

CC3.2 needs engineering to supply accurate facts about the system, and leadership to define objectives, accept risk and approve responses. Engineering contributes the component inventory, data flows, external dependencies, known vulnerabilities and the threats that matter to each service. Leadership contributes risk tolerances, decides which risks are significant and assigns owners for each response. Both groups must attend the analysis, because a register built by compliance alone often misses technical vulnerabilities, while one built by engineers alone often misses business and vendor impact. Agree these roles in writing before the workshops start.

Can open-source tools alone support a CC3.2 risk assessment?

Open-source tools can support much of the work, but they do not replace the judgment that CC3.2 expects. Inventory tools such as GLPI and Wazuh's Syscollector can record assets, software, open ports and services, which gives the analysis a factual base. Vulnerability findings can be consolidated in DefectDojo, and CISO Assistant can hold the risk register and map it to frameworks. What no tool decides is significance, risk tolerance or the response chosen for each risk. Confirm with each vendor which capabilities your version provides and test the exports against what your auditor will request before relying on them.

How DeployOpen scopes and prepares CC3.2 evidence

DeployOpen works on CC3.2 by preparing the systems and records that show how your organization identifies and analyzes risks to its objectives. Your organization owns the risk assessment and its decisions, and an independent CPA firm performs the examination and issues the report.

How we scope

Agree in writing which systems, business units and vendors the CC3.2 risk identification covers.
Confirm the objectives and sources of threat information the risk register must reference.
Fix deliverables, owners and timelines in a fixed-scope statement before any work starts.

How we build

Set up a risk register workflow in a self-hosted GRC tool such as CISO Assistant.
Connect asset inventories from GLPI and Wazuh Syscollector so threats map to real components.
Import vulnerability findings into DefectDojo to link analysis entries to tested weaknesses.

How we hand over

Document the risk identification method, scoring of significance and chosen responses.
Deliver exported risk register snapshots, review records and approval history for the auditor.
Walk your team through the evidence so owners can keep the register current between audits.

How we support

Offer ongoing support and retainers to refresh risk analyses as systems and vendors change.
Assist with evidence requests from your CPA firm during fieldwork, within the agreed scope.
Confirm with your auditor which vendor and partner risks they expect to see documented.