Why do SoD violations often persist even after they are identified?

Why SoD violations keep surviving the first finding

Segregation of duties problems often persist because identification and cleanup do not happen in the same control loop. A violation can be logged, reviewed, and still remain active if nobody owns the remediation step, the case is not routed to the right approver, or the access change is treated as a separate backlog item instead of an urgent control failure.

The practical issue is that SoD is not just a rule-definition problem, it is an access-governance workflow problem. Once a toxic combination exists, the organisation must decide whether to remove access, reassign responsibilities, or apply a compensating control, and each of those choices needs a tracked owner and a deadline.

That is why a clear ruleset matters. The Segregation of Duties (SoD) Guide is useful here because it frames SoD as both prevention and exception handling, including toxic combinations, mitigations, and extension to non-human access paths.

What usually breaks between detection and remediation

The gap is usually operational rather than theoretical. Detection tools can flag a conflict quickly, but if the alert lands in an unmanaged queue, remediation waits for manual triage, and the conflicting access keeps working in production, finance, or other sensitive workflows.

Another common failure is ownership ambiguity. Security may identify the issue, but application owners, IAM teams, and process owners each assume someone else will make the change. In those cases, the violation survives because the organisation has identified the risk without assigning the authority to remove it.

Queue design matters as much as detection quality. A case that only records the finding, without built-in routing, escalation, SLA tracking, or evidence of closure, creates a compliance log but not a control outcome.

Why the risk does not disappear once the violation is known

Known SoD violations still matter because the conflicting access can continue to enable fraud, error, unauthorized approval chains, or other policy breaches until it is actually removed or contained. In other words, visibility reduces surprise, but it does not reduce exposure on its own.

That is especially important where the conflict affects payment approval, vendor setup, journal entry, privileged administration, or other high-impact business functions. A documented exception may be acceptable only if it is time-bound, reviewed, and backed by a compensating control that is strong enough to offset the conflict.

For practitioners, the question is not whether the violation has been found, but whether the control has closed the loop. A finding without a fix is still an active control deficiency.

Practitioner Guidance

What to prioritise: Treat every confirmed SoD violation as an access issue with a due date, not as a reporting artifact. The first priority is to determine whether the conflicting entitlement can be removed immediately or whether a documented exception with compensating control is the only safe interim state.

What to verify: Check that each case has a named owner, a remediation path, and an escalation rule if the conflict remains open beyond the SLA. If those three items are missing, the organisation has detection, but not operational control.

Decision rule: If the same person or process can still complete both sides of a toxic combination, assume the risk remains live until access is changed or the workflow is structurally separated. Do not rely on the existence of the ticket as evidence of risk reduction.

Practitioner takeaway: Persistent SoD violations usually signal a control workflow failure, not a detection failure, so the real test is how quickly the organisation can convert a finding into enforced access change or a bounded exception.

Related resources from NHI Mgmt Group

• Why do web skimming campaigns often persist even after the original infection point is patched?
• Why do cybersecurity investments often fail to deliver value even after they are approved?
• Why do non-human identities create compliance risk even when policies exist?
• Why do ServiceNow tickets leak secrets so often?