Why do internal controls need more than separation of duties?

Why This Matters for Security Teams

Separation of duties is useful, but it only addresses one slice of control design: who can initiate, approve, and execute a sensitive action. It does not by itself detect failed reconciliations, weak exception handling, or situations where an approved process is misused after the fact. That is why modern control programs pair SoD with monitoring, evidence review, and corrective action, as reflected in the NIST Cybersecurity Framework 2.0 emphasis on detect and respond activities.

For NHI-heavy environments, the gap is even wider. Service accounts, API keys, certificates, and automated workflows often bypass human approval chains entirely, which means SoD can look strong on paper while secrets remain overprivileged or unreconciled in practice. NHI Management Group’s Ultimate Guide to NHIs shows how governance breaks down when identity inventory, rotation, and offboarding are treated as one-time tasks rather than continuous controls. The operational problem is not that SoD is wrong; it is that SoD is incomplete without ongoing verification. In practice, many security teams encounter control failure only after an exception is exploited or an audit reveals that approvals were logged but never reconciled.

How It Works in Practice

Effective internal control design layers SoD with compensating controls that verify the process actually worked. In practice, that means the control owner should not stop at “different people approved and executed the action.” They should also confirm the transaction was recorded correctly, the entitlement change was reconciled against source data, and any exception was documented, time-bound, and reviewed. This is especially important where NHI activity is involved, because machine identities do not behave like users and can generate large volumes of access events that humans miss.

A mature pattern usually includes:

• pre-approval for high-risk actions, plus independent post-execution review
• periodic reconciliation between requested, approved, and completed changes
• rotation and revocation checks for credentials, tokens, and certificates
• evidence retention for exceptions, overrides, and emergency access
• training for approvers so they can spot abnormal requests, not just sign them

That operational model aligns with guidance in the Ultimate Guide to NHIs, which treats lifecycle controls and visibility as core governance requirements, not optional add-ons. It also fits the spirit of the NIST Cybersecurity Framework 2.0, where control effectiveness depends on continuous oversight rather than static policy placement. One useful way to think about it is that SoD limits who can act, while monitoring and reconciliation prove that the action was legitimate and complete. These controls tend to break down when approval evidence is scattered across ticketing systems, spreadsheets, and CI/CD tooling because no single owner can reconcile the full chain of custody.

Common Variations and Edge Cases

Tighter SoD often increases operational overhead, requiring organisations to balance fraud resistance against speed, resilience, and staffing limits. That tradeoff is real in small teams, during incident response, and in automation-heavy environments where a human approval every time would create bottlenecks.

Current guidance suggests several practical exceptions. Emergency access can be justified, but it should be logged, time-limited, and reviewed after the event. Automated workflows can also satisfy control intent if the design includes independent review, immutable logs, and periodic recertification. In NHI contexts, the hardest edge case is often the “approved but forgotten” credential: a service account or API key that was created for a legitimate workflow and never revisited. That is where Ultimate Guide to NHIs — Standards becomes especially relevant, because lifecycle governance must include offboarding, rotation, and ownership clarity. The practical lesson is that SoD helps prevent unilateral misuse, but only continuous review catches collusion, stale exceptions, and control drift before they become incidents.

Related resources from NHI Mgmt Group

• Why do segregation of duties controls matter so much in SOX readiness?
• What is the difference between human IAM controls and NHI governance?
• Should organisations prioritise external exposure or internal credential governance first?
• When should organizations review access controls?