Who should be accountable when SOD violations involve service accounts?

Why This Matters for Security Teams

service account are often treated as technical plumbing, but when they can approve payments, move data, deploy code, or trigger exceptions, they become part of the segregation of duties model. That shifts accountability from a purely operational issue to a governance one. NIST SP 800-53 Rev 5 Security and Privacy Controls makes the control expectation clear: access must be assigned, reviewed, and enforced as a security decision, not an incidental admin task.

This is why identity governance owners should own the policy outcome even when the account is maintained by another team. If accountability is left undefined, violations tend to survive because each team assumes another group is responsible for the exception, the review, or the remediation. NHIMG research shows that only 5.7% of organisations have full visibility into their service accounts, which makes hidden SoD exposure common rather than exceptional. See the Ultimate Guide to NHIs — What are Non-Human Identities and the 52 NHI Breaches Analysis for the broader pattern.

In practice, many security teams discover service-account SoD violations only after a fraud review, audit finding, or incident has already exposed the gap.

How It Works in Practice

The practical answer is to separate policy ownership from system ownership. Identity governance, risk, or security typically owns the SoD policy, the approval logic, and the exception standard. Application, finance, or platform teams usually own the workflow that creates the business action, the service account that executes it, and the evidence required for remediation. That split keeps the control accountable without pretending the identity team understands every application nuance.

For service accounts, the review should focus on what the identity can actually do, not what team created it. A service account that can initiate invoices, approve journal entries, change vendor records, or deploy production code needs the same SoD scrutiny as a human user. Current guidance suggests three checks are essential:

• Map each service account to a business function, not just an application name.
• Define the conflicting duties it can trigger, inherit, or bypass.
• Require a named business owner and a named control owner for exceptions.

That model aligns with NIST SP 800-53 Rev 5 Security and Privacy Controls and with the identity visibility concerns highlighted in the Ultimate Guide to NHIs — What are Non-Human Identities. The operational rule is simple: if a service account can affect a controlled business step, it must be reviewed, approved, and remediated through the same governance chain used for people. These controls tend to break down in legacy ERP, mainframe, and batch-processing environments because ownership is fragmented and the account-to-process mapping is rarely current.

Common Variations and Edge Cases

Tighter SoD enforcement often increases operational overhead, requiring organisations to balance control strength against release speed, outage risk, and support burden. That tradeoff becomes sharper when service accounts are embedded in automation, shared across multiple apps, or inherited through vendor-managed platforms.

There is no universal standard for this yet, but current guidance suggests a few common edge-case rules. Shared service accounts should not be excluded from SoD just because multiple teams use them; instead, the control should attach to the business functions they can perform. Break-glass and emergency accounts need separate exception handling, short review windows, and explicit post-use validation. In cloud and CI/CD pipelines, the account may be ephemeral, but the SoD obligation still applies if it can change production state or approve sensitive actions.

For teams modernising governance, the right question is not who administers the credential, but who can accept the risk of the conflict. That is also where audit evidence matters most: ownership, approval history, and remediation proof should be visible in the GRC record and tied back to the service-account lifecycle. NHIMG’s Ultimate Guide to NHIs — What are Non-Human Identities is useful here because it frames service accounts as governed identities, not just technical objects.

Related resources from NHI Mgmt Group

• What problem does ownership attribution solve for service accounts and API keys?
• When do service accounts become a higher risk than ordinary user accounts?
• How should security teams govern Active Directory service accounts?
• Should organisations use the same governance model for CI/CD identities as for service accounts?