Accountability should sit with the identity and security function that can enforce lifecycle control, session oversight, and revocation. Contractors and service teams should not be treated as exceptions to the governance model. If they can access databases, they must be included in the same approval, monitoring, and offboarding discipline as employees.
Why This Matters for Security Teams
Database access accountability is often blurred when contractors or service teams are involved because ownership gets split between operations, procurement, and application support. That split is dangerous: the party that can request access is not necessarily the party that can enforce revocation, review sessions, or prove why access still exists. NHI Mgmt Group’s Ultimate Guide to NHIs shows that 92% of organisations expose NHIs to third parties, which turns “temporary” access into a persistent governance gap if no single owner is accountable. The problem is not just trust, but lifecycle control, auditability, and rapid offboarding. In practice, many security teams discover this only after contractor access outlives the engagement or a service team retains direct database rights long after the original need has changed.
How It Works in Practice
The cleanest model is to assign accountability to the identity or security function, then require the contractor sponsor or service owner to supply the business justification and operational context. That means the owner of record is responsible for approval workflow, expiry dates, periodic review, and revocation evidence, while the consuming team remains responsible for the operational need. This aligns with the broader NHI governance pattern described in Ultimate Guide to NHIs — Key Challenges and Risks and the access-control expectations reflected in the OWASP Non-Human Identity Top 10.
Operationally, strong accountability usually includes:
- Named owner for every database credential, service account, or privileged access path.
- Time-bound access approvals with automatic expiry for contractors and external service teams.
- Session logging and review for direct database access, not just ticket approval.
- Offboarding checks that revoke database rights, tokens, API keys, and vault entries together.
- Periodic recertification that verifies the access is still needed and still mapped to a current engagement.
Where possible, use PAM, JIT provisioning, and workload identity rather than shared passwords or long-lived static secrets. This reduces ambiguity over who “owns” the access because the identity system becomes the control point, not an informal team agreement. These controls tend to break down when contractors inherit shared accounts or when service teams use emergency access paths that bypass normal approval and revocation workflows.
Common Variations and Edge Cases
Tighter accountability often increases administrative overhead, requiring organisations to balance speed for delivery teams against the risk of orphaned database access. That tradeoff becomes sharper with vendors, managed services, and “break glass” support arrangements, where operational urgency can tempt teams to bypass normal ownership rules. Current guidance suggests the same baseline still applies: if the account can reach production data, it needs a single accountable owner, documented purpose, and an expiry mechanism.
There are two common exceptions to think through carefully. First, if a service team administers the database platform itself, accountability may sit with platform security or infrastructure governance, but the access must still be explicitly approved and logged. Second, if a contractor is using ephemeral access through a brokered workflow, the sponsor can own the business need while identity security owns the control plane. The account may change hands, but accountability should not disappear. This is especially important when offboarding is weak; NHI Mgmt Group notes that only 20% of organisations have formal processes for revoking API keys, which is a warning sign for any environment that relies on external labour or outsourced operations. In practice, ownership failures surface fastest in shared service environments with overlapping admin rights and no clear revocation authority.
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-01 | Directly addresses ownership and governance of non-human access paths. |
| NIST CSF 2.0 | PR.AC-1 | Identity and access management needs clear ownership for contractor and service access. |
| NIST AI RMF | Governance and accountability are core when access decisions span multiple operational teams. |
Establish accountable ownership, review cadence, and escalation paths for all non-employee database access.
Related resources from NHI Mgmt Group
- Who should own access decisions when service management and IAM are connected?
- Why do self-service portals create governance risk when access is involved?
- How should security teams govern access requests through IT service management tools?
- How do IAM teams decide whether an AI security assistant needs its own access controls?
