The platform owner, the data owner and the identity governance team all share responsibility, because the exposure sits at the intersection of content access, secrets handling and integration risk. Accountability should include who approved the access model, who owns the leaked secret and who can revoke any downstream credentials.
Why This Matters for Security Teams
When ServiceNow exposes credentials or internal records, the failure is rarely a single misstep. It usually combines content access, secret handling and integration design, which means accountability cannot sit with one team alone. The platform owner may control configuration, the data owner defines sensitivity, and identity governance owns revocation, review and access boundaries. For broader context on how leaked secrets become a systems issue, see 52 NHI Breaches Analysis and the Guide to the Secret Sprawl Challenge.
Practitioners should also treat this as an identity problem, not just a SaaS incident. If a leaked token can be reused elsewhere, the blast radius extends into downstream tooling, automation and privileged workflows. That is why the question of “who is accountable” needs to include who approved the access model, who owns the credential lifecycle and who can prove revocation actually happened. Standards guidance from the OWASP Non-Human Identity Top 10 and NIST SP 800-63 Digital Identity Guidelines reinforces that identity assurance depends on explicit lifecycle control, not assumptions about platform safety. In practice, many security teams encounter shared accountability only after leaked credentials have already been replayed into adjacent systems.
How It Works in Practice
The most reliable operating model is to assign accountability across three layers. First, the platform owner is responsible for configuration, logging, integration hygiene and the security posture of the ServiceNow instance. Second, the data owner decides what data is permitted in workflows, forms, knowledge articles and exports, and should classify anything that can become sensitive once exposed. Third, identity governance owns entitlement review, secret rotation, revocation and evidence that downstream access was removed.
In concrete terms, that means every ServiceNow integration should have a named secret owner, a documented business purpose and a revocation path. If a token is used by a connector, bot or script, its lifecycle should be shorter than the process it supports. Current best practice also leans toward separating human admin access from machine access, so a compromised admin session does not automatically expose long-lived integration secrets. The Shai Hulud npm malware campaign and Reviewdog GitHub Action supply chain attack show how quickly exposed secrets can be harvested once they leave their intended boundary.
- Define ownership for the platform, the data and each integration secret.
- Use least privilege and separate roles for admin, data steward and revoker.
- Rotate credentials on a schedule and immediately after exposure.
- Log who approved access, who used it and who removed it.
For implementation detail, use the Anthropic report on the first AI-orchestrated cyber espionage campaign as a reminder that autonomous tooling can turn one exposed credential into a broader intrusion chain. These controls tend to break down when ServiceNow is connected to legacy scripts, shared service accounts and undocumented outbound integrations because revocation cannot be verified across every consumer.
Common Variations and Edge Cases
Tighter accountability often increases operational overhead, so organisations must balance faster remediation against cleaner ownership boundaries. That tradeoff matters most where ServiceNow is used as a workflow hub for multiple teams, because permissions and secrets are often reused to keep business processes moving.
There is no universal standard for this yet, but current guidance suggests a few recurring exceptions. If the leaked data is purely operational metadata, the data owner may be less exposed than when tickets contain incident notes, API keys or customer records. If a contractor or systems integrator created the integration, accountability still sits with the organisation that approved the access and retained the risk. If the secret lives outside ServiceNow but is injected into it through a connector, then the original secret owner must still participate in containment and rotation. The Cisco Active Directory credentials breach and New York Times breach illustrate how internal exposure often becomes an identity and access issue long before it becomes a platform-only issue.
Security teams should also distinguish between accountability for the incident and accountability for the control failure. The first is about triage, containment and disclosure. The second is about whether access reviews, secret handling rules and revocation workflows were actually in place. In real environments, the messy cases are shared admin models, inherited integrations and stale tokens that nobody can confidently map back to one owner.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST CSF 2.0 and NIST AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-03 | Shared ownership and secret rotation are core NHI control concerns. |
| NIST CSF 2.0 | PR.AC-4 | Least-privilege and access lifecycle control fit this accountability question. |
| NIST AI RMF | Accountability across platform, data and identity is a governance requirement. |
Document decision ownership, escalation paths and incident responsibilities for every ServiceNow integration.
