SoD Conflict Review & Compensating Control Procedure
Defines how identified duty conflicts are reviewed, mitigated and evidenced when the organisation is too small to separate the roles.
Available soon
- Format
- Word
- Size
- 62 KB
- Length
- 18 pages
- Version
- 1.0
- Updated
What's inside
- Purpose
- Scope
- Roles
- Triggers and inputs
- Conflict ratings
- Procedure steps
- Compensating control catalogue
- Small organisations — separating duties with few people
- Decision points
- Worked examples
- Outputs and records produced
- Timing targets
- Escalation
- Evidence retained
- Related documents
- Adapting this template
- Framework references
- Definitions
Preview
The document from section 1, as you will receive it. Highlighted [[text]] is for you to replace; shaded guidance boxes are for you to delete before approval. The cover and document control pages are in the file.
Purpose
This procedure sets out how [[Organisation Name]] finds and deals with segregation of duties conflicts: one person holding two duties that should be kept apart, such as setting up a supplier and paying it, or administering a system and reviewing its logs. It is the working routine behind rules SD-01 to SD-07 of the Security Exception & Waiver Standard.
It follows one order every time: separate the duties if you can; if you cannot, put a second person's eyes on the work, prove that it happens, and have the gap approved and reviewed. Most small organisations cannot separate every duty. That is acceptable to an auditor when each conflict is known, rated, covered by a control that someone other than the person in conflict carries out, and reviewed on time.
It answers three questions for every conflict: who found and rated it, what stops one person misusing it, and what evidence shows that control is working.
Scope
This procedure applies to:
- every duty combination listed in the Segregation of Duties Conflict Matrix, in every system named there — typically finance and payments, payroll and HR, purchasing, identity and access administration, IT change and deployment, and security logging and monitoring;
- everyone who holds those duties, including temporary staff, contractors, and the administrators of service providers who run systems for us;
- standing access and emergency or privileged access alike (SD-06).
It does not cover the design of roles in each system ([[role design or access management procedure]]), the approval of ordinary access requests with no conflict ([[access request procedure]]), or the rules for exceptions in general, which are in the Security Exception & Waiver Standard and the Exception Lifecycle Operating Procedure.
Guidance — delete before approval
Keep the systems in scope identical to those in the Segregation of Duties Conflict Matrix. If you add a system to the matrix, it is in scope here from the same day.
Include the service provider's administrators by name or role. A provider engineer who can both change your firewall and delete its logs is a conflict in your organisation, even though they are not your employee.
Roles
Role | What they do in this procedure |
|---|---|
Information security [[e.g. Head of Information Security]] | Owns this procedure and the Segregation of Duties Conflict Matrix (SD-02). Rates conflicts, advises on separation and compensating controls, and assesses exception requests (EX-04). Runs the review schedule (SD-05). |
Access administrator [[e.g. IT service desk, identity team, or the outsourced provider]] | Checks every new or changed access request against the matrix before granting it (SD-03). Does not grant a conflicting combination without a decision from this procedure. |
Control owner / system owner [[e.g. IT Operations Manager]] | Runs the periodic access review for each system in scope, and proposes how a conflict can be separated or mitigated. Makes sure the compensating control runs. |
Line manager [[e.g. the manager of the person in conflict]] | States which duties the person needs. Arranges mandatory leave or rotation where that is the control chosen. |
Independent reviewer [[e.g. finance director, managing director, external accountant, outsourced IT provider]] | Carries out the compensating control: reviews logs or transactions, gives the second approval, or performs the reconciliation. Must not be the person in conflict, and should not report to them. |
Risk owner [[the accountable business executive for the affected service]] | Owns the risk of a conflict that cannot be separated, and signs the exception request. |
Approver for the band (see the Standard, EX-05) | Approves the exception for a conflict that cannot be separated, at the level its score sets (Exception Risk Scoring & Expiry Model). |
Independent reviewer [[e.g. internal audit, or an external reviewer for small organisations]] | Tests, at least once a year, that conflicts in the matrix are found and that the compensating controls ran, using the evidence in SD-07. |
Guidance — delete before approval
One person can hold several roles here, with one exception: the person in conflict can never be the independent reviewer of their own conflict, and should not approve its exception. In a very small organisation, the independent reviewer is often the owner or managing director, a board member, or the external accountant.
Triggers and inputs
When this procedure runs
Trigger | What starts | Steps |
|---|---|---|
A joiner, mover or role change request (SD-03) | The check before access is granted | 1 to 2, then 5 onwards if a conflict is found |
The periodic access review of a system in scope: [[e.g. quarterly for finance and administrator access, six-monthly for others]] | The search for conflicts in existing access | 3 to 4, then 5 onwards |
A conflict's review date falls due (SD-05) | The review of the conflict and its compensating control | 13 to 16 |
Emergency or privileged access is used (SD-06) | The emergency access route | E1 to E5 |
The matrix is updated — annually, and after any restructure or new core system (SD-02) | A check of existing access against the changed matrix | 3 to 4 |
A person leaves, is absent for a long period, or a team shrinks | Checking whether duties have moved onto one person | 3 to 4 |
An audit finding, incident or fraud concern involving combined duties | An immediate search and rating | 3 onwards |
Inputs
Input | Where it comes from | Used for |
|---|---|---|
Conflicting duty combinations, with their default rating | Segregation of Duties Conflict Matrix | Identifying and rating conflicts |
Who holds which roles and permissions in each system | [[User and role exports from each system in scope]] | Finding conflicts in existing access |
Access requests with the duties requested | [[Access request or service desk system]] | The check before granting (SD-03) |
Organisation chart and reporting lines | [[HR system]] | Choosing an independent reviewer |
Open SoD exceptions, controls and review dates | Security Exception Register | Reviews due; controls to check |
Emergency and privileged access logs | [[Privileged access tool, or system logs]] | The emergency access route (SD-06) |
Conflict ratings
Every conflict carries one of three ratings, from the Security Exception & Waiver Standard. The Segregation of Duties Conflict Matrix gives each combination a default rating; information security may raise it for your circumstances, and may lower it only with a recorded reason.
Rating | Meaning | Example | Review of its compensating control (SD-05) |
|---|---|---|---|
High | One person could make and hide an unauthorised change, payment or access grant with no second person seeing it. | Creating a new supplier and releasing payments to it. Administering a server and deleting its security logs. | Quarterly |
Medium | One person could make an unauthorised change that another control would probably, but not certainly, detect later. | Writing code and deploying it to production, where releases are logged and reviewed later. | Every six months |
Low | The combination is undesirable but the damage is small or detected quickly by routine checks. | Raising a purchase order and receiving the goods, for low-value office supplies. | At the annual matrix review (SD-02) |
The rating sets how often the conflict is reviewed and how urgently it must be dealt with. It is not the exception's score: a conflict that cannot be separated is also scored with the Exception Risk Scoring & Expiry Model, which sets who approves it and for how long (step 11).
Procedure steps
Stage 1 — Find conflicts
Conflicts are found in two ways: before access is granted, and in access that already exists.
Step | What happens | Who | Output |
|---|---|---|---|
1 | Before granting new or changed access, compare the duties requested, and those the person already holds, with the Segregation of Duties Conflict Matrix (SD-03). Include access the person holds in other systems — the conflict is often across two systems. | Access administrator | Request cleared, or conflict flagged |
2 | If the request creates a conflict, do not grant the conflicting part. Send the request to the system owner and information security with the conflict identified. Grant the rest of the request. | Access administrator | Conflict referred; non-conflicting access granted |
3 | At each periodic access review, export users and roles from each system in scope and run them against the matrix. Include service provider accounts, shared accounts and accounts with emergency or administrator rights. | System owner; information security | List of conflicts in existing access |
4 | Record each conflict found in the [[conflict log, or the Security Exception Register]]: person, systems, duties combined, date found, how found. | Information security | Conflict recorded |
Guidance — delete before approval
A spreadsheet is enough for step 3 in most small organisations: one sheet of who holds what, one of the conflicting pairs from the matrix, and a lookup. The discipline is in running it every time, not in the tool.
Look for conflicts created by absence. When a colleague leaves or is off long-term, their duties often move quietly to the one person who should not hold them.
Stage 2 — Rate
Step | What happens | Who | Output |
|---|---|---|---|
5 | Rate the conflict High, Medium or Low, starting from the matrix default. Raise it if, in your organisation, one person could act and hide it (for example, no one else ever sees the bank statements). Record the reason for any change from the default. | Information security, with the system owner | Rating and reason |
6 | A new High conflict with no control in place is reported to the risk owner and the line manager within [[2 working days]], with an interim measure agreed straight away — for example, a second person checking every payment until step 10 is complete. | Information security | Interim measure recorded |
Stage 3 — Separate if you can
Separation is always tried first. It removes the conflict rather than watching it, and it needs no exception.
Step | What happens | Who | Output |
|---|---|---|---|
7 | Look for a way to separate the duties, in this order: remove the access the person does not truly need; reassign one duty to someone else; split the workflow in the system so a second person must act (for example, the system or bank requires a second approver); move one duty to a service provider or external party. | System owner; line manager; information security | Separation option chosen, or reasons none works |
8 | If a separation is possible, make the change, confirm it in the system (a fresh export or screenshot), and close the conflict in the log. If separation cannot be completed within [[5 working days]] of finding the conflict, raise an exception request now (EX-01, step 11), with the separation as its remediation plan. If separation is not possible at all, record why — cost, headcount, system limitation — and go to Stage 4. | System owner | Conflict closed, or reasons recorded |
Guidance — delete before approval
Workflow controls built into systems are the cheapest separation available to a small organisation. Most banks offer dual authorisation of payments; most accounting, source-code and cloud platforms can require a second approver for changes. Switch these on before designing a manual review.
Stage 4 — Mitigate what cannot be separated
Step | What happens | Who | Output |
|---|---|---|---|
9 | Choose one or more compensating controls from the catalogue in the next section. Each must be carried out by someone other than the person in conflict, at a stated frequency, and leave evidence. | System owner; information security | Control design: who, what, how often, evidence |
10 | Run the control once and keep the evidence, so that it is tested before the exception is approved (EX-07). A control that has not yet run is listed on the request, but does not lower the score. | Independent reviewer | First evidence of the control |
11 | Within [[5 working days]] of finding the conflict (EX-01), request an exception on the Security Exception Request & Approval Form (SD-04). Information security scores it with the Exception Risk Scoring & Expiry Model; the score's band sets the approver and the longest duration. Record it in the Security Exception Register. | System owner as requester; information security | Exception request, scored |
12 | The approver for the band decides. An approved conflict keeps its access; a refused one is separated (step 7) by the date the approver sets. | Approver for the band | Decision; register updated |
Guidance — delete before approval
A conflict that will last as long as the organisation stays this size is still an exception with an expiry date. At each expiry it is scored again and renewed; when its renewals run out it goes to the next approval level (EX-08) and appears as a chronic exception in the management report. That is deliberate: management should see, at least once a year, the duties it has chosen not to separate.
Stage 5 — Review
Each conflict is reviewed at its rating's frequency (SD-05): High quarterly, Medium every six months, Low at the annual matrix review (SD-02).
Step | What happens | Who | Output |
|---|---|---|---|
13 | Collect the evidence that the compensating control ran every time it should have since the last review: signed reviews, alert records, second approvals, reconciliations. | Information security | Evidence pack for the review |
14 | Check that the control is still effective: the right person performed it, they looked at the right data (pulled by themselves, not supplied by the person in conflict), and anything unusual was followed up. | Information security; independent reviewer | Review record |
15 | Check that the conflict is still needed: can the duties now be separated — new staff, new system features, a provider? If yes, go to step 7. | System owner; information security | Decision: keep, or separate |
16 | Record the result and the next review date. A control that missed a run, or was performed by the person in conflict, is a failed control: the exception is scored again at once without it (SM-07 in the Exception Risk Scoring & Expiry Model), and the conflict is reported to the risk owner. | Information security | Register updated; failures reported |
Emergency and privileged access
Emergency ("break-glass") and privileged access often creates a conflict for a short time by design. It is allowed without a prior exception only under these conditions (SD-06).
Step | What happens | Who | Output |
|---|---|---|---|
E1 | Emergency accounts are named in advance, with credentials held so that use is visible — [[e.g. sealed envelope in the safe, a password vault that alerts on checkout]]. Privileged rights for normal work are granted for a limited time, [[e.g. up to 8 hours]], rather than held permanently where the system allows. | Access administrator; information security | List of emergency and privileged accounts |
E2 | Every use is logged automatically, and an alert goes to someone other than the user — [[e.g. the Head of Information Security and the outsourced provider]]. | Access administrator | Alert on use |
E3 | The user records why the access was used and what was done, the same day. | User of the emergency access | Reason and actions recorded |
E4 | Someone other than the user reviews the log of what was done within [[2 working days]], and confirms it matches the stated reason. | Independent reviewer | Signed review |
E5 | Credentials are changed after each emergency use, and temporary rights are confirmed removed. | Access administrator | Credential change recorded |
Privileged accounts that hold a conflicting combination permanently — for example, a sole administrator — are not emergency access. They follow Stages 1 to 5 like any other conflict, and are normally rated High.
Compensating control catalogue
Choose the control that would catch the misuse the conflict allows. Prefer a control that prevents (a second approval) over one that detects later (a review), and one generated by the system over one that depends on memory.
Control | What it catches | Minimum design | Evidence | Works in a small organisation when… |
|---|---|---|---|---|
Independent review of logs or transactions | Changes, payments or access grants made by the person in conflict | Reviewer pulls the report themselves from the system; covers every relevant event since the last review; signs and dates it; follows up anything unexplained | The report, with reviewer's signature or approval and date; notes of follow-up | The owner, a director or the external accountant spends [[30 minutes a month]] on a report the system produces |
Dual approval | A single person completing a transaction alone | The system enforces a second approver who is not the initiator; cannot be bypassed by the initiator | System configuration export; sample of approvals showing two different people | The bank, accounting or code platform already offers it — switch it on |
Mandatory leave or rotation | Concealment that needs the person's daily presence (for example, teeming and lading) | At least [[5 consecutive working days]] a year away from the duties, with no remote access to them, while someone else performs them | Leave record; confirmation from the stand-in of what they did and found | Someone can cover the duties for a week — often a provider or a manager |
Automated alerts | High-risk actions as they happen: new supplier bank details, admin group changes, log deletion or logging stopped | Alert goes to someone other than the person in conflict; cannot be switched off by them; tested | Alert rule configuration; test alert record; alert history | Logs are sent to a service the administrator cannot alter, and alerts go to a director or the provider |
Periodic reconciliation by someone else | Differences between what should be and what is: payroll to headcount, supplier payments to invoices, users to staff list | Performed by someone independent, from source records they obtain themselves, at a set frequency | Signed reconciliation with differences explained | An external accountant or bookkeeper already reconciles monthly — add the check to their scope |
Guidance — delete before approval
The most common failure of a compensating control is that the reviewer looks at a report prepared by the person being reviewed. The reviewer must obtain the data themselves, or receive it directly from the system.
A review that never finds anything is not proof that it works. Once a year, ask the independent reviewer to walk through one real item from start to finish with information security.
Small organisations — separating duties with few people
In a team of two or three, most conflicts cannot be separated internally. They can almost always be covered. These patterns work in practice:
- Use people outside the team. The owner or managing director, a non-executive director, the external accountant or the outsourced IT provider can each be the independent reviewer. They need access to reports, not to the systems.
- Use controls the bank and the software already have. Dual authorisation of payments, approval rules in the accounting system, required reviews in the code repository, and alerts in the cloud administration console cost nothing.
- Send the evidence somewhere the person in conflict cannot change it. Forward logs to a service where the administrator has read-only access; have bank statements sent directly to the reviewer.
- Keep reviews short and regular. A fixed 30-minute slot each month or quarter, with the report already in the reviewer's inbox, happens. An open-ended "review of everything" does not.
- Record the conflicts you have accepted. An auditor will not expect a ten-person company to separate every duty. They will expect it to know which duties are combined, and to show that someone checked.
Decision points
Decision | Who decides | Rule | Recorded in |
|---|---|---|---|
Is this a conflict? | Information security, using the matrix | A combination listed in the Segregation of Duties Conflict Matrix, or one information security adds to it | Conflict log |
What is its rating? | Information security, with the system owner | Matrix default; raised for context; lowered only with a recorded reason | Conflict log |
Can it be separated? | System owner, with information security | Separation is tried first (step 7); the reason it is not possible is recorded | Conflict log |
Which compensating control? | System owner proposes; information security agrees | Performed by someone independent; tested before the request (EX-07) | Exception request |
May the conflict stay? | The approver for the exception's band | The Exception Risk Scoring & Expiry Model sets the approver and longest duration (EX-05, EX-06) | Security Exception Register |
Has the control failed? | Information security | A missed run or a non-independent performer is a failure (step 16) | Register; report to risk owner |
Worked examples
The organisations, people and systems are illustrative. The exception scores are calculated with the model's rules.
Example 1 — supplier set-up and payment at a 12-person firm
Step | The finance manager can add suppliers, change their bank details and prepare payments |
|---|---|
Found | At the quarterly access review of the accounting system and the bank portal (step 3). |
Rated | High — one person could redirect a payment to their own account and no one else would see it (matrix default). |
Separated? | In part. The bank's dual authorisation was switched on: every payment now needs the managing director's approval in the bank portal (step 7). But the finance manager still changes supplier bank details alone, and the managing director approves what the payment run shows. |
Mitigated | Automated alert to the managing director on every change of supplier bank details, and a monthly report of changes pulled by the managing director from the accounting system, checked against the call-back record. Run once in September before the request (step 10). |
Scored | The payment system is Critical, and fraudsters target finance staff's email to change supplier bank details, so one compromised account is enough. Impact 3 Major; likelihood 3 Likely, lowered to 2 by the tested control (EX-07). Score 3 × 2 = 6 → Medium: approved by the Head of Information Security, for up to 180 days. |
Reviewed | Quarterly, as a High conflict: the managing director's signed monthly reports and the alert history are checked. |
Example 2 — the only IT administrator also manages the security logs
Step | A 30-person company has one IT administrator, with full administrator rights and control of the logging system |
|---|---|
Found | When the matrix was first applied (step 3). |
Rated | High — the administrator could make an unauthorised change and delete the record of it. |
Separated? | No: there is one administrator. Recorded reason: headcount. |
Mitigated | Logs forwarded to a cloud log service where the administrator has read-only rights; alerts on changes to administrator groups, and on logging stopping, go to the outsourced IT provider and the managing director; the provider reviews a summary of administrator activity monthly. The test alert on [[date]] reached both. |
Scored | Misuse could hide a compromise of every system; it needs insider access. Impact 4 Severe; likelihood 2 Possible, lowered to 1 by the tested control (EX-07). Score 4 × 1 = 4 → Medium: approved by the Head of Information Security, for up to 180 days. The administrator also holds the information security role, so is not independent: the Standard names [[the managing director]] to approve in that role. |
Reviewed | Quarterly. At each review, information security — here, the provider — confirms the alerts still fire and the monthly reviews happened. |
Example 3 — developers who deploy their own code
Step | Four developers can each write code and deploy it to the production system |
|---|---|
Found | At the six-monthly review of the source-code platform (step 3). |
Rated | Medium — a developer could deploy an unauthorised change, which the release log would probably, but not certainly, show later. |
Separated? | Yes. The code platform was set to require one other developer's approval before any change reaches the main branch, and only the main branch can be deployed. A fresh settings export confirmed it (step 8). |
Result | Conflict closed. No exception needed. The emergency fix route that bypasses review was added to the emergency access list (E1). |
Example 4 — payroll run by one person
Step | The HR administrator adds new employees and prepares the monthly payroll |
|---|---|
Found | When a colleague left and her duties moved to the HR administrator. |
Rated | Medium — a fictitious employee could be paid; the finance director's review of payroll totals would probably, but not certainly, notice. |
Separated? | No: no second HR person until [[date]]. |
Mitigated | The external accountant reconciles payroll to the headcount list each month, using the HR system report sent to them directly; the HR administrator takes [[5 consecutive working days]] of leave a year during which the accountant runs payroll. |
Scored | Payroll holds personal data and moves money; misuse needs insider access. Impact 3 Major; likelihood 2 Possible, lowered to 1 by the tested control (EX-07). Score 3 × 1 = 3 → Low: approved by control owner, for up to 365 days. |
Reviewed | Every six months. Separated once the new HR assistant starts (step 15). |
Outputs and records produced
Output | Produced at step | Held in | Maintained by |
|---|---|---|---|
Access requests checked against the matrix | 1, 2 | [[Access request system]] | Access administrator |
Conflict log: person, systems, duties, rating, date found, decision | 4 to 8 | [[Conflict log, or the Security Exception Register]] | Information security |
Separation evidence: export or screenshot after the change | 8 | Conflict log | System owner |
Exception requests and decisions for conflicts not separated | 11, 12 | Security Exception Request & Approval Form; Security Exception Register | Information security |
Compensating control evidence: signed reviews, approvals, alerts, reconciliations | 10, 13 | [[Evidence location]] | Independent reviewer |
Review records | 14 to 16 | Security Exception Register | Information security |
Emergency access records: reason, actions, review, credential change | E1 to E5 | [[Privileged access tool or log]] | Access administrator |
These records feed the quarterly management report (EX-12). Its headline number for this procedure is unmitigated SoD conflicts: known High conflicts with no compensating control recorded and reviewed in the last quarter. Target: zero.
Timing targets
Activity | Target | Basis |
|---|---|---|
Check a request against the matrix | Before access is granted | Standard SD-03 |
Report a new High conflict with no control, and agree an interim measure | Within [[2 working days]] of finding it | This procedure |
Separate, or raise an exception request | Within [[5 working days]] of finding the conflict; a longer separation plan can follow inside the exception | Standard EX-01 |
Decide the exception | Within the band's decision time (working days from a complete request) | Standard EX-05 |
Review a High conflict and its control | Quarterly | Standard SD-05 |
Review a Medium conflict and its control | Every six months | Standard SD-05 |
Review a Low conflict | At the annual matrix review (SD-02) | Standard SD-02, SD-05 |
Review the matrix itself | Annually, and after any restructure or new core system | Standard SD-02 |
Review emergency access use | Within [[2 working days]] of use | Standard SD-06; this procedure |
Guidance — delete before approval
Targets marked "This procedure" are not in the Standard. You may change them, but keep the 'report and interim measure' target short: a High conflict with nothing in place is exactly the gap a fraud uses.
Escalation
When | Escalated to | By |
|---|---|---|
A conflict is neither separated nor raised as an exception request within [[5 working days]] (EX-01), or a High conflict has no compensating control at the time of the request | Risk owner and the approver for the High band; counted in the quarterly report | Information security |
A compensating control missed a run, or was performed by the person in conflict | Risk owner; exception scored again (step 16) | Information security |
A conflicting access was granted without the check in step 1 | Access administrator's manager; access removed or conflict processed within [[5 working days]] | Information security |
Emergency access used without a stated reason, or not reviewed | Head of Information Security; treated as a possible security incident | Independent reviewer |
Signs that a conflict has been misused | [[Incident Management Procedure]] and [[fraud response or whistleblowing route]] | Anyone |
Evidence retained
Keep the following so an auditor can follow any conflict from discovery to its latest review (SD-07). Retention should match the Records section of the Security Exception & Waiver Standard.
Evidence | Shows | Minimum retention |
|---|---|---|
The matrix, with its review history | Conflicts are defined and kept current (SD-02) | [[3 years]] |
Access requests with the matrix check | Conflicts are caught before access is granted (SD-03) | [[3 years]] |
Access review exports and the conflict log | Existing conflicts are found and rated | [[3 years]] |
Exception requests and approvals | Conflicts not separated are approved at the right level (SD-04) | [[3 years after expiry]] |
Compensating control evidence | Controls ran, independently, at their frequency | [[3 years]] |
Review records | Conflicts are reviewed on time (SD-05) | [[3 years]] |
Emergency access records | Emergency use is justified and reviewed (SD-06) | [[3 years]] |
Guidance — delete before approval
An auditor will typically pick two or three conflicts and ask to see: when each was found, who rated it, why it was not separated, who approved it, and the last three runs of its compensating control. Test this yourself once a quarter.
Related documents
Document | Relationship |
|---|---|
Security Exception & Waiver Standard | The rules this procedure runs: SD-01 to SD-07, and the exception rules EX-01 to EX-13 |
Segregation of Duties Conflict Matrix | The conflicting combinations and their default ratings |
Security Exception Request & Approval Form | How a conflict that cannot be separated is requested and approved |
Exception Risk Scoring & Expiry Model | How that exception is scored, and what its band sets |
Security Exception Register | Where approved conflicts, their controls and review dates are recorded |
Exception & SoD Responsibility Matrix | Who requests, assesses, approves and reviews |
[[Access Control Policy]] and [[access request procedure]] | How access is requested, granted and reviewed generally |
Adapting this template
Guidance — delete before approval
Small organisation: this procedure is written for you. Expect to separate few duties and mitigate most. Name the independent reviewers now — owner, director, external accountant, IT provider — and agree the time each will give. Use the bank's and the software's built-in approval controls first. Review High conflicts quarterly and Medium ones every six months, and combine the reviews into one short meeting.
Regulated entity (NIS2, DORA): DORA expects the ICT risk control function to be independent enough to avoid conflicts of interest, and its technical standards expect segregation of duties in both ICT security policies and access control. Add to the matrix the separation of ICT operations, ICT risk control and internal audit, and include in the evidence how those functions are kept apart. Keep records for the period your regulator expects.
IT run by a service provider: include the provider's administrators in the matrix and the access review. Require the provider to operate a matrix check for its own staff on your systems, and to give you user exports for step 3. The provider can also be your independent reviewer for conflicts inside your own staff — but never for conflicts held by its own engineers.
Delete this section before approval.
Framework references
These references show where this document supports an external framework. They indicate relevance only and do not reproduce the text of any standard. Editions referenced: ISO/IEC 27001:2022 incl. Amd 1:2024; NIST CSF 2.0; Directive (EU) 2022/2555 (NIS2); Regulation (EU) 2022/2554 (DORA); Delegated Regulation (EU) 2024/1774.
Framework | Reference | Supported by |
|---|---|---|
ISO/IEC 27001:2022 | Annex A 5.3 — Segregation of duties | Whole procedure |
ISO/IEC 27001:2022 | Annex A 5.15 — Access control | Stage 1: checks before access is granted |
ISO/IEC 27001:2022 | Annex A 5.18 — Access rights | Stage 1: access reviews; emergency and privileged access |
NIST CSF 2.0 | PR.AA-05 — “Access permissions, entitlements, and authorizations are defined in a policy, managed, enforced, and reviewed, and incorporate the principles of least privilege and separation of duties” | Stages 1 to 5 |
NIS2 — Directive (EU) 2022/2555 | Article 21(2)(i) — “human resources security, access control policies and asset management” | Whole procedure |
DORA — Regulation (EU) 2022/2554 | Article 6(4) — a control function for ICT risk, independent enough to avoid conflicts of interest, and segregation of ICT risk management, control and internal audit functions | Adapting this template: regulated entity |
DORA — Delegated Regulation (EU) 2024/1774 | Article 21(b) — an access control policy with segregation of duties that prevents combinations of access rights able to circumvent controls | Stage 1; conflict ratings; emergency and privileged access |
DORA — Delegated Regulation (EU) 2024/1774 | Article 2(2)(g) — ICT security policies specify segregation-of-duties arrangements to avoid conflicts of interest | Whole procedure |
Definitions
Term | Meaning in this procedure |
|---|---|
Compensating control | A measure, carried out by someone other than the person in conflict, that would prevent or detect misuse of the combined duties. |
Conflict | One person holding two or more duties, listed in the matrix, that should be kept apart. |
Dual approval | A transaction or change that the system will not complete until a second, different person approves it. |
Emergency ("break-glass") access | An account or right, held in reserve, used only when normal access cannot resolve an urgent problem. |
Independent reviewer | A person who carries out a compensating control and is neither the person in conflict nor someone who reports to them. |
Mandatory leave | A period of consecutive days when a person is away from their duties, with no remote access to them, while someone else performs them. |
Privileged access | Rights to administer a system, change its security settings, or see or change all of its data. |
Segregation of duties (SoD) | Dividing duties between people so that no one person can carry out and conceal an unauthorised action. |
Separation | Removing a conflict by taking away access, reassigning a duty, or making the system require a second person. |