SOC Risk Assessment: The SOC 2 Requirements Auditors Test

On February 12, 2024, attackers logged into a Change Healthcare remote-access portal that had no multifactor authentication, and UnitedHealth CEO Andrew Witty later told the Senate Finance Committee the company paid a $22 million ransom. The SOC risk assessment exists to catch exactly that kind of gap.

The breach eventually touched 190 million Americans and cost roughly $2.9 billion to clean up. Numbers that size explain why customers now demand SOC 2 reports from every vendor touching their data, and why the risk assessment behind those reports gets read closely.

SOC Risk Assessment: Key Takeaways
SOC means System and Organization Controls; a SOC risk assessment satisfies SOC 2 criteria CC3.1 through CC3.4, mapped to COSO principles 6 through 9.
Change Healthcare’s missing MFA on one portal cost a $22 million ransom, 190 million breach notices, and roughly $2.9 billion, per Senate testimony.
Build the register from assets and vendors, score on an anchored five-point grid, and link every above-appetite risk to an owned control.
CC3.3 makes fraud consideration mandatory and CC3.4 makes reassessment after material change mandatory; auditors flag both most often.
US breaches average a record $10.22 million and 30 percent involve third parties, so vendor entries belong inside the register itself.
Refresh the SOC risk assessment at least annually and on every material change; a register older than the Type II window invites a finding.

The pages ranking for this keyword blur three topics, so precision is the differentiator here: what SOC stands for, the four CC3 criteria a SOC risk assessment must answer, a working register you can copy, and the reassessment rhythm a Type II audit window demands. Get those four right and audit week turns into a records review.

What a SOC Risk Assessment Is and Which SOC You Mean

SOC stands for System and Organization Controls, the AICPA’s attestation suite, and a SOC risk assessment is the documented process behind criterion CC3 of a SOC 2 examination. Search results muddle it with social risk and Security Operations Center reviews. Committing to the right meaning up front saves a wasted audit cycle.

Report	What it covers	Who reads it
SOC 1	Controls relevant to customers’ financial reporting	User entities and their financial auditors
SOC 2	Security plus optional Trust Services categories	Customers and security teams, restricted use
SOC 3	General-use summary of the SOC 2 result	Public, marketing pages, prospects

SOC 2 is where the risk assessment requirement lives. The AICPA’s Trust Services Criteria organize the examination around security plus four optional categories, and the common criteria borrow their structure from COSO’s 17 internal control principles. A service organization picks its categories; CC3 applies regardless.

Type matters as much as scope. A Type I report checks control design at one date, while a Type II tests operating effectiveness across a window, usually 12 months, which means the SOC risk assessment must stay current for the entire period. Our comparison of SOC 2 versus ISO 27001 covers when each certification fits.

The Breach That Shows Why a SOC Risk Assessment Matters

Change Healthcare processed claims for one in three US patients when ALPHV/BlackCat got in through that unprotected portal. Witty’s testimony landed the point no framework document can: the company knew MFA policy existed, yet one legacy server still sat outside it. Risk assessments live or die on inventory honesty, the first step in any cyber security risk management plan.

What One Skipped Control Cost: The SOC Risk Assessment Case Study

Figure 1. One portal outside the MFA policy produced a ransom, 190 million notices, and a Senate hearing.

The costs keep compounding elsewhere too. IBM’s 2025 Cost of a Data Breach report puts the US average at a record $10.22 million against $4.44 million globally, and 30 percent of breaches now involve a third party, double the prior year. Every one of those third parties is someone’s SOC 2 vendor.

CC3: The Four Criteria Inside a SOC 2 Risk Assessment

Auditors test the risk assessment against four common criteria, CC3.1 through CC3.4, which mirror COSO principles 6 through 9. Objectives come first, because a risk is only definable as a threat to something the business promised. Vague objectives make every downstream judgment arbitrary.

CC3.1 to CC3.4: The SOC Risk Assessment Backbone

Figure 2. Four criteria, four COSO principles, one register that has to answer all of them.

Criterion	COSO principle	What the auditor wants to see
CC3.1	Principle 6	Objectives and service commitments specific enough to assess risk against
CC3.2	Principle 7	Entity-wide risk identification with documented analysis and treatment decisions
CC3.3	Principle 8	Fraud scenarios considered: incentives, pressures, opportunities, override
CC3.4	Principle 9	Reassessment triggered by significant business, personnel, or system change

CC3.2 carries most of the workload: identify risks across the entity and analyze them as the basis for a management decision. In practice that means a maintained register tied to systems and commitments, scored with a documented method, the discipline any risk assessment process teaches. Auditors sample it, then trace controls back to entries.

Building the SOC Risk Assessment Register

Picture a mid-size SaaS platform preparing its first Type II examination. The register starts from an asset and vendor inventory, adds threats against each Trust Services category in scope, then scores likelihood and impact on a defined scale. NIST SP 800-30 remains the cleanest published method for that middle step.

Register field	Why the auditor checks it
Risk ID and description	Sampled directly; vague entries invite deeper testing
Linked objective or commitment	Proves CC3.1 objectives actually drive the analysis
Trust Services category	Confirms scope matches the system description
Likelihood and impact score	Method must be documented and consistently applied
Owner and review date	Stale dates signal an abandoned process
Treatment and linked control	Controls tested in the report must trace back here

Scoring works best on a small, anchored scale. A five-point likelihood-by-impact grid with written anchors holds up under challenge better than any bare percentage, and moving from qualitative words to numbers gives the auditor something to trace. The unpatched portal that sank Change Healthcare would score 4 by 5 on any honest grid.

Breach Costs the SOC Risk Assessment Is Priced Against

Figure 3. A US breach averages $10.22 million; scoring impact honestly starts with numbers like these.

Treatment closes the loop. Every risk above appetite maps to a control, an owner, and a date, and the control list becomes the system description your auditor tests. High scores with no linked control are the fastest route to a qualified opinion, and security key risk indicators keep the treated risks visible between assessments.

Fraud and Vendor Risk in the SOC Risk Assessment

CC3.3 asks a question many first-year registers skip: where could fraud defeat the objectives? Auditors expect incentives, pressures, and opportunities considered explicitly, from payment-flow manipulation to an engineer overriding access controls. Segregation-of-duties gaps belong here, scored like any other entry and monitored through NIST cybersecurity key risk indicators.

Vendors get the CC3 treatment too, because IBM’s 30 percent third-party figure includes subservice organizations sitting inside your audit boundary. Decide the carve-out or inclusive question early, send a real vendor risk assessment questionnaire, and log complementary user entity controls where you rely on someone else’s report.

Risk area	Example scenario	Control the auditor expects
Internal fraud	Engineer disables logging to hide activity	Segregation of duties; immutable audit logs
Payment fraud	Invoice redirection through a spoofed vendor	Dual approval on banking changes
Management override	Executive bypasses change management	Board-level reporting; whistleblower channel
Subservice failure	Cloud provider outage breaks availability	Carve-out disclosure; monitored SLAs
Fourth-party spread	Vendor’s vendor breached, data exposed	Questionnaires that reach one tier deeper

Keeping the SOC Risk Assessment Current for a Type II Window

CC3.4 turns the assessment into a standing process by demanding reassessment when anything material changes. New products, acquisitions, staff turnover in key roles, and fresh entries on CISA’s Known Exploited Vulnerabilities catalog all qualify as triggers. A register dated 11 months before the audit reads as abandonment.

Task	Owner	Trigger or cadence
Full register review	Security or compliance lead	Annually, before the audit period opens
Change-triggered reassessment	Risk owner for the affected area	Same month as the change
Vendor register refresh	Procurement plus security	On onboarding and at renewal
High-risk trend review	Leadership or risk committee	Monthly dashboard
Evidence check against register	SOC 2 project owner	Quarterly, mirroring auditor sampling

The 241-Day Lifecycle a SOC Risk Assessment Shortens

Figure 4. Breaches take 181 days to find and 60 more to contain; current registers shorten both ends.

In our advisory work, the registers that sail through audit share one habit: reassessment frequency written into policy with named owners, not left to whoever remembers. Trend the open high risks monthly beside your cybersecurity KRIs and the Type II window stops being a scramble.

Common SOC Risk Assessment Questions Practitioners Ask

What is a SOC risk assessment?

A SOC risk assessment is the documented risk identification, analysis, and treatment process that SOC 2’s common criteria CC3.1 through CC3.4 require of a service organization. It ties risks to business objectives and Trust Services categories, scores them, and routes each above-appetite risk to a control an auditor can test.

Is a SOC risk assessment the same as a social risk assessment?

No. SOC stands for System and Organization Controls, the AICPA attestation family, so the assessment concerns information systems and service commitments. Social risk assessment evaluates community and stakeholder impacts and belongs to ESG and project finance, a separate discipline with separate methods.

How often should a SOC risk assessment be updated?

Formally at least once a year, and again whenever a material change lands: a new product, an acquisition, a major vendor swap, or a serious incident. Type II examinations cover a 12-month window, so an assessment older than the period under audit invites a finding. Put the cadence in policy.

Who should run the SOC risk assessment?

A named owner, typically the security or compliance lead, with input from engineering, operations, and finance, because CC3.4 findings usually trace to missing voices. External help speeds the first cycle, and an information security management system gives the work a durable home afterward.

What framework should score a SOC risk assessment?

SOC 2 mandates no single method, so pick one, document it, and stay consistent, whether it follows NIST or ISO 27001. NIST SP 800-30 pairs naturally with the NIST Cybersecurity Framework, five-point grids satisfy auditors when the anchors are written down, and banks often reuse the FFIEC assessment tool. Auditors reward consistency over sophistication.

Does a SOC risk assessment cover fraud?

Yes, explicitly. CC3.3 requires the entity to consider fraud potential when assessing risks, mirroring COSO principle 8, so registers need entries for payment manipulation, privileged-access abuse, and management override. Auditors flag fraud sections written as an afterthought, which makesthreat-based assessment a sensible companion.

Six SOC Risk Assessment Findings Auditors Keep Writing Up

Ask a SOC 2 auditor what they write up most and the answers barely change from firm to firm. The six findings below surfaced in every practitioner guide we reviewed for this piece, and each one is preventable with a register field or a calendar entry.

Finding	Root cause	Remedy
Register missing entirely or rebuilt for audit week	Assessment treated as a deliverable	Stand up a living register with owners and dates
Risks with no linked controls	Scoring disconnected from treatment	Require a control or acceptance sign-off per entry
Fraud section blank or boilerplate	CC3.3 misread as optional	Score at least five fraud scenarios explicitly
No reassessment after a major change	CC3.4 triggers undefined	List triggers in policy; log each reassessment
Undocumented scoring method	Scores assigned by feel	Publish anchored scales; train the raters
Vendors excluded from the register	Third parties assumed out of scope	Add subservice organizations and questionnaire results

What 2026 and 2027 Hold for the SOC Risk Assessment

AI has already moved inside the audit. Automated evidence platforms pull tickets, configs, and access logs continuously, which shifts auditor attention to the judgment layers, and the risk assessment is the biggest judgment layer left. Registers with sloppy scoring will stand out more, not less, as everything around them automates.

The regulatory floor under the voluntary standard is rising on three fronts at once. The SEC’s cybersecurity disclosure rules make material-incident judgment a board matter, the FTC’s Safeguards Rule requires written risk assessments outright, and HIPAA’s Security Rule never stopped demanding one. A SOC register increasingly doubles as the evidence file for all three.

Third-party risk will dominate the next revision cycle of buyer expectations. With 30 percent of breaches arriving through vendors, procurement teams have started reading CC3 sections before signing, and the Verizon DBIR gives them fresh ammunition every spring. Customer questionnaires will start quoting your own register back at you.

The Change Healthcare epilogue is the paragraph to reread each year. One inventory gap at a certified, well-resourced company produced 190 million breach letters and a Senate hearing. Registers built with that story in mind, current, scored, and owned, are the strongest argument for disciplined cybersecurity risk management.

 

Get Your SOC Risk Assessment Audit-Ready With Risk Publishing

Most registers we review would survive a design test and fail an operating one, and the difference is six months of unglamorous upkeep. Risk Publishing maps your SOC risk assessment to CC3.1 through CC3.4, pressure-tests the scoring, and builds the reassessment calendar your Type II window needs. Reach us via contact or browse our services first.