ISO 27001 A.5.3: Segregation of Duties

Quick Reference (60 Seconds)

Control: A.5.3, Segregation of Duties
Purpose: Prevent fraud, errors, and unauthorized activities by dividing critical tasks among multiple people so that no single person has complete control over a sensitive process.
ISO 27002 attributes: Control type: Preventive · Properties: Confidentiality, Integrity, Availability · Concepts: Protect · Capabilities: Governance, Identity and access management · Domains: Governance and ecosystem
Who it applies to: All organizations with processes involving financial transactions, sensitive data, system administration, or any critical business function where a single person could cause significant harm.
Minimum viable actions:

• Identify critical processes where a single person could cause fraud, errors, or unauthorized access
• Split these processes into separate duties (e.g., requester, approver, executor, reviewer)
• Assign each duty to a different person or role
• Implement technical controls (access controls, workflows, logging) to enforce separation
• Review segregation at a frequency set by risk (many organisations check conflicts with each quarterly access review)

Key deliverables: Segregation of Duties Policy, Critical Process SoD Matrix, Access Control SoD Matrix, Compensating Controls Register, SoD Audit Report.

Audit questions you should be able to answer:

• Which processes have segregation of duties applied?
• How do you prevent a single person from approving and executing their own transactions?
• What compensating controls exist where SoD cannot be implemented?
• How do you audit and review SoD effectiveness?

What the Control Asks For

Do you need this control?

A.5.3 is not mandatory in itself: under clause 6.1.3 you include it if your risk assessment calls for it, and record the decision in your Statement of Applicability. Include it where one person could both commit and conceal an error or fraud, such as raising and approving payments, or writing and deploying code. A very small team may not be able to separate duties fully; then record compensating controls (logging, independent review, approvals) instead of excluding the control.

Annex A 5.3 asks organizations to separate conflicting duties and conflicting areas of responsibility, so no single person can commit or conceal fraud, error, or misuse.

This control requires organizations to:

1. Identify conflicting duties: Find tasks where a single person could both initiate and approve an action, or both create and validate a transaction
2. Segregate responsibilities: Split these duties across different people or roles
3. Implement controls: Use technical and procedural controls to enforce separation
4. Apply compensating controls: Where segregation is not feasible (e.g., small teams), implement compensating controls (supervisory review, logging, audit)
5. Review and audit: Regularly verify that segregation is effective and not being circumvented

What ISO 27002 Recommends (in Our Words)

Decide which duties and areas of responsibility need separating. Typical examples: initiating, approving and executing a change; requesting, approving and implementing access; designing, implementing and reviewing code; developing software and administering production; using and administering applications; using applications and administering databases; and designing, auditing and assuring security controls.

ISO 27002 also asks you to:

• consider collusion when you design the segregation;
• in small organisations, apply segregation as far as practicable, and where it is hard, use other controls such as monitoring, audit trails and management supervision;
• make sure role-based access systems don't give one person conflicting roles, using automated tools to find conflicts where there are many roles;
• define roles carefully so access works when a role is removed or reassigned.

What the Standard Does NOT Require

• The standard does not require SoD for every single task (only for critical or conflicting duties)
• It does not mandate that every organization must have large teams (compensating controls are acceptable for small organizations)
• It does not specify particular technical controls (workflows, access controls, manual checks are all acceptable)
• It does not prohibit a single person from ever having multiple roles (it prohibits the combination of conflicting roles)

Why Segregation of Duties Matters

The Fraud Prevention Principle

Segregation of Duties (SoD) is one of the oldest and most effective internal controls. It is based on a simple principle: no single person should have complete control over a critical process.

When one person can both create and approve a transaction, the risk of fraud, error, and abuse increases dramatically:

• Fraud: A single person can create a fake vendor, approve payment, and transfer funds to themselves
• Errors: A single person can make a mistake that goes undetected because no one else reviews their work
• Unauthorized access: A single administrator can grant themselves access to sensitive data and cover their tracks
• Sabotage: A disgruntled employee can destroy data or systems without oversight
• Data manipulation: A single person can alter financial records to hide theft or misstate performance

The Business Impact of SoD Failures

What public cases show:

• Satyam (2009): the founder admitted inflating cash and profits by about ₹7,000 crore. This was top-management override and collusion, which ordinary segregation of duties rarely stops on its own; the compensating controls are independent board and audit-committee oversight and genuinely independent audit.
• PNB (2018): fraudulent Letters of Undertaking worth about ₹11,400 crore (initial estimate) were issued over SWIFT by bank staff. Maker-checker was defeated by credential sharing, and SWIFT was not integrated or reconciled with the core banking system, so the transactions never showed up in the books.

The Indian Context

Indian organizations face unique SoD challenges:

• SMEs and family businesses: Small teams make traditional SoD difficult; owner-operator models often centralize all authority
• Cost sensitivity: Organizations may avoid hiring additional staff for SoD due to cost constraints
• Rapid growth: Startups scale quickly without formalizing SoD, creating control gaps
• Regulatory intensity: RBI (maker-checker in its IT Governance Master Direction and earlier circulars), SEBI and IRDAI expect segregation of duties for financial and regulated systems
• IT outsourcing: When IT is outsourced, the client and vendor must clearly define SoD boundaries
• Legacy systems: Older systems may lack workflow controls that enforce SoD automatically
• Digital India: Government e-services require SoD but government staffing models may not support it
• DPDP Act 2023: Personal data processing requires clear accountability; SoD gaps in data handling create compliance risk
• Banking sector: RBI's IT Governance Master Direction (2023) and its Cyber Security Framework in Banks (2016) expect segregation of duties for critical banking operations

Scope and Applicability

In Scope

SoD applies to all critical processes where a single person could cause significant harm:

• Financial processes: Payments, invoicing, payroll, expense approvals, financial reporting, vendor management, procurement
• IT administration: User access management, system configuration changes, privilege escalation, backup and recovery, security tool administration
• Data management: Data creation, modification, deletion, backup, restoration, access granting, classification
• Change management: Change request, approval, implementation, testing, deployment
• Security operations: Security monitoring, incident response, forensics, audit log review, vulnerability management
• Development and deployment: Code development, code review, deployment approval, production access
• Procurement and vendor management: Vendor selection, contract approval, payment authorization, vendor access management
• HR processes: Hiring, termination, access provisioning, access revocation, payroll changes
• Physical security: Key management, access card provisioning, alarm management, CCTV access
• Business operations: Order entry, order fulfillment, inventory management, pricing changes, discount approvals

Out of Scope (with caveats)

• Non-critical processes: Routine tasks where a single person's control does not create significant risk (e.g., scheduling a meeting, ordering office supplies below a threshold)
• Single-person organizations: Sole proprietorships where the owner is the only employee (compensating controls apply)
• Emergency situations: Temporary SoD bypasses for emergencies with proper authorization and logging (must be documented and reviewed)
• Automated processes: SoD applies to human oversight of automated processes, not the automation itself (though the automation design should have SoD)

Caveat: Even "non-critical" processes can become critical if they aggregate into significant risk. Regular review is essential.

Applicability by Organization Size

Key Definitions and Terminology

Relationship to Other Controls

Directly Related Controls

Framework Mapping

Implementation Roadmap (Week-by-Week)

Figure · Tiers

Maturity levels for segregation of duties

Phase 1: Assessment and Design (Weeks 1–4)

Week 1: Process Inventory

• Inventory all critical business processes (financial, IT, data, operational)
• Identify processes where a single person could cause significant harm
• Map current process owners and executors
• Identify existing SoD (informal or formal)
• Identify processes with no SoD (single-person control)

Week 2: Risk Assessment

• Assess each critical process for SoD risk (fraud, error, unauthorized access potential)
• Score each process by: financial impact, data sensitivity, regulatory requirement, frequency of activity
• Identify high-risk processes requiring immediate SoD
• Identify medium-risk processes for phased SoD implementation
• Identify low-risk processes where compensating controls are sufficient

Week 3: SoD Design

• For each critical process, design the ideal SoD model (who requests, who approves, who executes, who reviews)
• Identify gaps between current state and ideal state
• Design compensating controls for processes where SoD cannot be fully implemented
• Design workflow rules and system configurations to enforce SoD
• Define exception process for emergency SoD bypasses
• Create the SoD Matrix

Week 4: Policy and Approval

• Draft the Segregation of Duties Policy
• Draft the SoD Matrix and register
• Draft compensating controls documentation
• Define exception approval workflow
• Review with stakeholders (Finance, IT, HR, Operations, Legal)
• Revise based on feedback
• Obtain formal approval from leadership and audit committee

Deliverables: Process inventory, Risk assessment, SoD design, SoD Matrix, Policy draft, Compensating controls register

Phase 2: Pilot Implementation (Weeks 5–8)

Week 5-6: Pilot with Financial Processes

• Select 2-3 financial processes for pilot (e.g., payment approval, vendor onboarding, payroll changes)
• Implement SoD for these processes (workflow, access controls, manual checks)
• Assign roles: requester, approver, executor, reviewer
• Train staff on new SoD processes
• Implement compensating controls for any gaps
• Monitor pilot processes for issues, delays, or workarounds

Week 7-8: Pilot with IT Processes

• Select 2-3 IT processes for pilot (e.g., user access provisioning, system configuration changes, privileged access management)
• Implement SoD for these processes (technical controls, approval workflows, logging)
• Assign roles: requester, approver, implementer, reviewer
• Train IT staff on new SoD processes
• Monitor for technical issues, access conflicts, or workflow failures
• Refine processes based on pilot feedback

Deliverables: Pilot SoD implementation, Training completion, Process refinement, Pilot findings report

Phase 3: Rollout (Weeks 9–14)

Week 9-10: Financial SoD Rollout

• Expand SoD to all financial processes (payments, invoicing, procurement, expense management, financial reporting, payroll, vendor management)
• Implement system workflows (ERP, accounting software, payment systems)
• Configure access controls for financial roles
• Train all finance staff
• Implement automated SoD monitoring for financial systems

Week 11-12: IT and Security SoD Rollout

• Expand SoD to all IT processes (user access management, change management, backup management, security tool administration, privileged access, database administration)
• Configure technical SoD in IAM, AD, cloud platforms, database systems
• Implement SoD in change management tools
• Train all IT staff
• Implement automated SoD monitoring for IT systems

Week 13-14: Operational and Business SoD Rollout

• Expand SoD to operational processes (order management, inventory, pricing, discount approval, HR processes, procurement)
• Implement workflow SoD in business systems (CRM, ERP, HRMS)
• Train business unit staff
• Implement SoD monitoring for business systems
• Address cross-functional SoD (processes spanning multiple departments)

Deliverables: Full SoD rollout, Training completion, System configuration, Monitoring implementation

Phase 4: Optimization (Weeks 15–18)

Week 15-16: SoD Monitoring and Auditing

• Implement continuous SoD monitoring (user access reviews, transaction monitoring, SoD violation detection)
• Conduct first quarterly SoD audit
• Review all SoD exceptions and compensating controls
• Assess SoD effectiveness metrics
• Identify any workarounds or circumventions

Week 17-18: Continuous Improvement

• Update SoD policy based on lessons learned
• Refine SoD Matrix based on process changes
• Enhance compensating controls where needed
• Improve monitoring and detection
• Update training materials
• Plan for annual SoD review and annual audit

Deliverables: SoD monitoring active, First audit complete, Policy updated, Continuous improvement plan

Maturity Model

Detailed Implementation Guidance

The SoD Analysis Framework

Step 1: Identify Critical Processes

Critical Process Categories:

• Financial processes: Accounts payable, accounts receivable, payroll, expense reimbursement, treasury, financial reporting, budgeting, procurement, vendor management, payment processing, invoicing, collections, asset management, inventory valuation, tax reporting, audit coordination
• IT processes: User access provisioning, access revocation, privilege escalation, system configuration, database administration, backup management, security tool administration, change management, patch management, incident response, log review, audit log management, cloud resource provisioning, network changes, firewall rule changes, encryption key management, certificate management
• Data processes: Data creation, data modification, data deletion, data backup, data restoration, data access granting, data classification, data migration, data archival, data destruction, data quality management, master data management
• Operational processes: Order entry, order fulfillment, shipping, inventory management, pricing changes, discount approval, credit limit changes, returns processing, quality assurance, production scheduling, supply chain management, contract management, customer onboarding, customer termination, supplier onboarding
• HR processes: Hiring, termination, salary changes, role changes, access provisioning, access revocation, payroll changes, benefits administration, performance evaluation, background check administration, disciplinary action
• Security processes: Security monitoring, alert response, incident investigation, forensic analysis, vulnerability scanning, penetration testing, audit planning, audit execution, finding remediation, risk assessment, policy approval, exception approval, security tool configuration, key management, certificate issuance, certificate revocation

Step 2: Decompose Each Process into Duties

For each critical process, identify the individual duties that should be separated:

Example: Payment Process

• Duty 1: Create vendor master record (requester)
• Duty 2: Approve vendor master record (approver)
• Duty 3: Create payment request (requester)
• Duty 4: Approve payment request (approver)
• Duty 5: Execute payment (executor)
• Duty 6: Reconcile payment (reviewer)
• Duty 7: Review payment reports (auditor)

Example: User Access Provisioning

• Duty 1: Request access (requester, user or manager)
• Duty 2: Approve access request (approver, data owner or system owner)
• Duty 3: Provision access (executor, IT administrator)
• Duty 4: Verify access (reviewer, security team or user)
• Duty 5: Review access logs (auditor, security or compliance)
• Duty 6: Revoke access upon termination (executor, HR + IT)
• Duty 7: Review access rights quarterly (reviewer, security or data owner)

Example: Change Management

• Duty 1: Request change (requester, business or IT)
• Duty 2: Assess change impact (assessor, security, operations, business)
• Duty 3: Approve change (approver, CAB, system owner, business owner)
• Duty 4: Implement change (implementer, IT or developer)
• Duty 5: Test change (tester, QA or independent tester)
• Duty 6: Approve deployment (deploy approver, system owner or CAB)
• Duty 7: Deploy to production (deployer, IT or DevOps)
• Duty 8: Verify post-deployment (verifier, operations or business)
• Duty 9: Review change logs (auditor, security or compliance)

Step 3: Assign Roles to Duties

SoD Role Assignment Principles:

• No single person should have two conflicting duties (e.g., cannot both request and approve the same transaction)
• No single person should have both execution and review duties for the same process
• No single person should have both creation and validation duties for the same data
• No single person should have both operational and audit duties for the same system
• Management should not approve their own transactions (e.g., a manager should not approve their own expense report)
• IT administrators should not audit their own systems (e.g., a system admin should not review their own access logs)
• Developers should not deploy their own code to production without independent review
• Security team members should not review their own security incidents (another team member should review)

Step 4: Identify SoD Violations

SoD Violation Types:

Step 5: Implement Controls

Technical Controls:

• Role-based access control (RBAC): Define mutually exclusive roles that cannot be assigned to the same user
• Workflow systems: Enforce approval workflows that require different users for each step
• System configuration: Configure systems to prevent a user from both requesting and approving
• Segregated environments: Separate development, testing, and production environments with different access
• Logging and monitoring: Log all transactions and activities for review and audit
• Automated alerts: Alert when a single user attempts to perform conflicting duties
• Dormant account detection: Detect and disable accounts that have not been used, reducing SoD risk from unused access
• Transaction limits: Enforce limits that require additional approval for high-value transactions
• Maker-checker workflows: Require two different users for creation and approval
• Dual authorization: Require two users to approve critical actions (e.g., wire transfers, privilege escalation)
• Split knowledge: Require two people to combine knowledge for critical actions (e.g., encryption key recovery)

Procedural Controls:

• Manual review: A second person reviews and approves paper or electronic documents
• Four-eyes review: Two people must review and sign off on critical actions
• Independent audit: An internal or external auditor reviews transactions and access for SoD compliance
• Management review: Supervisors review and approve transactions performed by their team
• Cross-functional review: A person from a different department reviews transactions
• Periodic access review: Regular review of user access rights to detect SoD violations
• Reconciliation: Independent reconciliation of records (e.g., bank reconciliation by someone not involved in payments)
• Job rotation: Rotate staff through different roles to prevent long-term collusion and detect irregularities
• Mandatory vacation: Require staff to take vacation so that others can review their work
• Surprise audits: Unannounced audits of specific processes to detect SoD violations

Compensating Controls (when SoD is not feasible):

• Supervisory review: A manager reviews all transactions performed by a single person (e.g., in a small team)
• Detailed logging: Extensive logging of all activities with automated anomaly detection
• External audit: Periodic external audit of the process and controls
• Reconciliation: Independent reconciliation of all transactions by a third party or system
• Threshold limits: Transaction limits that trigger automatic review or approval
• Management certification: Management certifies the integrity of the process periodically
• Automated monitoring: Real-time monitoring of all activities for anomalies
• Exception reporting: Automated reports of unusual transactions for management review
• Digital signatures: Requirement for digital signatures that create an audit trail
• Video surveillance: Physical monitoring of personnel performing sensitive tasks

SoD Matrix Template

Organizational SoD Matrix:

Technical SoD Implementation

IAM and RBAC SoD

Active Directory / Azure AD:

• Create mutually exclusive role groups (e.g., "Payment_Requesters" and "Payment_Approvers")
• Configure incompatible-access rules (for example Entra ID Governance access packages with incompatible groups, or SoD rules in an IGA tool) so one user cannot hold both
• Use dynamic groups with exclusion rules
• Implement access reviews that check for SoD violations
• Use Azure AD Access Reviews for periodic SoD validation
• Use Azure AD PIM (Privileged Identity Management) for just-in-time access that limits SoD risk

ERP Systems (SAP, Oracle, NetSuite, Microsoft Dynamics):

• Configure SoD rules in the ERP's access control module
• Use SAP GRC (Governance, Risk, and Compliance) for SoD analysis
• Use Oracle's SoD functionality in Oracle Identity Management
• Configure business roles with SoD constraints
• Use transaction codes and authorization objects to enforce SoD
• Implement workflow rules for approval processes
• Use the ERP's built-in SoD reporting and monitoring

Database Systems:

• Separate database roles: DBA, Schema Owner, Application User, Read-Only User, Backup Operator
• Use database-specific SoD: a user with CREATE USER should not have GRANT ALL PRIVILEGES
• Use row-level security to restrict access based on user roles
• Implement audit policies that log all DBA activities
• Use database vaults (Oracle Database Vault) to enforce SoD at the database level
• Separate backup and restore permissions

Cloud Platforms (AWS, Azure, GCP):

• Use IAM policies to enforce SoD (e.g., separate policies for creation and deletion)
• Use separate AWS accounts and permission sets for conflicting functions; SCPs can deny dangerous actions, but cannot by themselves stop one user holding two roles
• Use Azure RBAC with custom roles that exclude conflicting permissions
• Use GCP IAM with custom roles and resource hierarchies
• Implement AWS Config Rules or Azure Policy to detect SoD violations
• Use cloud-native GRC tools (e.g., AWS Audit Manager, Azure Policy, GCP Security Command Center)
• Use access reviews (e.g. Entra ID Access Reviews) and IGA SoD rule checks; AWS IAM Access Analyzer finds external and unused access rather than SoD conflicts

DevOps and CI/CD:

• Separate developer and deployer roles in CI/CD pipelines
• Use branch protection rules to prevent developers from merging their own code without review
• Require code review approvals from independent reviewers
• Use separate deployment credentials that are not available to developers
• Implement deployment approval gates that require a different person to approve
• Use infrastructure as code (IaC) with separate roles for code creation and deployment
• Use CI/CD pipeline access controls that enforce SoD

SoD Exception Management

When SoD Exceptions Are Allowed:

• Small team size: In organizations with fewer than 5 employees, full SoD may not be feasible
• Emergency situations: Critical security incidents requiring immediate action
• Specialized expertise: Tasks requiring unique skills that only one person has (temporary, with knowledge transfer plan)
• Legacy systems: Systems that cannot technically support SoD (with migration plan)
• Cost constraints: Temporary exceptions with compensating controls and remediation timeline
• M&A integration: During mergers, SoD may be temporarily relaxed with enhanced monitoring
• Key person dependency: When a critical process depends on a single expert (with succession plan)

Exception Approval Process:

1. Request: Process owner submits SoD exception request with justification
2. Risk Assessment: Security team assesses the risk of the exception
3. Compensating Controls: Define specific compensating controls to mitigate risk
4. Approval: Exception approved by CISO (for low/medium risk) or CEO/audit committee (for high risk)
5. Documentation: Exception documented in the SoD Exception Register
6. Time Limit: Exception granted for a specific time period (maximum 12 months, renewable)
7. Monitoring: Enhanced monitoring during the exception period
8. Review: Exception reviewed at expiration; either renewed with updated justification or SoD implemented
9. Audit: All exceptions reviewed during quarterly and annual audits

SoD Exception Register:

SoD Monitoring and Detection

Continuous Monitoring:

• User access review: Quarterly review of all user access rights for SoD violations
• Transaction monitoring: Automated monitoring of transactions for SoD violations (e.g., user approves their own transaction)
• Role assignment monitoring: Alert when a user is assigned conflicting roles
• Privilege escalation monitoring: Alert when a user gains privileges that create SoD conflicts
• Exception monitoring: Track all SoD exceptions and their expiration dates
• Workflow monitoring: Monitor workflow processes for bypasses or workarounds
• Log analysis: Regular analysis of system logs for SoD violations
• Anomaly detection: Use AI/ML to detect unusual patterns that may indicate SoD circumvention

SoD Audit Procedures:

• Quarterly SoD audit: Review all critical processes for SoD compliance
• User access review: Review all user accounts for conflicting roles and permissions
• Transaction sampling: Sample transactions to verify that conflicting duties were not performed by the same person
• Exception review: Review all active SoD exceptions and compensating controls
• System configuration review: Review system configurations to verify SoD enforcement
• Workflow review: Review workflow configurations to verify SoD rules
• Compensating control effectiveness: Test whether compensating controls are effective
• Management inquiry: Interview process owners and staff to verify SoD understanding and compliance

Tools, Technologies, and Solutions

SoD and GRC Platforms

Workflow and BPM Tools for SoD

Indian SoD and GRC Service Providers

Policy and Procedure Templates

Segregation of Duties Policy (Template)

SoD Exception Request Procedure (Template)

Risk Assessment and Treatment

Risk Assessment for SoD

Risk Treatment Options

Audit and Compliance Checklist

Pre-Audit Self-Assessment

Auditor Interview Questions

Be prepared to answer:

1. "Which processes have segregation of duties applied?"
2. "Can you show me your SoD Matrix?"
3. "How do you prevent a single person from approving and executing their own transactions?"
4. "What compensating controls exist where SoD cannot be implemented?"
5. "Can you show me your SoD Exception Register?"
6. "How do you audit and review SoD effectiveness?"
7. "Are system administrators segregated from audit roles?"
8. "How do you enforce SoD in your financial systems?"
9. "Are developers able to deploy code to production without independent review?"
10. "How do you handle SoD in a small team or startup?"

Common Audit Findings and How to Avoid Them

Metrics and KPIs

Process Metrics

Outcome Metrics

Dashboard Sample

┌─────────────────────────────────────────────────────────────────────┐
│           SEGREGATION OF DUTIES DASHBOARD                              │
│                    [Organization] — [Month Year]                        │
├─────────────────────────────────────────────────────────────────────┤
│  SOD COVERAGE: 100%          ██████████████████████  Target: 100%  │
│  SYSTEM ENFORCED: 85%        █████████████████░░░░░░  Target: >80%  │
│  EXCEPTION RATE: 8%          ██████░░░░░░░░░░░░░░░  Target: <10%  │
│  EXCEPTION REVIEW: 100%      ██████████████████████  Target: 100%  │
│  USER ACCESS REVIEW: 100%    ██████████████████████  Target: 100%  │
│  VIOLATION DETECT: 98%       ████████████████████░░  Target: >95%  │
│  VIOLATION REMEDIATION: 36h  ████████████████████░░  Target: <48h  │
│  COMP CONTROL COV: 100%      ██████████████████████  Target: 100%  │
│  COMP CONTROL EFF: 97%       ████████████████████░░  Target: >95%  │
│  BREAK-GLASS: 2%             █░░░░░░░░░░░░░░░░░░░░  Target: <5%   │
│  BREAK-GLASS REVIEW: 100%    ██████████████████████  Target: 100%  │
│  AUDIT FINDINGS: 0           ░░░░░░░░░░░░░░░░░░░░░  Target: 0     │
│  FRAUD INCIDENTS: 0          ░░░░░░░░░░░░░░░░░░░░░  Target: 0     │
│  SOD WORKAROUNDS: 0          ░░░░░░░░░░░░░░░░░░░░░  Target: 0     │
│  TRAINING COMP: 100%         ██████████████████████  Target: 100%  │
└─────────────────────────────────────────────────────────────────────┘

Common Pitfalls and How to Avoid Them

Pitfall 1: "We're Too Small for SoD"

Symptom: Small organization (under 10 employees) believes SoD is impossible and does nothing.

Reality: Small organizations are actually at higher risk for fraud because trust is higher and oversight is lower. A single dishonest employee in a small company can cause catastrophic damage. Compensating controls (owner review, external audit, bank controls) are the solution, not an excuse to do nothing.

Solution:

• Implement compensating controls: supervisory review, external audit, detailed logging, bank reconciliation, threshold limits
• Use external services (bookkeeper, auditor, managed security provider) for independent review
• Implement bank controls (dual signatories, transaction alerts, spending limits)
• Use cloud accounting software with approval workflows even for small teams
• Document all compensating controls and review them regularly

Pitfall 2: "SoD Is Inconvenient and Slows Us Down"

Symptom: Organization implements SoD but staff circumvent it because it creates delays or extra work.

Reality: If SoD is seen as a burden, it will be bypassed. The design of SoD must balance security with operational efficiency. Automation, streamlined workflows, and clear emergency procedures can make SoD efficient.

Solution:

• Automate approval workflows to reduce manual delays
• Set clear approval SLAs (e.g., approve within 24 hours)
• Use mobile approval apps for quick approvals on the go
• Implement delegated approval for absences (with proper authorization)
• Design efficient workflows with parallel processing where possible
• Provide emergency break-glass procedures for urgent situations
• Train staff on why SoD matters (security culture reduces resistance)

Pitfall 3: "We Have SoD on Paper, But Not in Practice"

Symptom: SoD policy exists, but in practice people share credentials, managers approve their own requests, or workflows are bypassed.

Reality: SoD that exists only on paper is worse than no SoD because it creates a false sense of security. Active enforcement, monitoring, and consequences are essential.

Solution:

• Implement system-enforced SoD (workflows that prevent same-user request and approve)
• Use MFA to prevent credential sharing
• Monitor for workflow bypasses and same-user request-approve events
• Conduct surprise audits of transactions
• Enforce consequences for SoD violations
• Regularly review and test SoD controls

Pitfall 4: "The Admin Needs Full Access to Do Their Job"

Symptom: IT administrators are given full admin access to everything "because they need it for troubleshooting."

Reality: No single administrator needs full access to everything all the time. Just-in-time access, privilege escalation workflows, and role-based access can provide admin access when needed while maintaining SoD.

Solution:

• Use Just-in-Time (JIT) access, admin privileges granted for a specific time window for a specific task
• Use Privileged Access Management (PAM) for controlled admin access
• Separate admin roles by system (e.g., network admin vs. database admin vs. application admin)
• Separate admin and audit roles
• Implement admin activity logging to an independent system
• Require approval for privilege escalation
• Regularly review admin access and revoke unnecessary privileges

Pitfall 5: "SoD Exceptions Are Never Reviewed"

Symptom: SoD exceptions are granted and then forgotten, creating permanent gaps in controls.

Reality: Exceptions are temporary by design. Permanent exceptions undermine the entire SoD program. Regular review and renewal (or remediation) are essential.

Solution:

• All exceptions must have expiration dates (maximum 12 months)
• Implement automated alerts for exception expiration (30 days, 15 days, 7 days before expiration)
• Quarterly review of all exceptions by the Security Committee
• Require renewed justification for extension
• Track exception metrics (number of exceptions, average duration, risk trend)
• Escalate long-term exceptions to the CEO or Audit Committee

Pitfall 6: "We Only SoD Financial Processes"

Symptom: SoD is applied only to financial processes, ignoring IT, security, data, and operational processes.

Reality: Financial fraud is one risk, but SoD is equally critical for IT (admin abuse), security (monitoring bypass), data (unauthorized modification), and operations (inventory theft, order manipulation). A complete SoD program covers all critical processes.

Solution:

• Expand SoD to IT processes (user access, change management, backup, security tools)
• Expand SoD to security operations (monitoring vs. administration, incident response vs. investigation)
• Expand SoD to data management (creation vs. validation, backup vs. deletion)
• Expand SoD to operational processes (order entry vs. fulfillment, inventory vs. reconciliation)
• Expand SoD to HR processes (hiring vs. access provisioning, termination vs. access revocation)
• Use the process inventory from the implementation steps above to ensure complete coverage

Pitfall 7: "SoD Is Implemented, But Not Monitored"

Symptom: SoD controls are implemented initially but never monitored for effectiveness, violations, or circumvention.

Reality: SoD controls can degrade over time: new systems are added without SoD, role assignments change creating conflicts, exceptions accumulate, workarounds emerge. Continuous monitoring is essential.

Solution:

• Implement automated SoD monitoring (user access reviews, transaction monitoring, role conflict detection)
• Conduct quarterly SoD audits
• Monitor for workflow bypasses and exceptions
• Use analytics to detect anomalies (e.g., a user who never had approval authority suddenly approving transactions)
• Regularly review system configurations for SoD enforcement
• Include SoD in the internal audit plan annually

Pitfall 8: "SoD Breaks During Emergencies, And We Never Fix It"

Symptom: Emergency break-glass procedures bypass SoD during incidents, but the bypass is never reviewed or the SoD is never restored.

Reality: Emergency procedures are designed for emergencies, not for permanent operation. After the emergency, SoD must be restored, and the break-glass use must be reviewed to ensure it was legitimate.

Solution:

• Emergency break-glass access must be time-limited (e.g., 4 hours)
• All break-glass usage must be logged and automatically alerted to management
• Post-emergency review must be conducted within 24 hours
• Break-glass access must be automatically revoked after the time limit
• If break-glass is used frequently, it indicates a process or system problem that needs fixing
• Annual review of all break-glass usage

Illustrative Scenarios

Illustrative scenario, a composite example for guidance, not a specific Singahi engagement or a verified outcome.

Illustrative Scenario 1: Indian SME, Implementing SoD with Compensating Controls

Organization: A 25-employee manufacturing SME in Pune. Context: Family-run business with no formal SoD. The owner managed all financial approvals. A single accountant handled bookkeeping, invoicing, payments, and bank reconciliation. A single IT person managed all systems, user access, backups, and security. No external audit. No internal controls. Challenge: Implement SoD in a small organization where traditional SoD (multiple people for each duty) is not feasible due to overhead and team size. Need to prevent fraud and errors without adding significant headcount. Approach:

1. Week 1-2: The consultant conducted a SoD risk assessment. Identified critical processes: payments, invoicing, payroll, user access, backups, inventory, procurement. Risk level: High for financial processes, Medium for IT processes.
2. Week 3-4: Designed a compensating control model instead of traditional SoD:
   • Financial Compensating Controls:
     • Bank-level dual authorization for wire transfers above (bank enforces, not internal)
     • Monthly external accountant review of all transactions (outsourced bookkeeper)
     • Owner review and signature on all vendor payments above - Bank reconciliation performed by the external accountant (not the internal accountant)
     • Surprise cash and inventory counts quarterly
     • Digital payment trail (no cash payments above )
     • Expense reimbursement requires receipt + manager approval + owner review
   • IT Compensating Controls:
     • Monthly external IT security review of user access, backups, and changes
     • Backup logs sent to owner's email automatically (owner reviews monthly)
     • Cloud system audit logs reviewed by external consultant quarterly
     • MFA on all admin accounts
     • Admin password in sealed envelope with owner (break-glass only)
     • Quarterly external vulnerability scan
   • Operational Compensating Controls:
     • Inventory counts by external auditor quarterly
     • Order-fulfillment-reconciliation by owner weekly
     • Procurement above requires owner approval
3. Week 5-6: Implemented the compensating controls:
   • Engaged an external accountant for a monthly review
   • Engaged external IT consultant for quarterly security review (/quarter)
   • Configured bank dual authorization for large transfers
   • Set up automated log forwarding to owner email
   • Implemented MFA on all systems
   • Created documented procedures for all compensating controls
4. Week 7-8: Trained all staff on the new controls and why they matter. Trained the owner on how to review the reports and what to look for. Created a simple SoD register documenting all processes, duties, and compensating controls.
5. Week 9-10: Conducted first review:
   • External accountant reviewed first month of transactions, found 2 discrepancies (corrected)
   • External IT consultant reviewed first quarter, found 3 dormant admin accounts (revoked)
   • Owner review found 1 unauthorized expense (addressed through policy reinforcement)
6. Ongoing: Quarterly reviews continue. SoD register updated annually. Owner confidence increased. Bank and investors viewed the controls positively. Results:

• SoD coverage: 100% of critical processes (via compensating controls)
• Discrepancies detected: 5 in first year (all corrected before material impact)
• Fraud incidents: 0
• Owner confidence: "I now sleep better knowing someone else is watching the books and systems"
• Investor due diligence: SoD controls were a positive factor in the next funding round
• Regulatory readiness: Controls met requirements for SME lending and vendor onboarding Key Lesson: Small organizations cannot afford traditional SoD, but they can afford compensating controls. The cost of an external review is small compared with the potential impact of fraud or errors. The key is documenting the controls and executing them consistently.

Illustrative Scenario 2: Indian Bank, Complete SoD Transformation

Organization: A mid-size private bank in India with 500 branches, 3,000 employees, and large total assets. Context: Legacy banking systems with limited SoD capabilities. SoD was primarily manual and paper-based. Multiple instances of the same person handling both loan origination and loan approval. IT administrators had both system access and audit log access. Security team had both monitoring and administration duties. RBI had noted SoD deficiencies in the last inspection. Challenge: Transform SoD across a large, complex organization with legacy systems, diverse processes, and regulatory pressure. Need to automate SoD where possible while managing manual SoD where automation is not feasible. Approach:

1. Phase 1: Assessment (Month 1-2): The consultant conducted a complete SoD assessment across all banking processes: retail banking, corporate banking, treasury, operations, IT, security, HR, procurement. Found: 200+ critical processes, 80+ SoD violations, 45 active SoD exceptions (many expired), no automated SoD, manual SoD heavily reliant on paper forms, legacy core banking system (CBS) had limited SoD workflow capabilities, RBI had 12 findings related to SoD.
2. Phase 2: Design (Month 3-4): Designed a complete SoD program:
   • SoD Matrix: Created a master SoD Matrix covering 200+ processes with defined requester, approver, executor, reviewer, and auditor roles
   • System Enforced SoD: Identified processes where system workflow could enforce SoD (payments, user access, configuration changes, loan processing, trade processing)
   • Manual SoD: Identified processes where manual SoD was required (branch-level operations, customer onboarding, some legacy system tasks)
   • Compensating Controls: Designed compensating controls for 15 processes where neither system nor manual SoD was feasible (legacy system limitations, small branch teams)
   • Exception Management: Designed a formal exception process with approval, time limits, compensating controls, and quarterly review
   • Monitoring: Designed automated monitoring for system-enforced SoD and manual audit procedures for manual SoD
3. Phase 3: System Implementation (Month 5-8): Implemented system-enforced SoD:
   • Core Banking System (CBS): Configured role-based access with SoD rules (e.g., loan officer cannot approve their own loans; teller cannot approve their own cash adjustments)
   • Payment Systems: Implemented dual authorization for wire transfers and NEFT/RTGS above thresholds
   • User Access Management: Implemented IAM system (SailPoint) with SoD rules (e.g., user access requester cannot be the same as approver; admin cannot approve their own access)
   • Change Management: Implemented ServiceNow with approval workflows requiring CAB approval for changes, separate implementer and tester roles
   • Financial Systems: Implemented ERP SoD rules (e.g., accounts payable clerk cannot approve payments; vendor creator cannot approve payments to that vendor)
   • Security Tools: Separated security administration and security monitoring roles in SIEM, firewall, and DLP tools
   • Development and Deployment: Implemented CI/CD with branch protection, code review requirements, and separate deployment approval
4. Phase 4: Manual SoD Implementation (Month 7-9): Implemented manual SoD for processes not covered by systems:
   • Branch Operations: Defined manual SoD procedures (e.g., cash verification by branch manager, not the teller; vault access requires two people)
   • Customer Onboarding: Defined manual SoD (e.g., KYC collected by relationship manager, verified by operations officer, approved by branch manager)
   • Legacy System Tasks: Defined manual SoD checklists and sign-off procedures
   • HR Processes: Defined manual SoD for hiring, termination, and access management (HR initiates, IT implements, manager verifies, security audits)
5. Phase 5: Monitoring and Audit (Month 10-11): Implemented SoD monitoring:
   • Automated SoD violation detection in IAM system (SailPoint)
   • Quarterly user access reviews with SoD violation reports
   • Automated transaction monitoring for same-user request-approve events
   • Monthly SoD dashboard for the CISO and Audit Committee
   • First internal SoD audit conducted
   • RBI inspection readiness review
6. Phase 6: Optimization (Month 12+): Continuous improvement:
   • Quarterly SoD audits
   • Annual SoD policy review
   • SoD metrics tracked and reported monthly
   • Exception register maintained and reviewed quarterly
   • Legacy system upgrade roadmap to enhance system-enforced SoD
   • Branch-level SoD audits conducted quarterly
   • SoD training for all staff conducted annually Results:

• SoD coverage: 100% of 200+ critical processes
• System-enforced SoD: 75% of processes (up from 0%)
• Manual SoD: 15% of processes
• Compensating controls: 10% of processes
• SoD exceptions: Reduced from 45 to 8 (all with documented compensating controls and quarterly review)
• RBI findings: 0 SoD-related findings in the next inspection
• Fraud incidents: 0 internal fraud incidents in 18 months post-implementation
• Audit findings: SoD findings reduced from 12 to 0
• SoD violation detection: 23 violations detected and remediated in first quarter (all were legacy system access issues, corrected)
• Branch compliance: 95% of branches fully compliant with SoD procedures (5% had minor manual procedure gaps, addressed)
• Employee satisfaction: Initial resistance due to workflow changes, but satisfaction improved after automation reduced manual steps Key Lesson: Large organizations with legacy systems can achieve complete SoD by combining system-enforced SoD (where possible), manual SoD (where necessary), and compensating controls (where SoD is not feasible). The key is a systematic approach: inventory, risk assessment, design, implementation, monitoring, and continuous improvement. Regulatory pressure (RBI) can be a catalyst for SoD transformation, but the business value (fraud prevention, error reduction, operational integrity) is the real driver.

Multi-Framework Mapping

NIST SP 800-53 Rev 5 Mapping

COBIT 2019 Mapping

COSO Framework Mapping

SOX Section 404 Mapping

PCI DSS v4.0.1 Mapping

DPDP Act 2023: Relevant Provisions

Regulatory and Industry Context

India

International

Roles and Responsibilities (RACI) for A.5.3 Implementation

RACI Matrix for A.5.3 Implementation

Role Descriptions for A.5.3 Implementation

Documentation and Evidence Requirements

Recommended Documentation

ISO 27001 does not mandate specific documents for this control. If you select it, keep the documented information you need to show it is planned and working (clause 7.5), and set retention in your own retention schedule. Typical records:

Evidence for Audit

Continuous Improvement

Improvement Cycle

Plan → Implement → Measure → Review → Improve

Plan: Set targets for SoD coverage, system enforcement, exception management, violation detection, and audit readiness.

Implement: Deploy SoD policy, matrix, system controls, manual procedures, compensating controls, and monitoring.

Measure: Track KPIs, conduct audits, monitor violations, assess exceptions, and evaluate compensating controls.

Review: Monthly metrics review, quarterly exception review, quarterly access review, annual complete audit, and post-incident review.

Improve: Update policy, refine matrix, enhance system controls, improve monitoring, reduce exceptions, and advance maturity.

Improvement Triggers

Maturity Advancement Path

FAQ

Q1: Can a single person have multiple security roles?

A: Yes, but not conflicting roles. A person can be both a Security Analyst and an Incident Responder (complementary roles). But a person cannot be both a System Administrator and a Security Auditor for the same systems (conflicting roles). The key is conflict, not quantity.

Q2: What if we only have 3 employees? How do we implement SoD?

A: Traditional SoD is not feasible, but compensating controls are. Use: owner review of all transactions, external accountant review, bank dual authorization, automated logging and alerts, quarterly external audit, and threshold limits. Document these controls and review them regularly. The principle is "independent oversight," not "multiple employees."

Q3: Is SoD only for financial processes?

A: No. SoD applies to any critical process where a single person could cause significant harm. This includes IT (user access, change management, backups), security (monitoring vs. administration), data (creation vs. validation), operations (order entry vs. fulfillment), and HR (hiring vs. access provisioning). Financial processes are the most common focus, but complete SoD covers all critical domains.

Q4: What are the most common SoD conflicts in IT?

A: The most common IT SoD conflicts are: (1) System admin + audit log access (admin can cover their tracks), (2) Developer + production deployer (developer can deploy backdoors), (3) Security admin + security monitor (admin can disable monitoring), (4) DBA + backup operator + data access manager (DBA can exfiltrate and delete data), (5) Change requester + change approver + change implementer (same person can make unauthorized changes). Each of these should be separated.

Q5: How do we enforce SoD in a CI/CD pipeline?

A: Use branch protection rules to prevent developers from merging their own code without review. Require code review approvals from independent reviewers. Use separate deployment credentials that are not available to developers. Implement deployment approval gates that require a different person to approve. Use infrastructure as code with separate roles for code creation and deployment. Log all deployments and require independent verification.

Q6: What is a compensating control, and when is it used?

A: A compensating control is an alternative control that reduces risk when traditional SoD cannot be implemented. It is used when: (1) the organization is too small for multiple people, (2) the system cannot technically support SoD, (3) emergency situations require temporary bypass, (4) specialized expertise is available from only one person. Examples: supervisory review, external audit, detailed logging, threshold limits, automated monitoring, and management certification. Compensating controls must be documented, approved, and reviewed regularly.

Q7: How do we handle SoD for third-party vendors and outsourced functions?

A: Include SoD requirements in vendor contracts and SLAs. Define which party (client or vendor) is responsible for each duty. Audit the vendor's SoD during vendor assessments. Require the vendor to report their SoD controls and exceptions. Maintain independent oversight of vendor activities. Do not assume the vendor has SoD, verify it.

Q8: What is the "Four-Eyes Principle," and how does it relate to SoD?

A: The Four-Eyes Principle requires two people to review or approve a critical action. It is a specific form of SoD where two people must be involved (not just different roles). For example, a wire transfer requires two authorized signatories. The principle ensures that no single person can complete a critical action alone. It is commonly used in banking, finance, and critical system changes.

Q9: How do we monitor for SoD violations in real-time?

A: Use IAM tools that detect role conflicts (e.g., SailPoint, Azure AD Access Reviews). Use SIEM rules that alert when a user both requests and approves a transaction. Use transaction monitoring tools that flag same-user request-approve events. Use database audit tools that detect conflicting activities. Implement regular user access reviews (quarterly). Use analytics to detect anomalies in user behavior.

Q10: What should be in a break-glass procedure for emergency SoD bypass?

A: A break-glass procedure should include: (1) Emergency conditions that justify bypass, (2) Authority to approve bypass (e.g., CISO or manager), (3) Time limit for bypass (e.g., 4 hours), (4) Mandatory logging of all bypass activities, (5) Automatic alerts to management when bypass is used, (6) Post-emergency review within 24 hours, (7) Automatic revocation of bypass access after the time limit, (8) Documentation requirements, (9) Consequences for misuse. Break-glass is for emergencies, not for routine convenience.

Q11: How do we handle SoD in a cloud environment (AWS, Azure, GCP)?

A: Cloud environments require cloud-native SoD: (1) Use IAM policies to separate creation and deletion permissions, (2) Use separate accounts or projects for different environments (dev, test, prod), (3) Use AWS SCPs or Azure Policy to prevent certain role combinations, (4) Use cloud-native audit tools (AWS CloudTrail, Azure Monitor, GCP Audit Logs) to monitor for SoD violations, (5) Use cloud-native GRC tools (AWS Audit Manager, Azure Policy, GCP Security Command Center) to assess SoD compliance, (6) Use third-party cloud security tools (e.g., Prisma Cloud, Lacework) for SoD monitoring across cloud resources.

Q12: How do we handle SoD in a DevOps or agile environment?

A: DevOps and agile require "SoD at speed": (1) Automate approval gates in CI/CD pipelines, (2) Use branch protection and mandatory code reviews, (3) Implement automated security testing (SAST, DAST, IaC scanning) as part of the pipeline, (4) Use separate deployment credentials with approval workflows, (5) Use infrastructure as code with version control and peer review, (6) Implement monitoring and alerting for production changes, (7) Use "security champions" within agile teams to provide independent security review, (8) Document emergency procedures for critical hotfixes that require bypass.

Q13: What is the difference between static SoD and dynamic SoD?

A: Static SoD is defined at the role level and enforced through system configuration (e.g., a user cannot be assigned both Role A and Role B). Dynamic SoD is checked at the time of transaction (e.g., a user cannot approve their own request, even if they have both roles). Static SoD is easier to implement but less flexible. Dynamic SoD is more granular but requires more sophisticated system support. Both should be used where possible.

Q14: How do we handle SoD for encryption key management?

A: Encryption key management is a high-risk area for SoD. Best practices: (1) Separate key generation, key distribution, key storage, and key destruction roles, (2) Use Hardware Security Modules (HSMs) with dual control (two people required for key operations), (3) Use split knowledge (two key halves required to reconstruct a key), (4) Use automated key rotation with independent verification, (5) Log all key operations to an immutable audit log, (6) Require management approval for key recovery operations, (7) Never allow a single person to have full control over a master key or root key.

Q15: How do we measure the effectiveness of our SoD program?

A: Track: SoD coverage (percentage of critical processes with SoD), system-enforced SoD rate, exception rate and risk trend, conflicts found by automated scan versus found by audit, violation remediation time, compensating control effectiveness, fraud incidents related to SoD, audit findings related to SoD, and employee understanding of SoD. See Section 13 for a complete KPI framework. The ultimate measure is whether the organization has zero fraud incidents and zero SoD-related audit findings.

References and Further Reading

Standards and Guidelines

1. ISO/IEC 27001:2022: Information Security, Cybersecurity and Privacy Protection, Information Security Management Systems, Requirements. ISO, 2022.
2. ISO/IEC 27002:2022: Information Security, Cybersecurity and Privacy Protection, Information Security Controls. ISO, 2022.
3. NIST SP 800-53 Rev 5: Security and Privacy Controls for Information Systems and Organizations. NIST, 2020.
4. NIST CSF 2.0: Cybersecurity Framework. NIST, 2024.
5. COBIT 2019: Control Objectives for Information and Related Technologies. ISACA, 2019.
6. COSO Framework: Internal Control, Integrated Framework. COSO, 2013.
7. CIS Controls v8: Center for Internet Security, 2021.
8. PCI DSS v4.0: Payment Card Industry Data Security Standard. PCI SSC, 2022.
9. ITIL 4: IT Service Management. AXELOS, 2019.
10. SOX (Sarbanes-Oxley Act): Section 404: Internal Control Over Financial Reporting. US Congress, 2002.
11. Basel Committee on Banking Supervision: Operational Risk Management Guidelines. BIS, 2011.
12. ISACA Standards: Segregation of Duties (various ISACA guidance documents). ISACA, 2023.

Fraud and Internal Controls

13. "Other People's Money: A Study in the Social Psychology of Embezzlement": Donald R. Cressey, Free Press, 1953 (the work behind the later "fraud triangle" model).
14. "Corporate Fraud Handbook: Prevention and Detection": Joseph Wells, Wiley, 2022.
15. "Internal Control Audit and Compliance": Lynford Graham, Wiley, 2015.
16. **"Fraud Analytics: Using Descriptive, Predictive, and Social Network Techniques", Bart Baesens, Wiley, 2015.
17. "The Internal Auditing Handbook": K.H. Spencer Pickett, Wiley, 2020.
18. "ACFE Report to the Nations 2024": Association of Certified Fraud Examiners, 2024.

Access Control and IAM

20. "Privileged Attack Vectors": Morey Haber and Brad Hibbert, Apress, 2020.
21. "SailPoint IdentityNow Documentation": SailPoint, 2024.
22. "Azure AD / Entra ID Documentation": Microsoft, 2024.

Indian Regulatory Resources

23. Digital Personal Data Protection Act 2023: Government of India, 2023.
24. RBI Master Direction on Information Technology Governance, Risk, Controls and Assurance Practices: Reserve Bank of India, 7 November 2023 (in force from 1 April 2024); and RBI Cyber Security Framework in Banks: circular of 2 June 2016.
25. SEBI Cybersecurity and Cyber Resilience Framework (CSCRF) for SEBI Regulated Entities, circular of 20 August 2024.
26. IRDAI Guidelines on Information and Cybersecurity: Insurance Regulatory and Development Authority of India, 2023.
27. IT Act 2000 (as amended): Ministry of Electronics and Information Technology, India.
28. CERT-In Security Guidelines: https://www.cert-in.org.in/
29. MeitY Cybersecurity Guidelines: Ministry of Electronics and Information Technology, India.
30. Companies Act 2013: Ministry of Corporate Affairs, India.
31. Guidance Note on Audit of Internal Financial Controls over Financial Reporting: Institute of Chartered Accountants of India.

Industry Research

32. IBM Cost of a Data Breach Report 2024: IBM Security and Ponemon Institute, 2024.
33. Verizon Data Breach Investigations Report 2024: Verizon, 2024.
34. ACFE Report to the Nations 2024: Association of Certified Fraud Examiners, 2024.