TSC-CC3.3 Guidance

TSC-CC3.3 requires you to explicitly consider fraud as part of your risk assessment and to show, with evidence, that this consideration drives controls and monitoring. To operationalize it quickly, define fraud scenarios relevant to your services, map them to control responses, assign owners and review cadence, and retain auditable proof that the process runs as designed ¹.

Key takeaways:

• TSC-CC3.3 is a fraud-risk lens on your existing risk assessment, not a standalone “fraud policy.”
• Auditors look for documented fraud scenarios, linked controls, and recurring review evidence ¹.
• The fastest path is a simple fraud risk register tied to your SOC 2 system boundary, plus monitoring and an audit trail.

A SOC 2 program can pass many technical tests and still fail a basic governance expectation: you assessed “risk,” but did not assess fraud risk. TSC-CC3.3 (COSO Principle 8) pushes you to treat fraud as a first-class risk category, with concrete scenarios, not generic statements. For a CCO, GRC lead, or compliance officer, the work is less about perfect fraud forensics and more about demonstrating disciplined thinking and repeatable execution: identify where fraud could happen in your environment, decide which scenarios matter, and show what you did about them.

In practice, this requirement becomes a structured add-on to your enterprise risk assessment (or SOC 2 risk assessment) that covers both internal and external fraud. It should connect directly to your trust services commitments: the systems in scope, the data they process, and the people and third parties who can influence outcomes. Your auditor will expect traceability from fraud risks to controls and evidence that you revisit the analysis as your business changes ¹.

The guidance below is written to help you implement the tsc-cc3.3 guidance requirement with minimal ambiguity and maximum audit-readiness.

Regulatory text

Excerpt (TSC-CC3.3): “COSO Principle 8: The entity considers the potential for fraud in assessing risks” ¹.

What the operator must do

You must be able to demonstrate that your risk assessment process explicitly considers fraud. That means:

• Fraud is named as a risk source (not implied).
• Fraud scenarios are plausible for your system boundary and business model.
• Your control environment addresses those scenarios with preventive/detective controls and monitoring.
• You retain evidence that the assessment and follow-up actions occur on a defined cadence ¹.

Plain-English interpretation (what auditors are really asking)

“Show me that you’ve thought about how someone could intentionally cheat, steal, manipulate, or misrepresent within your system, and that you built controls to reduce that risk.”

Fraud in this context is broader than “financial statement fraud.” In SOC 2 operational terms, it often includes:

• Insider abuse (privileged access misuse, data theft, sabotage).
• External fraud (account takeover, social engineering that leads to unauthorized changes).
• Fraudulent system use (misuse of customer accounts, API keys, or billing manipulation).
• Third-party-enabled fraud (a third party with access performs unauthorized actions).

A clean implementation produces a short list of prioritized fraud scenarios, each with documented mitigations, owners, and a review trail.

Who it applies to

Entities: Any organization undergoing a SOC 2 audit that includes the Common Criteria ¹.

Operational context: Applies wherever you have:

• People with access to sensitive data or production systems (employees, contractors, administrators).
• Monetization paths that can be manipulated (billing, credits, refunds, usage metering).
• Identity and access workflows (provisioning, role changes, SSO, API keys).
• Material reliance on third parties (cloud platforms, payment processors, support outsourcers).

If your SOC 2 system description includes a service organization boundary and you operate customer-impacting processes, auditors typically expect fraud risk to be reflected in your governance processes, not left to “security” alone ¹.

What you actually need to do (step-by-step)

Use this sequence to implement quickly while staying audit-aligned.

Step 1: Define scope and owners

1. Confirm the SOC 2 system boundary (products, environments, data types, key processes).
2. Assign a fraud-risk owner (often GRC) and process participants (Security, Finance/Revenue Ops, HR/People Ops, Support, Engineering).
3. Define where the record lives (GRC tool, risk register spreadsheet, or Daydream), and how changes are versioned.

Output: RACI for fraud-risk assessment and a scoped “fraud risk assessment” workpaper.

Step 2: Create a fraud scenario catalog tailored to your business

Start from your real workflows. Write scenarios as: Actor + method + target + impact.

Minimum set most auditors expect to see covered in some form:

• Privileged access misuse: admin extracts customer data from production.
• Unauthorized changes: engineer bypasses change control to deploy a backdoor.
• Support/social engineering: support agent resets MFA based on weak verification.
• Billing/usage manipulation: internal or external party alters usage records or refunds.
• Third-party access abuse: contractor uses access after offboarding.

Output: Fraud scenario catalog (10–25 scenarios is usually enough for mid-market teams; keep it right-sized as long as it’s defensible).

Step 3: Rate fraud scenarios using consistent criteria

Pick criteria you can defend in an audit. Common:

• Likelihood (based on access paths, history, control maturity)
• Impact (customer harm, confidentiality, service integrity, financial exposure)
• Detectability (how likely you are to catch it quickly)

Document the rubric once, then apply it consistently.

Output: Fraud risk register with ratings and rationale.

Step 4: Map each priority fraud risk to control responses

For each “high” or “meaningful” scenario, document:

• Preventive controls (least privilege, approval workflows, segregation of duties)
• Detective controls (logging, alerting, anomaly detection, access reviews)
• Corrective controls (incident response, disciplinary process, customer notification paths)

Tie these to your existing SOC 2 controls where possible; do not invent new controls unless there’s a real gap.

Output: Risk-to-control mapping (a simple table works).

Step 5: Implement monitoring and recurring review

TSC-CC3.3 expects the process to run, not to exist as a one-time document ¹.

• Set a review trigger list: major releases, new admin tooling, new third party with sensitive access, new revenue model, security incidents.
• Add recurring review to a governance calendar.
• Add action tracking for remediation tasks (owner, due date, status, evidence).

Output: Review schedule + action tracker with status history.

Step 6: Build the audit trail (make it easy to test)

Auditors test design and operating effectiveness by sampling evidence. Make the sampling easy:

• Meeting notes, agendas, and attendees
• Risk register version history
• Tickets showing control changes or remediation
• Logs or reports showing monitoring ran and exceptions were handled

Output: Evidence folder structure with naming conventions.

Required evidence and artifacts to retain

Keep artifacts that show both design and operation.

Core artifacts (high value in audits)

• Fraud risk assessment procedure or policy describing how fraud is considered in risk assessments ¹.
• Fraud risk register (scoped to SOC 2 system boundary) with scenario descriptions, ratings, and rationale.
• Risk-to-control mapping linking fraud risks to specific controls.
• Review evidence: calendar invites, minutes, sign-offs, and decision records.
• Monitoring evidence: access review reports, privileged activity logs, alert tickets, exception handling records.
• Testing results: internal control testing or QA evidence that the controls work as intended ¹.

Helpful supporting artifacts

• Background checks / onboarding controls (where applicable)
• Segregation of duties matrix (especially around billing, refunds, and admin actions)
• Third-party access lists and offboarding confirmations
• Incident response tabletop notes where fraud scenarios were exercised

Common exam/audit questions and hangups

Auditors frequently probe these points:

1. “Where is fraud explicitly considered?” If it’s buried in a generic risk assessment, you may fail the clarity test. Put “fraud” in headings, fields, and meeting agendas.
2. “Show the linkage.” They will ask how a fraud risk maps to a control, and then ask for evidence the control operated ¹.
3. “How did you choose scenarios?” A short narrative tying scenarios to system architecture and workflows prevents rework.
4. “What changed this period?” Type 2 audits make “period changes” a focal point. Show updates when products, teams, and third parties change.
5. “Who reviewed and approved?” Lack of a clear owner or reviewer is a repeat finding.

Frequent implementation mistakes (and how to avoid them)

Mistake	Why it fails	Fix
Fraud risk assessment is a one-time doc	Operating effectiveness cannot be shown	Add a recurring review cadence and retain evidence each cycle
Scenarios are generic (“fraud could happen”)	Auditor can’t test it	Write actor-method-target-impact scenarios tied to your systems
No linkage to controls	Becomes “paper compliance”	Maintain a risk-to-control mapping table and keep it current
Evidence retention is ad hoc	Sampling becomes painful	Create an evidence checklist and folder structure; assign an evidence owner
No testing	Auditors expect testing results where you claim control effectiveness 1	Add lightweight control testing or periodic self-assessments with recorded results

Enforcement context and risk implications

SOC 2 is an audit framework, not a regulatory enforcement regime, so “enforcement cases” are not the right mental model here ¹. The risk is commercial and contractual:

• A weak CC3.3 story can drive SOC 2 exceptions, scope limitations, or qualified opinions depending on severity and pervasiveness.
• Customers and procurement teams interpret fraud-risk governance as a proxy for insider risk readiness, billing integrity, and administrative control maturity.

Fraud risk assessment also reduces incident blast radius. Many high-impact security incidents include an element of intentional misuse (insider or social engineering). CC3.3 pushes you to plan for that reality.

Practical 30/60/90-day execution plan

First 30 days: establish the minimum viable program

• Appoint owner and stakeholders; define SOC 2 boundary for this workstream.
• Draft a one-page Fraud Risk Assessment Procedure aligned to your risk assessment process ¹.
• Build initial fraud scenario catalog and prioritize top scenarios.
• Start an evidence folder and naming convention.

Daydream fit: Use Daydream to centralize the fraud risk register, map risks to controls, and preserve version history so audit sampling is straightforward.

Days 31–60: connect fraud risks to controls and evidence

• Map priority fraud risks to existing controls (IAM, logging, change management, support workflows, billing controls).
• Identify gaps; open remediation tickets with owners and due dates.
• Define monitoring reports and exception handling steps for the top scenarios.
• Run one formal review meeting; capture minutes and approvals.

Days 61–90: prove operating effectiveness and get audit-ready

• Perform lightweight control testing on the mapped controls (sampling access reviews, change approvals, privileged activity logs) and retain results ¹.
• Update the fraud risk register based on remediation progress and any environment changes.
• Create an “auditor packet” folder: procedure, latest risk register, mapping, review evidence, testing evidence.
• Run a mock audit interview: be able to answer “show me” requests quickly.

Frequently Asked Questions

Do we need a standalone fraud policy to meet TSC-CC3.3?

You need documented guidance that fraud is considered in risk assessment, but it can be a section within your risk management policy or procedure if it is explicit and testable ¹.

What’s the difference between “fraud risk assessment” and “security risk assessment” for SOC 2?

Security risk assessments often focus on threats and vulnerabilities broadly. CC3.3 expects you to call out intentional deception or misuse scenarios and show control responses tied to those scenarios ¹.

How deep should the fraud scenarios go?

Deep enough that an auditor can trace each scenario to specific controls and evidence of operation. If a scenario cannot be mapped to a control or monitored, rewrite it until it can be tested.

Does this apply to third parties, or only our employees?

It applies to your system and its operations, which includes third parties who have access to your environments, data, or business processes. Include third-party-enabled scenarios and show how access is governed.

What evidence is most persuasive in a SOC 2 audit?

A current fraud risk register with version history, a clear mapping to controls, and meeting minutes or approvals showing periodic review. Add samples that show monitoring and exception handling occurred ¹.

We’re early-stage. Can we keep this lightweight and still pass?

Yes, if it is explicit, scoped, and repeatable. A smaller scenario set with strong linkage and clean evidence often audits better than a long list with no owners or follow-through.

Related compliance topics

• 2025 SEC Marketing Rule Examination Focus Areas
• Access and identity controls
• Access Control (AC)
• Access control and identity discipline
• Access control management

Footnotes

1. AICPA Trust Services Criteria 2017, 2017