CC3 asks you to consider the potential for fraud when assessing risk. For a software company, that means asking how someone inside or outside could misuse access, money or data, then listing the controls that make it harder. A short written assessment, reviewed yearly, is enough to start.
Where fraud shows up in the criteria
The risk assessment group, CC3.1 to CC3.4, covers setting objectives, identifying and analyzing risks, assessing fraud risk and reviewing significant changes. The fraud criterion sits inside your normal risk assessment. It is not a separate program.
Fraud scenarios for software teams
Think about incentive, opportunity and rationalization, then adapt to your business.
- Insider data theft: an employee exports customer data before leaving.
- Privileged misuse: an admin changes records or looks up data for personal reasons.
- Payment fraud: fake vendor invoices, changed bank details, or payroll redirection.
- Customer account takeover through support: a social engineer convinces staff to reset access.
- Code tampering: a malicious change inserted into the product or a dependency.
- Revenue manipulation: pressure to record sales that did not close.
- Credential sale: access offered to outsiders.
Method in four steps
- List scenarios like the above, relevant to you.
- For each, note who could do it, what they would gain and what access they need.
- Rate likelihood and impact on a simple scale.
- Record existing controls and add actions for gaps.
Document the result in the same register as other risks. See the risk assessment worked method.
Controls that map well
- Least privilege and regular access review.
- Logging of admin actions and alerts on bulk data export.
- Approval and call back verification for payment detail changes.
- Support scripts that verify identity before account changes.
- Pull request review and protected branches for code integrity.
- Dependency monitoring and scanning, so a tampered package is more likely to be found.
- Offboarding that removes access the same day.
- A channel to report concerns without retaliation.
Review and change
Revisit the assessment at least yearly and when something significant changes: a new product line, an acquisition, a new payment flow, or an incident. CC3.4 expects you to consider changes that could affect internal control.
Evidence
- The dated assessment with scenarios and ratings.
- Management review or sign off.
- Tickets for resulting actions.
- Examples of the controls operating, such as an access review or a verified payment change.
Safeguard's SBOM and dependency scanning supports the code and dependency integrity item. It does not address financial fraud.
Quick check
Is a separate fraud policy required?
The criteria ask you to assess fraud risk, not to publish a policy. A section in your risk assessment and code of conduct is common.
Do we include customer fraud?
Include it if it can affect your control objectives, such as abuse of your platform. Keep the list focused on your system.
Sources
Last reviewed: 19 October 2026.
