A.5.3 Segregation of duties: requirements and evidence

What A.5.3 segregation of duties asks you to separate

A.5.3 asks you to separate conflicting duties and conflicting areas of responsibility so that no single person can commit fraud, make an error that goes unnoticed, or bypass an information security control on their own. The question an auditor or a customer questionnaire usually puts in practice is simple: who can approve a change, a payment or a access grant, and can the same person also request, execute or record it? If the honest answer is yes and nobody else checks the result, the control is not met. The control belongs to the organizational controls theme, and it carries forward control A.6.1.2 from the 2013 edition, so organizations that already had a segregation of duties control in their 2013 ISMS will mostly need to show that it still works under the 2022 wording. ISO/IEC 27002:2022 gives the implementation guidance for the control, and it is the document to read when you need to explain your reasoning in plain terms.

The control is hard to meet in small teams because the people who can do the work are often the same people who can check it. A three-person IT function may have one administrator who builds servers, deploys code and holds the keys to the backup system. Separation does not require a large headcount, but it does require you to identify which combinations of duties create risk and then decide how each one is handled. Start with a short list of high-risk pairings, such as requesting and approving access, developing and promoting code to production, and recording and reconciling financial transactions. Confirm with the business owner of each system who currently holds both halves of each pair, and record that finding before you change anything.

Where full separation is not practical, you still need a documented answer. Options include a second approver who reviews every privileged action, a log review performed by someone outside the administration team, or a rule that a person may not approve their own request, enforced in the ticketing or change system. These are compensating controls, and an assessor will ask who performs them, how often, and what evidence they leave behind. Ask your certification body or auditor early whether they accept your compensating controls for the pairings you cannot split, because a compensating control that exists only in conversation rarely satisfies anyone.

Which roles, systems and third parties fall under segregation of duties

Segregation of duties applies wherever one person could start, approve, change or conceal a sensitive action without a second party. The cards below cover the scope areas that most often change the amount of work, from production access and change approval to finance, HR, administrators and outsourced operators. Each card names the conflict pair or boundary and the check that decides whether it belongs in scope.

Production access and deployment

Conflicting duties arise when the same people can write code, approve it and deploy it to production. Check whether developers hold standing production rights, whether deployment pipelines require a reviewer other than the author, and whether emergency access bypasses that review. Systems that handle customer data or security configuration are usually in scope, while isolated development sandboxes with no production data are usually not, provided the boundary is documented and tested.

Change request approval

A change that the requester also approves defeats the purpose of change control. List every change category your organization uses, then confirm that the approver for each category differs from the implementer and from the requester. Standard, pre-approved changes need a defined owner who reviews them periodically. Record the approver identity in the ticket, since auditors sample change records to test whether separation actually happened.

Financial and procurement systems

Typical conflicts include creating a vendor and paying that vendor, or raising a purchase order and approving the invoice. Information security scope is usually triggered when these functions sit in systems that hold financial records or affect integrity reporting. Confirm which roles can create, modify and release payments, and whether the ERP or accounting platform enforces approval limits or only relies on policy.

HR and identity administration

Staff who can create accounts, assign roles and approve their own access create a path to unauthorized access that bypasses every other control. Map who can onboard, change and remove identities in the directory and in each application, and check whether the person who requests a role is barred from approving it. Payroll and HR data systems often fall in scope alongside identity administration because they drive access decisions.

Privileged administrators and log custody

Administrators who manage servers, databases or security tools are the most common source of unsupervised power. Separate the roles that configure systems from those that review audit logs, and make sure administrators cannot alter or delete their own activity records. Break-glass accounts need named custodians, sealed credentials and review after each use. Confirm that privileged rights are granted per task rather than as a standing shared role.

Outsourced operators and managed providers

A managed service provider or implementation partner that both operates a system and approves its own changes sits inside your separation model even though its staff are not your employees. Define in the contract which party requests, approves and executes each change, and require the provider's administrators to use named accounts that your organization can review. Confirm whether the provider's access is covered by the supplier controls you already run, and record any gap as a risk for your own decision.

How an assessor tests segregation of duties

This table walks through the test steps an assessor typically performs for A.5.3, the evidence each step requests and the findings that most often appear. Read it as a checklist for preparing evidence before fieldwork starts, since each row maps a test to what the organization must be able to show.

Test step	What the assessor checks	Evidence requested	Common finding
Conflict matrix review	Whether a written matrix names the duties that must not sit with one person, such as request, approve, deploy and reconcile	Approved matrix with version history, owner and review date, plus the rationale for each conflict	Matrix exists but omits production deployment, payment release or privileged admin roles
Role assignment comparison	Whether actual role assignments in identity and business systems match the matrix	Exported role lists from directory, ERP, cloud and code hosting tools, dated and tied to the matrix	Users hold conflicting roles through group nesting or inherited permissions that nobody reviewed
Sampling of change approvals	Whether the person who approved a change is different from the person who built or deployed it	Change records with requester, approver, implementer and timestamps for a sample of changes	Self-approved changes where the approval field is filled by the implementer or left blank for emergency changes
Sampling of access grants	Whether anyone approved their own access or the access of a peer in their own team without a second reviewer	Access request tickets showing requester, approver and fulfilment for a sample of grants	Administrators approve their own privileged access, or approvals are granted by a shared account
Break-glass and emergency paths	Whether emergency bypasses of separation are logged, time-limited and reviewed after the event	Emergency access logs, post-event review records and sign-off by a second person	Emergency access is used routinely with no review, or reviews are not dated
Compensating control review	Where separation is not practical, whether a documented alternative control detects misuse and is operating	Compensating control description, owner, monitoring reports and records of exceptions reviewed	Small teams rely on informal supervision that is not written down, so the assessor cannot test it
Access certification campaigns	Whether reviewers look for accumulated access that creates conflicts, not only for unused access	Campaign scope, reviewer assignments, decisions to keep, change or revoke, and completion records	Campaigns certify access as a list without checking it against the conflict matrix
Documentation of exceptions	Whether each accepted conflict has an owner, a justification, an expiry and a periodic re-approval	Exception register with approvals, expiry dates and evidence of re-approval	Exceptions granted once and never revisited, or no register at all

Implementing segregation of duties step by step

This sequence turns A.5.3 from a policy statement into a working set of separated roles, approval paths and documented exceptions that an assessor can sample. Each step produces an artifact that the next step depends on.

Identify conflicting roles and duties
Start with the business processes that move money, data, code, configuration or access, and list every task inside each process. Mark pairs of tasks that one person should not perform alone, such as requesting and approving a payment, developing and deploying a change, or administering a system and auditing its logs. Owners of each process confirm the list, and the security function reviews it. The step is done when every critical process has a written list of incompatible task pairs with the owner's sign-off.
Define the conflict matrix
Turn the task pairs into a matrix that maps roles to the duties they may hold and the duties they may never hold together. Rows are roles, columns are duties, and each cell records allowed, prohibited or allowed with approval. Assign a named owner to each role, and record which systems implement each rule. The output is a versioned matrix stored with the access control policy, so an assessor can compare it with the identity records in the next steps.
Enforce separation in access rights
Translate the matrix into concrete access rights in the identity provider, applications and cloud accounts. Remove combinations that the matrix prohibits, separate administrator accounts from ordinary user accounts, and restrict who can grant or change rights. Where the platform supports it, block a conflicting assignment at the point of request rather than detecting it later. The check is a test export of role assignments showing that no identity holds a prohibited combination.
Separate change and release approval
Require that the person who requests a change, the person who builds or implements it, and the person who approves it are different individuals wherever the matrix says so. Configure the change workflow so approvals are recorded against each change record, and block self-approval in the tool. Keep change requests, approvals and deployment logs linked so that one ticket shows the full path. The output is a sample of closed changes where each record shows separate requester, implementer and approver.
Document compensating controls where separation is impractical
Some organizations are too small or too specialized to separate every duty, so identify each remaining conflict and decide how it will be controlled. Typical compensating measures include independent review of logs, dual control on sensitive actions, management review of reports, and monitoring of privileged activity. Record the residual risk, the compensating control, the accountable owner and the evidence that the control runs. Management accepts each exception in writing. The step is complete when every unresolved conflict has a documented, approved and evidenced alternative.
Run access certification and review cycle
Set a review cycle that checks role assignments against the matrix and the approved exceptions, with designated reviewers who decide to keep, change or revoke each item within a set timeframe. Tools such as midPoint can run these campaigns and keep the decisions, but the organization sets the cadence and the reviewers. Track findings, correct conflicts and update the matrix when processes or staff change. The output is completed review records, correction tickets and a dated log that shows the cycle is running.

Where separation breaks down in access and change approval

Separation usually breaks down quietly, through accumulation rather than a single bad decision. An engineer joins the platform team with read access to production logs, moves to the release group and keeps the old group memberships, then takes on an incident role that adds administrative rights. Each grant looked reasonable when it was made, but no step removed what the previous role no longer needed. Under A.5.18 Access rights, the joiner, mover and leaver steps are where this is prevented, so the reader should check whether a role change triggers removal of prior access as well as addition of new access, and whether the periodic access review compares actual entitlements against the role definition rather than simply confirming that named accounts still exist.

The change pipeline is where accumulated access turns into a segregation failure. If one person can raise a change request, approve it and deploy it, the approval step is decorative. Under A.8.32 Change management, the question an assessor asks is whether the requester, the approver and the person who applies the change are different people for changes that affect production, or whether an approver can approve their own change through a shared group, a broken workflow or an emergency path that skips review. Ticketing tools such as GLPI, whose Assistance module handles tickets and changes following ITIL practices, can hold the request and approval record, but the reader should confirm that the approval rule is enforced by the tool and not just followed by convention, and that the emergency change path still records a second person.

Privileged access under A.8.2 Privileged access rights concentrates the risk, because administrators can often bypass both the approval workflow and the logs that would reveal it. Practical checks include listing every account that holds administrative rights to the deployment pipeline, the repository and the production hosts, then asking whether any of those accounts can also approve the changes it deploys. Where a small team cannot avoid a single person holding both roles, the decision is a compensating control: independent review of that person's changes after the fact, tighter logging of administrative actions and a named second approver for high-risk changes. Access certification campaigns in midPoint, which have designated reviewers decide whether to keep, change or revoke each role assignment within a set timeframe, can surface accumulation that a manual review would miss. The reader should confirm what the timeframe is in their own configuration.

Evidence that proves conflicting duties stay separated

An auditor testing A.5.3 wants proof that conflicting duties are separated in practice, not only in a policy. The artifacts below connect the conflict analysis to what actually happened in access, change and review records, and each one needs a routine owner so it stays current between audits.

Segregation conflict matrix

A matrix listing each pair of roles, functions or permissions that must not sit with one person, such as requesting and approving a payment or developing and promoting code. Record the rationale for each conflict and the owner who signed it off. Review it when new systems, roles or teams appear, and reconcile it against the role assignment export at each review so that a new conflict cannot slip in unnoticed.

Role assignment exports

Periodic exports from each system showing who holds which roles, groups and privileged permissions. These are the raw data an assessor compares against the conflict matrix. Check for combinations the matrix forbids, including roles inherited through groups and accounts that were never linked to a person. Schedule the export on a fixed cadence and keep the date and source system with each file.

Change approval records with distinct approvers

For each production change, the ticket should show who requested it, who approved it and who deployed it, with the approver different from the requester and the deployer. Ticketing tools such as GLPI can hold these change records with timestamps. Sample recent changes yourself and confirm that no single identity appears in more than one of these roles, and that emergency changes have a documented after-the-fact review.

Access review sign-offs

Signed or recorded decisions from designated reviewers who confirm, change or revoke each access item within a set timeframe. The sign-off should name the reviewer, the date, the items reviewed and the action taken. Reviewers should not be the people whose access they review. Track revocations to confirm they were actually executed in the systems, not only recorded as decided.

Compensating control records

Where a small team cannot separate a duty, a documented compensating control, such as independent review of a sample of transactions by a manager outside the process, must fill the gap. Keep the decision, the residual risk accepted, the reviewer, and evidence that each review ran on schedule. Revisit the compensating control whenever headcount or the process changes, because a control that lapsed quietly is a finding.

Privileged access and exception log

A register of privileged accounts, their owners and the conflicting permissions each one holds, plus any approved exceptions to the matrix with an expiry date. Auditors often test whether administrators can both change configurations and approve their own changes. Reconcile this log against the exports each quarter, and close any exception that has passed its expiry date.

What meeting A.5.3 costs in money and effort

This table breaks down the cost components of enforcing segregation of duties, who is paid for each, whether it is one-time or recurring, and what drives it up or down. Use it to build a quote request, since no price is published here and most costs depend on how many conflicting roles your environment has.

Cost component	Who is paid or who spends	One-time or recurring	What drives the cost
Tooling and licenses	Software vendor for commercial identity governance or ticketing products	Usually recurring (subscription or maintenance)	Number of users, systems and approval workflows in scope
Open-source tooling	No license fee; hosting, setup and upkeep fall to your team or implementer	One-time setup plus recurring hosting and upgrades	Infrastructure size, integrations with identity and change systems, upgrade frequency
Role analysis and redesign	Internal engineers and access owners; sometimes an implementation partner	One-time, with periodic repeats after reorganizations	Number of job roles, legacy permission sprawl, number of conflicting pairs identified
Change approval workflow design	Change managers, platform engineers and developers	One-time build, then ongoing maintenance	Number of production change paths and emergency change procedures
Compensating controls where separation is impractical	Internal management for review, and tooling for logging and monitoring	Recurring, as reviews run on a schedule	Size of small teams, number of single-person functions, frequency of reviews
Access certification reviews	Designated reviewers (managers, system owners) spend time on each review cycle	Recurring, per review campaign	Number of access items, reviewer count, review frequency and review scope
Evidence upkeep	Internal control owners export logs, ticket records and approval histories	Recurring, tied to each audit or assessment window	Evidence sources, retention rules and how often records are sampled
External review and audit	Independent auditor or certification body; consultant or implementer if engaged	Periodic, tied to the audit cycle	Scope of the ISMS, number of sites, sample sizes the auditor selects, readiness of evidence

Who owns segregation of duties and who can help

Your organization owns A.5.3. Management decides which duties conflict, accepts the residual risk where separation is impractical and signs off the rules that enforce separation. No outside party can make those decisions on your behalf, because the Statement of Applicability and the risk treatment choices are your statements about your own business. The people who approve exceptions must be named and must not be the same people who benefit from them.

Conflict matrix: Maintain a written list of conflicting roles and activities, such as requesting and approving a payment, developing and deploying code, or administering a system and auditing its logs.
Approval authority: Record who may approve access grants, change requests and privileged actions, and confirm that approvers are independent of the requester.
Exception register: Document each case where separation is not practical, the compensating control applied, the owner and the review date.
Ongoing review: Recheck the matrix after reorganizations, hiring, role changes and new systems, since accumulated access tends to drift.
Management acceptance: Keep records showing that leaders reviewed and accepted the matrix and the residual risk.

Before engaging anyone, check that your internal owner can answer for every conflict in the matrix without referring to a consultant.

Common gaps in segregation of duties and how to close them

Most segregation of duties failures are not dramatic. They are missing records, admins who can approve their own work, and reviews that confirm access without ever removing it. Each card below pairs one common gap with a closure step an assessor can test under A.5.3.

No conflict matrix

Without a documented list of incompatible duties, nobody can say which role combinations are forbidden. Build a matrix that pairs conflicting activities, such as requesting and approving a payment, or developing and deploying code to production. Record the owner who signed off the matrix and the date of the last review. Assessors often ask for this document first, so confirm it exists before the audit starts.

Admins approving their own changes

When the person who makes a change can also approve it, a single account can bypass review of configuration, access or code. Enforce a rule that the requester cannot be an approver, and configure the change workflow so the system blocks self-approval rather than relying on people to follow the rule. Test this by attempting a self-approved change in a non-production environment and keeping the result as evidence. This ties directly to A.8.32 Change management.

Undocumented compensating controls

Small teams often cannot separate every duty, so one person holds two conflicting roles. That can be acceptable, but only if a compensating control is written down, owned and operating. Examples include independent review of the person's output by a manager, or log review by a second team. Document the residual risk, the compensating control, the reviewer and the review frequency, then retain the review records. An undocumented workaround is indistinguishable from no control at all.

Access reviews that never revoke

A review that confirms every existing role is not a segregation control. Reviewers tend to approve access they do not understand, and accumulated roles from past jobs remain active. Give reviewers the list of conflicting combinations from the matrix and require a keep, change or revoke decision for each flagged item within a set period. Track the revocations. If a review campaign never removes anything, ask the reviewer to explain why, and check whether the review is reaching the right people. Tools such as midPoint support this kind of certification campaign.

Shared accounts across conflicting roles

A shared administrator or service account makes it impossible to tell which person performed an action, so separation of duties cannot be enforced or evidenced. Replace shared accounts with named identities for people and controlled, owned identities for systems. Where a shared account cannot be removed, restrict its use to a documented procedure with a logged approver. Check the audit logs for activity under shared identities during the last review period and confirm that each action traces to a person.

Ticket workflows that skip the approval step

Requests can move from submission to fulfilment without a separate approval step when the workflow allows it, or when urgent work is handled outside the system. Map the actual path of a change or access request, then compare it with the documented one. Configure the ticketing system so the approval state is mandatory before fulfilment, and record emergency changes with a retrospective approval. Open-source service management tools such as GLPI include change and problem workflows that can carry these states.

How long and how much work does segregation of duties take?

How much does it cost to implement segregation of duties for ISO 27001?

No supplied source gives a price for segregation of duties, and DeployOpen does not publish one. Cost comes from the work: mapping conflicting roles, changing access and approval workflows, and collecting evidence. Your own team carries the internal time for decisions and sign-off. An external party is paid only for the work in its written scope. Ask any provider for a quote that separates one-time setup (role analysis, workflow changes, tooling configuration) from recurring work (periodic access reviews, change approval support and evidence collection). Ask the certification body separately for its audit fees, since those are not part of implementation.

How long does it take to put segregation of duties in place?

No supplied source gives a duration for this control, so treat any figure you hear as a question to ask rather than a benchmark. The timeline depends on how many systems and roles need separation, how many approval paths already exist, and whether the team has a current access inventory. A small organization with a few systems and clear ownership can move faster than one with many legacy applications and shared accounts. Ask for a schedule tied to the written scope, with milestones for role mapping, control changes, a period in which the new separation operates, and evidence capture before the audit.

What does the internal team need to provide for segregation of duties?

The work needs people who know how the business actually operates, not only how the systems are configured. Expect to involve:

Can we implement segregation of duties ourselves without a partner?

Yes, many organizations do this in-house, and ISO/IEC 27001 does not require outside help. The control asks you to identify conflicting duties and enforce separation, so the organization owns the decisions. In-house teams struggle most with three things: finding conflicts hidden in role combinations, getting managers to accept approval changes that slow work, and keeping evidence current between audits. Assess whether your team has time for role analysis, change to approval workflows and recurring reviews, and whether it can document the reasoning behind every compensating control.

When should we bring in a partner for segregation of duties?

Bring in a partner when the internal team lacks time, when systems are complex or self-hosted and need configuration, or when the organization needs an independent view of role conflicts. DeployOpen prepares systems, controls and evidence for compliance assessments, and most engagements are fixed-scope with deliverables agreed in writing before work starts. DeployOpen does not issue audit reports or certificates, and an independent certification body must still assess the controls. Keep the partner independent from the certification body and check that the written scope names who approves each role decision.

What makes segregation of duties more expensive over time?

Costs rise when the number of systems, roles and approval paths grows, because each new conflict needs review and each new workflow needs evidence. Mergers, new products and staff turnover add recurring work, since access accumulates unless reviews remove it. Costs fall when identity data is clean, approval paths are documented and access reviews run on a fixed cycle. Ask any provider to price recurring work separately, including periodic review campaigns and support for changes to the control.

Which tools can help run segregation of duties reviews?

Open-source tools can support parts of the control, but none replaces the decisions on conflicting roles. midPoint documents access certification campaigns in which designated reviewers decide within a set timeframe whether to keep, change or revoke access items such as role assignments. GLPI's Assistance module, documented as following ITIL practices, can route change requests through tickets and records. Zammad is a web-based helpdesk that brings requests into one ticket system. Confirm each tool's approval and separation features in your own environment before relying on it as evidence.

How DeployOpen prepares segregation of duties evidence

DeployOpen plans, implements and documents the technical separation that A.5.3 Segregation of duties depends on, inside your own infrastructure. We prepare the systems, role design and records an assessor will sample, while your organization keeps ownership of the controls and the independent auditor or certification body issues any report or certificate.

How we scope

We agree a written scope listing which conflicting roles and areas of responsibility the engagement covers.
Scope names the systems in play, such as identity, change approval, payments or deployment pipelines, before any work starts.
Engagements are fixed-scope, with deliverables and timelines agreed in writing; ongoing support is available as a retainer.

How we build

We map conflicting duties to role definitions and separate approver, requester and implementer rights in the platforms you run.
We configure access certification campaigns so designated reviewers decide whether to keep, change or revoke role assignments.
Where full separation is not practical, we set up documented compensating controls such as independent review of logged actions.

How we hand over

We deliver a segregation matrix, role descriptions and the approval workflow configuration for your records.
We document how each separation is tested, which evidence is produced, and where an assessor can find it.
Your team receives runbooks so access reviews and role changes continue after the engagement closes.

How we support

Retainer support can cover periodic access reviews, role changes after reorganizations and updates to the conflict matrix.
We can rerun separation checks after upgrades or new integrations so evidence stays current between assessments.
Questions about the independent assessment itself go to your auditor or certification body, not to DeployOpen.