SOC 2 CC3.3: Considering the Potential for Fraud in Risk Assessment

SOC 2 CC3.3 requires an entity to consider the potential for fraud when it assesses risks to its objectives. It sits in the CC3 series (Risk Assessment), and a frequent finding under it is a team that catches fraud in its daily work but has no documented fraud scenarios in the risk assessment, so the one thing an auditor always checks for is missing.

What does SOC 2 CC3.3 require?

CC3.3 is a specific requirement inside the broader risk assessment. It says the entity cannot treat fraud as someone else's problem: the risk assessment carried out under CC3.2 has to explicitly consider how fraud could occur and threaten the objectives. It is one of the few places in the Common Criteria where the standard names a category of risk the assessment must cover by name.

The criterion draws on the fraud triangle. It asks the entity to consider the incentives and pressures that could lead someone to commit fraud, the opportunities created by weak controls, and the attitudes or rationalizations that let people justify it. It also asks the entity to consider various types of fraud, including fraudulent reporting, loss of assets, and corruption, and management's own ability to override controls.

For a technology company the requirement often feels foreign because fraud reads as a banking problem. In practice CC3.3 covers account takeover, abuse of the platform, unauthorized use or disposal of assets, altering records, and misuse of privileged access. The trust services criteria add an explicit point about fraud risks arising from the use of IT and access to information, which is where most SaaS fraud lives.

What are the CC3.3 points of focus?

The AICPA defines 5 points of focus for CC3.3. Because the Trust Services Criteria are AICPA copyrighted material, the points of focus below are paraphrased and grouped by theme rather than reproduced verbatim; consult the official TSC document for exact wording.

• Considers various types of fraud. The assessment covers fraudulent reporting, possible loss of assets, and corruption, across the ways fraud and misconduct can occur.
• Assesses incentives and pressures. The assessment considers the incentives and pressures that could motivate fraud (the first side of the fraud triangle).
• Assesses opportunities. The assessment considers opportunities for unauthorized acquisition, use, or disposal of assets, altering records, or other inappropriate acts (the second side).
• Assesses attitudes and rationalizations. The assessment considers how management or other personnel might engage in or justify inappropriate actions (the third side).
• Considers IT and access-related fraud risk (the trust services addition). The assessment includes internal and external threats and vulnerabilities that arise specifically from the use of IT and access to information.

The first four points come straight from COSO's fraud risk assessment and cover the classic incentive, opportunity, and rationalization structure plus the types of fraud. The fifth is the point added for the trust services criteria, and it is the one that ties fraud risk to the access controls, logging, and monitoring the rest of a SOC 2 program already runs.

How do you meet CC3.3 in cloud environments?

Cloud and SaaS environments meet CC3.3 by naming the fraud scenarios that fit the product and connecting them to the detection already in place:

• Documented fraud scenarios in the risk assessment. Fraud is a named category in the risk register, with a handful of scenarios written down rather than handled only in conversation.
• Platform and account fraud scenarios. Account takeover, credential abuse, payment fraud, and abuse of platform features are assessed where they apply to the product.
• IT and access-driven fraud. Misuse of privileged access, management override of controls, and unauthorized changes to records are assessed as fraud risks, matching the trust services point of focus.
• Detection linked to the scenarios. Existing monitoring, alerting, and anomaly detection are connected to the documented scenarios, so the assessment reflects controls that already run.

A GRC platform does not satisfy CC3.3 on its own. It can hold the fraud scenarios once they are written, but the control is the entity considering how fraud could occur and connecting that to real detection; the platform stores the analysis rather than performing it.

How do you meet CC3.3 on-prem?

On-prem and hybrid environments assess the same fraud triangle with more internal and physical exposure to weigh. The risk management guide for hybrid and on-prem environments covers the surrounding process; the shape is:

• Insider and privileged-access fraud. Small operations teams with broad access raise the opportunity side of the triangle, so privileged misuse and segregation-of-duties limits are assessed directly.
• Physical asset misuse. Unauthorized use or disposal of hardware and physical assets is a fraud scenario when the entity owns the data center or colocation footprint.
• Management override. The risk that management can override controls is named explicitly, since COSO calls it out and auditors expect to see it considered.
• Detection through logging and review. Access logs, change records, and periodic reviews are connected to the fraud scenarios as the detective side of the control.

Fraud detection does not require a sophisticated system on day one. It requires evidence that the entity looks for fraud and has a process for handling it when it appears, which a small team can start with a shared record of what they spot and why.

Cloud vs on-prem at a glance

What evidence do auditors expect for CC3.3?

A SOC 2 risk assessment has to include fraud scenarios explicitly, and auditors check for them by name. A practical target is a small number of documented fraud-specific scenarios inside the wider risk register, ensuring at least two or three of the register's entries address fraud rather than leaving the category empty.

How does CC3.3 map to ISO 27001:2022?

The overlap with ISO 27001 is partial rather than full. ISO 27001 Clause 6.1.2 requires a risk assessment that identifies threats, and fraud can be one of those threat categories, but ISO does not carry a standalone fraud-risk requirement the way SOC 2 does with CC3.3. Organizations pursuing both frameworks can reuse the risk assessment where fraud appears as a threat, while treating the explicit fraud-scenario expectation as SOC 2 net-new. The SOC 2 to ISO 27001 control mapping covers the full crosswalk across all five Trust Services Categories.

Related criteria

CC3.3 is the fraud-specific slice of the risk assessment that CC3.2 runs, so fraud scenarios live in the same risk register as every other analyzed risk. The objectives that fraud threatens are the ones specified under CC3.1. When the business, its systems, or its environment change, new fraud exposures are picked up by the change assessment under CC3.4. The detective side of fraud controls connects to the monitoring and access criteria elsewhere in the Common Criteria.

Frequently Asked Questions

What does SOC 2 CC3.3 mean?

SOC 2 CC3.3 means the entity must explicitly consider the potential for fraud when it assesses risks to its objectives. It draws on the fraud triangle of incentives and pressures, opportunities, and rationalizations, covers fraudulent reporting, loss of assets, and corruption, and adds fraud risks arising from the use of IT and access to information.

What evidence satisfies CC3.3?

The core evidence is a risk assessment that names fraud scenarios explicitly, a documented set of fraud risks, a fraud detection procedure or knowledge base, detection or monitoring records connecting the scenarios to controls, and a code of conduct. Auditors check that fraud appears in the risk assessment by name rather than being left out.

Does SOC 2 require documented fraud scenarios?

Yes. CC3.3 expects fraud to be considered explicitly in the risk assessment, which in practice means documented fraud scenarios in the risk register. A workable target is a small number of fraud-specific entries, ensuring at least two or three of the register's risks address fraud rather than leaving the category empty.

What is the fraud triangle in SOC 2 CC3.3?

The fraud triangle is the three conditions that tend to be present when fraud occurs: incentives or pressures that motivate it, opportunities created by weak controls, and attitudes or rationalizations that let people justify it. CC3.3's points of focus map to all three, plus a trust-services point covering fraud risks from the use of IT and access to information.

How is CC3.3 different from CC3.2?

CC3.2 is the general risk identification and analysis process across the entity. CC3.3 is a specific requirement inside it: the assessment must consider fraud, using the fraud triangle and the types of fraud, including management override. Fraud scenarios end up in the same risk register as every other risk, but CC3.3 is why they have to be there at all.