What do auditors expect to see for accepted SoD risk?

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.

Why This Matters for Security Teams

Accepted segregation of duties risk is not just an access issue, it is an auditability issue. Auditors want to see that a conflicting access path was identified, assessed, and deliberately handled through remediation or compensating control. That expectation maps closely to the governance emphasis in the NIST Cybersecurity Framework 2.0, where risk treatment must be traceable, repeatable, and tied to accountability.

For NHI-heavy environments, the problem is usually bigger than a single user conflict. Service accounts, API keys, CI/CD tokens, and automation identities can all carry combinations of permissions that create hidden SoD exposure. NHIMG has documented how widespread this exposure can be in the Ultimate Guide to NHIs — Regulatory and Audit Perspectives, where the control problem is framed as lifecycle evidence, not just detection. In practice, many security teams encounter SoD failures only after an auditor asks for proof of treatment, rather than through intentional governance design.

How It Works in Practice

Auditors usually expect a complete treatment trail for each accepted conflict. That trail should show the conflict itself, the risk rating, the business owner, the treatment decision, the date accepted, the approval authority, and the evidence that the decision was executed. If the conflict was remediated, the record should show what was removed, rotated, or re-segmented. If it was mitigated, the record should show the compensating control, such as JIT elevation, approval gates, monitoring, or restricted runtime scope.

For NHI and agentic workloads, accepted SoD risk is often tied to runtime behaviour rather than static roles. A service account may not be inherently dangerous until it is paired with a CI/CD token, a deploy pipeline, and write access to production secrets. That is why auditors increasingly look for evidence that identity governance, secrets governance, and change control are linked. NHIMG’s Top 10 NHI Issues is a useful reminder that excess privilege and poor lifecycle control are often the root causes behind accepted risk records.

• Identify the conflicting duties and the specific system, account, or token involved.
• Document whether the conflict was fixed, mitigated, or formally accepted.
• Record why the decision was made, including business necessity and control tradeoffs.
• Attach evidence such as approvals, tickets, policy exceptions, logs, or control test results.
• Set a review date so acceptance does not become indefinite tolerance.

Best practice is evolving toward risk acceptance with expiry, where approvals must be revalidated on a schedule and after material changes to the workflow, privilege set, or owner. These controls tend to break down when exceptions are tracked in spreadsheets or email because the treatment history becomes fragmented and cannot be reconstructed during an audit.

Common Variations and Edge Cases

Tighter SoD governance often increases operational friction, requiring organisations to balance audit assurance against delivery speed. That tradeoff is especially visible where automation must deploy, test, and release with minimal human intervention. In those environments, current guidance suggests using compensating controls rather than pretending the conflict does not exist.

There is no universal standard for exactly how much evidence is enough, but auditors usually care about consistency and defensibility. A low-risk exception may only need documented approval and periodic review, while a higher-risk conflict may require stronger monitoring, dual control, or short-lived access. The accepted risk record should reflect that difference instead of using a one-size-fits-all template.

Edge cases often appear in third-party operations, emergency access, and inherited systems. For example, a legacy platform may not support granular RBAC, so the organisation accepts a temporary SoD conflict while a replacement is planned. In those cases, the rationale should reference the interim nature of the exception and the compensating safeguards. NHIMG’s Ultimate Guide to NHIs is especially relevant when the exception involves non-human identities whose permissions persist beyond the original project need. The accepted risk record fails when it captures approval but omits expiry, review, or ownership change handling.

Related resources from NHI Mgmt Group

• Why do non-human identities create more audit risk than human accounts?
• Why do non-human identities create audit risk in modern environments?
• Why do non-human identities create compliance risk even when policies exist?
• Why do collaboration tools create such a large secrets risk?