Mitigation controls for segregation of duties risk and audit readiness

At a glance

What this is: This article explains how mitigation controls turn unresolved segregation of duties violations into documented, monitored risk treatments.

Why it matters: It matters because IAM, IGA, and PAM teams need a defensible way to manage necessary access conflicts without losing auditability or control.

By the numbers:

• Organizations that have experienced a compromised NHI averaged 2.7 separate incidents in the past 12 months.

👉 Read SafePaaS's full article on mitigation controls for segregation of duties

Context

Segregation of Duties, or SoD, is a control designed to prevent one identity from carrying out conflicting business functions without oversight. In practice, that becomes an identity governance problem when users, service accounts, or operational roles legitimately need access on both sides of a sensitive process and the business cannot simply revoke it.

The article’s core point is that detection alone is not enough. IAM and IGA teams need a documented treatment path for conflicts that cannot be removed, with time bounds, review, and evidence. That maps directly to broader governance expectations around access accountability, internal controls, and exception handling.

Key questions

Q: How should security teams handle SoD violations that cannot be remediated?

A: They should treat them as formal risk acceptances with documented mitigation, not as unresolved exceptions. That means assigning an owner, a justification, a validity period, and a review process. If the conflict stays active in production, the organisation needs evidence that the risk is monitored and periodically revalidated rather than simply tolerated.

Q: Why do SoD conflicts remain risky even when no fraud has occurred?

A: Because the risk lies in the access path as much as the transaction outcome. A user who can both create and approve can bypass controls whenever circumstances change, even if they have not yet done so. Governance must therefore cover both entitlement state and the possibility of future misuse.

Q: What do auditors expect to see for accepted SoD risk?

A: Auditors expect a complete treatment trail. Each conflict should show whether it was remediated, mitigated, or still pending, along with the reason for the choice and the evidence supporting it. Without that trail, an organisation can detect risk but still fail to demonstrate control over it.

Q: When should organisations prefer remediation over mitigation?

A: They should prefer remediation whenever access can be removed without breaking essential operations. Mitigation is appropriate only when the conflicting access is genuinely required and the organisation can prove that compensating controls, such as monitoring or approval review, reduce the residual risk to an acceptable level.

Technical breakdown

How SoD violation detection works

SoD testing begins by defining conflict rules, usually as pairs of incompatible functions such as create vendor and approve payment. A GRC or identity governance platform compares user-role entitlements against that ruleset to identify who can perform both sides of a prohibited combination. This is a can-do analysis: it shows potential abuse paths, not actual misuse. The value is in turning policy into machine-readable control checks that can be repeated after each access change or system update.

Practical implication: maintain a current ruleset and rerun SoD analysis whenever access models or business processes change.

Mitigation controls versus remediation

Remediation removes the conflicting access. Mitigation leaves the access in place but adds a compensating control, such as documented approval, transaction monitoring, or restricted review periods. The distinction matters because some operational roles cannot lose access without stopping finance, procurement, or close processes. A mitigation control is therefore an explicit risk acceptance mechanism, not a weaker form of remediation. It succeeds only when the organisation can explain what is being monitored, for how long, and by whom.

Practical implication: treat mitigation as a controlled exception path with owner, expiry, and justification, not as a permanent workaround.

From can-do analysis to did-do monitoring

Traditional SoD tools answer whether a user could perform conflicting actions. Transaction monitoring asks whether they actually did. That second layer matters because entitlement risk and transaction risk are not identical. A user may hold conflicting access and never exercise it, or may repeatedly use both sides of the conflict. Linking SoD violations to transaction monitors gives auditors evidence that the organisation is watching actual behaviour, not just access state. That is the difference between static compliance and risk visibility.

Practical implication: pair entitlement testing with transaction-level monitoring for any SoD violation you choose to keep active.

Threat narrative

Attacker objective: The objective is to exploit conflicting access to bypass financial control boundaries and carry out unauthorised or unreviewed transactions.

1. Entry occurs when a user is granted conflicting access that lets them participate in both sides of a controlled business process.
2. Escalation happens when that access is not removed and instead becomes an accepted exception with weak or missing compensating oversight.
3. Impact follows if the user actually executes conflicting transactions, creating fraud, misstatement, or control failure in financial workflows.

Breaches seen in the wild

• Cisco DevHub NHI breach — IntelBroker exploited exposed Cisco credentials, API tokens and keys in DevHub.
• DeepSeek breach — DeepSeek breach exposed 1M+ log lines and sensitive secret keys.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Mitigation is a governance decision, not a technical workaround. The article correctly frames unresolved SoD conflicts as accepted risk that must be documented, monitored, and revalidated. That is the right control lens for business-critical access that cannot be removed without disrupting operations. The implication is that IAM and IGA teams must manage exceptions with the same discipline they apply to standard entitlements.

SoD failures expose an access governance gap, not just a policy gap. A rule set that detects conflicts but leaves treatment undefined creates an audit problem because the organisation knows the risk exists but cannot show how it is governed. That maps directly to COSO monitoring and COBIT internal control expectations. Practitioners should treat every unresolved violation as a lifecycle item with ownership, expiry, and evidence.

Can-do analysis is incomplete without did-do evidence. The article’s strongest contribution is the link between entitlement conflict and transaction monitoring. That matters because many SoD violations are theoretical until exercised, while others become material only when the user acts on both sides of the conflict. The practitioner conclusion is that access review alone is not enough when accepted conflicts remain in production.

Accepted conflict exposure: the governing assumption that a user should not be allowed to hold conflicting access without remediation fails when the business depends on that access to keep operating. That assumption was designed for clean separation, not for operational exceptions with documented risk acceptance. The implication is that control design must distinguish between access removal and accountable exception governance.

Audit readiness depends on proving treatment coverage, not just finding violations. The article shows that 500 detected conflicts mean little if 400 are left without documented remediation or mitigation. That is a maturity test for internal controls. Practitioners should expect auditors to ask whether every violation has an owner, a treatment path, and a review date.

From our research:

• 72% of organisations have experienced or suspect they have experienced a breach of non-human identities, according to The 2024 ESG Report: Managing Non-Human Identities.
• Two-thirds of enterprises have endured a successful cyberattack resulting from compromised non-human identities, with a quarter encountering multiple attacks.
• For a broader control perspective, see Ultimate Guide to NHIs , Lifecycle Processes for Managing NHIs for lifecycle controls that keep accepted access from becoming permanent.

What this signals

Accepted SoD exposure is a governance state, not a temporary exception. Once a conflict is formally tolerated, the control objective shifts from removal to accountability, expiry, and evidence. That makes exception management part of the identity lifecycle, not a side process. Teams that cannot show treatment coverage will find that their access model looks complete on paper but weak in audit practice.

Control design should separate access entitlement from transaction behaviour. A user may hold conflicting access without ever using it, but the risk becomes much more material once transaction activity is visible. That is why SoD programmes need both entitlement reviews and behavioural monitoring, especially where finance or procurement workflows are concerned.

Our view is that exception governance is becoming the real maturity signal. As control environments get more complex, the organisations that stay defensible will be the ones that can show who accepted the risk, for how long, and under what monitoring regime. That is a stronger signal than simply counting detected violations.

For practitioners

• Build a current SoD conflict matrix Define the business function pairs that create real control conflicts, map them to roles and users, and refresh the matrix whenever finance, procurement, or approval workflows change.
• Use mitigation only for justified exceptions Require a documented reason, named owner, and expiry date for every accepted conflict so mitigation stays time-bound and reviewable.
• Link SoD exceptions to transaction monitors Connect accepted conflicts to activity monitoring so reviewers can see whether the user actually executed both sides of the conflicting process.
• Separate remediated, mitigated, and pending violations Report each treatment path distinctly so audit teams can see what was fixed, what is accepted, and what still needs action.

Key takeaways

• Segregation of duties controls fail when organisations can detect conflicts but cannot prove how accepted exceptions are governed.
• The scale of unresolved NHI compromise shows that unmanaged identity risk is already operational, not theoretical.
• The decisive control is not only removal of access, but a documented, time-bound treatment model that auditors can trace end to end.

Key terms

• Segregation Of Duties: Segregation of Duties is an internal control that prevents one identity from holding access that enables conflicting business actions without oversight. In identity programmes, it reduces the chance that a single user can create, approve, and conceal a transaction within the same process.
• Mitigation Control: A mitigation control is a compensating control used when conflicting access cannot be removed without harming operations. It does not eliminate the underlying risk. Instead, it documents the exception, time-bounds it, and adds oversight such as monitoring or approval review.
• Can-Do Analysis: Can-do analysis evaluates whether an identity has the entitlement to perform conflicting actions, regardless of whether those actions have occurred. It is the standard SoD detection model and the starting point for deciding whether access should be remediated or accepted with mitigation.
• Did-Do Monitoring: Did-do monitoring checks whether a user actually performed the conflicting transactions that their access would permit. It adds behavioural evidence to entitlement review, helping organisations distinguish theoretical conflict from exercised risk in production workflows.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.

This post draws on content published by SafePaaS: Managing Segregation of Duties risk with mitigation controls. Read the original.