Separation of Duties Under DORA: Maker-Checker Patterns for Financial Workflows
Why Separation of Duties Is a Regulatory Requirement, Not a Best Practice
In financial services, separation of duties is not a security enhancement — it is a governance fundamental. The principle that no single individual should control all phases of a critical process exists to prevent fraud, reduce error propagation, and ensure that decisions with significant consequences receive independent review.
DORA elevates SoD from a general IT governance principle to a specific regulatory obligation. Article 6(4) requires financial entities to ensure that "the ICT risk management function has a sufficient degree of independence" including "appropriate segregation and independence of ICT risk management functions." The EBA's guidelines on ICT and security risk management further specify that "financial institutions should implement adequate segregation of duties to prevent conflicts of interest and to ensure independent oversight."
The practical impact is that every ICT workflow with a governance dimension — change management, incident handling, evidence quality assurance, risk acceptance, vendor onboarding, backup verification — must implement demonstrable SoD controls. And the evidence that these controls are enforced must be captured, archived, and available for supervisory review.
The Maker-Checker Pattern
The maker-checker pattern (also called the four-eyes principle) is the most common implementation of SoD in financial workflows. One actor initiates an action (the maker); a different actor approves it (the checker). The pattern ensures that:
- No single actor can both propose and approve a material change
- Material decisions receive independent review before taking effect
- The approval chain is documented and auditable
SoD Enforcement Levels
DORA's SoD requirements operate at multiple levels:
| Level | SoD requirement | DORA basis | Example |
|---|---|---|---|
| Organizational | ICT risk management independent from operational ICT | Art. 6(4) | CISO reports to CRO, not CTO |
| Functional | Three lines of defense model | Art. 6(8) | Business (1st line), risk (2nd line), audit (3rd line) |
| Workflow | Maker-checker for critical decisions | Art. 5(2), RTS | Change approval, incident classification, evidence QA |
| System | Technical enforcement of role separation | Art. 9(4) | RBAC preventing self-approval in systems |
DORA Workflows Requiring SoD
ICT Change Management (Art. 9(4)(e))
Art. 9(4)(e) requires "sound ICT change management procedures" including "adequate controls, to ensure that changes are implemented in a controlled manner." The ESMA guidelines further specify that change management must include separation between development, testing, and production environments, and between change requestors and change approvers.
SoD enforcement rules for change management:
- The person requesting a change cannot approve it
- The person developing a change cannot deploy it to production
- For critical changes (affecting systems supporting critical functions), two independent approvers from different roles are required
- Emergency changes bypass pre-approval but require post-facto review within 24 hours by an independent reviewer
Incident Classification and Reporting (Art. 17-19)
Incident classification triggers regulatory obligations — a major incident classification starts the 4-hour NCA notification clock. The classification decision must be subject to SoD:
| Workflow step | Maker role | Checker role | SoD rationale |
|---|---|---|---|
| Incident detection and triage | SOC analyst | - | Detection is not a governance decision |
| Severity classification | Incident manager | CISO or deputy | Classification triggers regulatory obligations |
| NCA notification approval | CISO / incident manager | CRO or deputy | Regulatory submission requires independent oversight |
| Root cause assignment | Investigation lead | Independent reviewer | Prevent bias in root cause determination |
| Incident closure | Incident resolver | Incident manager (different person) | Resolver cannot declare their own work complete |
Evidence Quality Assurance (Art. 11, Art. 24-27)
Evidence collected during resilience testing and incident management must pass a quality gate before it is considered audit-ready. The quality gate is a maker-checker process:
- Maker: The person or team that collects or produces the evidence
- Checker: An independent reviewer (typically a different role) who validates the evidence's completeness, accuracy, and integrity
The checker must verify:
- Evidence corresponds to the claimed test or incident
- Evidence is complete (all required artifacts present)
- Evidence integrity is verified (checksums match)
- Evidence classification is appropriate per the data classification scheme
Risk Exception Approval (Art. 6)
When an institution identifies an ICT risk that it cannot mitigate to acceptable levels, Art. 6 requires a formal risk acceptance process. This is one of the highest-stakes maker-checker workflows:
- Maker: Risk owner proposes exception with justification, compensating controls, and expiry date
- First checker: Risk committee reviews proportionality and compensating controls
- Second checker: CISO or CRO validates from a security/compliance perspective
- No eternal waivers: Every exception must have an expiry date and automatic re-review trigger
Third-Party Onboarding (Art. 28-30)
The onboarding of a new ICT third-party provider — particularly one supporting critical functions — requires multiple levels of SoD:
| Onboarding stage | Maker | Checker | Evidence |
|---|---|---|---|
| Vendor assessment | Business owner | Third-party risk team | Assessment scorecard |
| Contract review | Procurement | Legal (Art. 30 compliance) | Gap analysis vs. Art. 30 checklist |
| Security assessment | Vendor self-assessment | Security team validation | Security assessment report |
| Critical vendor activation | Third-party risk team | CRO or management body | Activation approval record |
| Exit strategy validation | Business owner | Risk + Legal joint review | Exit strategy document |
Technical Enforcement
SoD must be enforced technically, not just procedurally. A policy that says "the requestor cannot approve their own change" is meaningless if the system allows it. Technical enforcement requires:
Role-based access control (RBAC): Roles are defined with explicit separation between initiation and approval capabilities. A user with the "change requestor" role cannot hold the "change approver" role for the same scope.
Workflow engine enforcement: The workflow system blocks transitions where the acting user matches the maker. This check is performed in the service layer (never in the UI alone), is validated by automated tests, and the enforcement event is logged.
Conflict detection: For more complex SoD scenarios (a user who holds multiple roles, or who has been temporarily elevated), the system must detect potential conflicts at the point of action — not after the fact.
Audit trail completeness: Every maker-checker interaction must emit an audit event that records: the maker identity, the checker identity, the action, the decision (approved/rejected), the rationale (for rejections), and the timestamp. This is the evidence that supervisors will examine.
The Audit Evidence for SoD
Supervisors do not take assertions of SoD compliance at face value. They examine evidence:
| Evidence type | Content | Retention |
|---|---|---|
| RBAC configuration export | Role definitions, role assignments, segregation rules | Current + annual snapshots |
| Workflow enforcement logs | Every maker-checker decision with identities and timestamps | 10 years |
| Conflict detection logs | Every SoD conflict detected and resolution action | 10 years |
| Access review records | Periodic review of role assignments confirming SoD integrity | 10 years |
| Exception records | Any SoD exceptions with justification, approval, and expiry | 10 years |
This evidence feeds into the Art. 14 board reporting as part of the ICT risk management framework status. The evidence management framework applies: all SoD evidence must be integrity-verified, access-controlled, and retention-managed.
Use the DORA readiness assessment to evaluate your SoD implementation maturity across ICT workflows, and consult the glossary for DORA-specific definitions of governance terms. The RTS/ITS reference provides additional detail on the technical standards for access control and change management.
Common SoD Failures
SoD in policy but not in systems. The policy document specifies maker-checker requirements, but the system allows self-approval. This is the most common finding in supervisory examinations.
Role accumulation. Over time, users accumulate roles that create SoD conflicts. Without periodic access reviews, a single individual may hold both "change requestor" and "change approver" roles — often because they were granted temporary elevation that was never revoked.
Emergency bypass without review. Emergency changes bypass the maker-checker process (acceptable per the emergency change procedure), but the post-facto review never happens. The emergency becomes a permanent SoD exception.
Incomplete audit trail. The maker-checker workflow works correctly, but the audit trail records only the final approval — not the maker identity, not the submission timestamp, not the reviewer's rationale for approval. Without complete evidence, SoD compliance cannot be demonstrated.
Conclusion
Separation of duties under DORA is not an abstract governance principle. It is a specific, enforceable requirement that must be implemented as technical controls in every ICT workflow with governance implications. The maker-checker pattern, the four-eyes principle, and role-based access control are the mechanisms. The audit trail is the proof.
The institutions that implement SoD effectively build it into their systems from the ground up — enforced in code, verified by tests, logged in immutable audit trails, and reported to the management body. The institutions that implement it as policy without technical enforcement will discover the gap during their first supervisory examination.
Resume en francais
Les articles 5 a 7 de DORA et les RTS associes exigent la separation des taches comme principe fondamental de gouvernance TIC. Cet article cartographie les exigences de SoD de DORA vers des modeles de workflow concrets — le modele maker-checker (quatre yeux) pour les decisions critiques, la segregation des roles et les preuves d'audit necessaires pour demontrer la conformite. Les workflows couverts comprennent la gestion des changements TIC (Art. 9(4)(e)), la classification et le signalement des incidents (Art. 17-19), l'assurance qualite des preuves, l'approbation des exceptions de risque et l'onboarding des tiers (Art. 28-30). L'article detaille l'application technique via RBAC, les moteurs de workflow avec verification maker-checker, la detection des conflits et la completude de la piste d'audit. Les echecs courants de SoD incluent la separation dans les politiques mais pas dans les systemes, l'accumulation de roles, les derogations d'urgence sans revue et les pistes d'audit incompletes.