How should organisations automate ITGCs without weakening segregation of duties controls?

Why This Matters for Security Teams

Automating ITGCs is valuable only if the control objective stays intact: access and change activity must remain traceable, approved, and separated where required. The failure mode is not usually the workflow itself, but automation that accelerates the wrong thing, such as granting access before conflict checks complete or auto-approving exceptions without reviewer accountability. NIST’s NIST SP 800-53 Rev 5 Security and Privacy Controls remains the clearest baseline for proving that controls are designed, not implied.

For teams that rely on scripts, tickets, and identity platforms, the real risk is silent control drift. A workflow can look efficient while still allowing the same person to request, approve, and benefit from access. That is especially dangerous in environments with service accounts, CI/CD automation, and shared admin roles, where segregation of duties becomes harder to see and easier to bypass. NHI Management Group’s Ultimate Guide to NHIs — Standards shows why this matters: NHIs are often overprivileged and poorly governed, which makes automated control paths a high-value target.

In practice, many security teams discover SoD failures only after an auditor asks for evidence, rather than through intentional control design.

How It Works in Practice

Effective automation treats ITGCs as policy-enforced workflows, not just task automation. The workflow should verify the requestor’s role, check for conflicting entitlements, route approvals to an independent reviewer, and record each decision in a tamper-evident audit trail. Where access is time-bound, use just-in-time assignment and automatic expiry so the control remains narrow and reviewable. That approach aligns with zero trust principles and avoids turning convenience into standing privilege.

For implementation, many organisations separate three control layers. First is entitlement logic: rules that detect whether a user already holds conflicting finance, development, or production support access. Second is approval logic: an independent approver must validate the request, especially for privileged access or emergency exceptions. Third is evidence logic: the system should capture who requested, who approved, what was granted, when it expires, and whether recertification was completed. This is where identity hygiene matters, because service accounts and other NHIs often have long-lived access paths that bypass human review if they are not modelled explicitly. NHIMG’s Codecov Supply Chain Breach illustrates how a weak control boundary around secrets and automation can cascade into broader compromise.

• Use policy-as-code to evaluate conflicts before access is issued.
• Require independent approval for privileged or compensating controls.
• Make evidence collection automatic so audit does not depend on manual screenshots.
• Recertify both human and non-human access on a fixed cadence.

Current guidance suggests that automation should enforce segregation of duties at request time, not rely on after-the-fact review. These controls tend to break down in highly dynamic DevOps environments because the same pipeline can both create and deploy privileges faster than reviewers can intervene.

Common Variations and Edge Cases

Tighter automation often increases workflow friction, requiring organisations to balance faster provisioning against stronger independence checks. That tradeoff becomes more visible when business teams expect low-friction access during month-end close, incident response, or production releases. The answer is not to weaken SoD, but to define narrow exception paths with stronger logging, shorter expiry, and mandatory post-approval review.

There is no universal standard for this yet, but current guidance suggests handling edge cases through compensating controls rather than informal overrides. For example, emergency access may be granted with JIT expiry and retrospective sign-off, while sensitive change workflows may require two-person approval plus immutable logging. Where automation touches NHIs, the same discipline applies to API keys, service principals, and machine-to-machine tokens, because those identities can execute changes without a human present. NIST’s NIST SP 800-53 Rev 5 Security and Privacy Controls is useful here because it supports evidence-based control testing, not just policy statements.

In practice, the hardest cases are shared admin models, emergency break-glass accounts, and automated deployment chains where one actor requests, approves, and executes too much of the process. Those environments need explicit SoD mapping before automation is expanded, otherwise the workflow becomes a control bypass rather than a control improvement.

Related resources from NHI Mgmt Group

• What breaks when organisations rely only on segregation of duties checks in ERP cloud security?
• How should organisations automate user access reviews without weakening control quality?
• How can organisations reduce false positives without weakening identity controls?
• How should organisations implement passwordless IAM without weakening recovery controls?