Your risk assessment explicitly considers insider threat and fraud scenarios, not just external attackers. This means thinking about what a malicious or negligent employee could do with their access, unauthorized data export, financial fraud, sabotage of production systems. The fraud risk section does not need to be elaborate, but it must be explicitly addressed in the risk register.
These are typical controls and implementation steps. Your systems and environment may differ.
Typical Control Fraud risk scenarios documented in the risk register
Implementation Steps
Add a fraud risk category to your risk register with at least 2-3 explicit scenarios: unauthorized data exfiltration by an employee, abuse of privileged access to modify financial records, collusion between employees to bypass segregation of duties controls
For each fraud risk, document the existing controls that mitigate it (access reviews, segregation of duties, logging of privileged activity) and any residual risk
Assess fraud risk separately for each role with privileged access, the fraud exposure of a read-only analyst is different from a production database admin
Review fraud risks annually as part of the standard risk assessment cycle; also revisit when roles change significantly
Typical Control Fraud risk scenarios documented in the risk register
Evidence Artifacts
Risk register showing a fraud risk category with specific scenarios, ratings, and mitigating controls
Annual risk assessment document confirming fraud risks were considered
Privileged access logging configuration showing that high-risk role activity is being monitored
📅Annual; risk register updated on role changes or incidents involving insider activity
Cross-framework mappings coming in v1.1
When we add ISO 42001 and ISO 27001, you'll see which controls map to this criterion.
ISO
ISO 42001
AI Management Systems
ISO
ISO 27001
Information Security
Mapping data will appear here automatically when the frameworks are published.
CC3.4
Identifies and assesses significant changes
Risk Assessment
3 evidence1 control
CC4.1
Selects, develops, and performs ongoing and separate evaluations
Monitoring Activities
6 evidence2 controls
CC4.2
Evaluates and communicates internal control deficiencies
Monitoring Activities
3 evidence1 control
CC5.1
Selects and develops control activities that mitigate risks
Control Activities
3 evidence1 control
CC5.2
Selects and develops general controls over technology
Control Activities
6 evidence2 controls
CC5.3
Deploys control activities through policies and procedures
Control Activities
3 evidence1 control
CC6.1
Logical access security infrastructure
Logical and Physical Access Controls
11 evidence3 controls
CC6.2
Registration and authorization prior to issuing credentials
Logical and Physical Access Controls
6 evidence2 controls
CC6.3
Role-based access management
Logical and Physical Access Controls
6 evidence2 controls
CC6.4
Physical access restrictions
Logical and Physical Access Controls
3 evidence1 control
CC6.5
Disposal and destruction of information assets
Logical and Physical Access Controls
3 evidence1 control
CC6.6
Controls against threats from outside system boundaries
Logical and Physical Access Controls
8 evidence2 controls
CC6.7
Restricts transmission and movement of information
Logical and Physical Access Controls
7 evidence2 controls
CC6.8
Controls to prevent or detect unauthorized software
Logical and Physical Access Controls
6 evidence2 controls
CC7.1
Detection and monitoring for vulnerabilities
System Operations
8 evidence2 controls
CC7.2
Monitoring for anomalies and security events
System Operations
4 evidence1 control
CC7.3
Evaluation of security events as security incidents
System Operations
4 evidence1 control
CC7.4
Incident response program
System Operations
4 evidence1 control
CC7.5
Recovery from security incidents
System Operations
4 evidence1 control
CC8.1
Authorized change management process
Change Management
8 evidence2 controls
CC9.1
Risk mitigation for business disruptions
Risk Mitigation
4 evidence1 control
CC9.2
Vendor and business partner risk management
Risk Mitigation
4 evidence1 control
Help us build what matters.
Vote for the next framework, subscribe for updates, and let us know if you'd contribute.
What should we add next?
Vote for the framework you need most.
0
ISO 42001
0
ISO 27001
0
CMMC
0
CPCSC
Stay Updated
Get notified when new frameworks and features are added.
On-premises implementation and evidence
Fraud risk scenarios documented in the risk register
Implementation steps
Include a fraud risk section in the annual risk assessment; identify the roles with the highest fraud exposure (privileged system access, financial system access)
Document the controls that reduce fraud risk: segregation of duties (no single person can both approve and execute a sensitive action), privileged access logging via your SIEM/monitoring platform, periodic access reviews
Ensure that audit log tampering is a documented fraud risk, confirm that log integrity controls are in place (your SIEM/monitoring platform immutable logging, your IDS/network monitoring platform log forwarding to an isolated store)
Tools / systems
Wazuh (privileged access logging and log integrity)
Security Onion (IDS and log management)
Work order system (segregation of duties enforcement)
GRC platform (e.g., Vanta, Drata, your GRC platform, Scrut)
Evidence artifacts
Risk register with fraud risk section showing scenario, likelihood, impact, and mitigating controls
Wazuh or SIEM configuration showing privileged account activity logging is enabled
Segregation of duties documentation confirming approval and execution are separated for sensitive actions
