Who should approve temporary privileged access when a third-party team needs DBA rights on a production system?

A designated internal approver should own the decision, not the external contractor. The approver needs authority to review the request, confirm the task scope, and reject anything outside policy. This separation preserves accountability, keeps privilege decisions inside the security boundary, and ensures elevated access is granted only for the intended maintenance window.

Why This Matters for Security Teams

Temporary DBA access is one of the clearest places where good intent can still create serious exposure. Production databases sit inside a high-value trust boundary, so the approval step is not administrative paperwork, it is the control that decides whether elevated privilege is justified, scoped correctly, and traceable back to an accountable internal owner. The wrong approver can turn a limited maintenance request into an open-ended access exception.

That matters most when a third-party team is involved, because the external operator may understand the task better than the business risk. Internal approval keeps the decision inside the organisation’s security boundary and preserves a clear separation between the person requesting access and the person authorising it. In practice, many access failures begin as routine maintenance requests that were approved too quickly, with too little scrutiny of scope, timing, or post-task removal.

One useful benchmark is that 97% of NHIs carry excessive privileges, which reinforces how often organisations grant more access than they intended and then struggle to constrain it later.

How It Works in Practice

The approval should sit with a designated internal approver who owns both the business justification and the security decision. In most mature environments, that is the system owner, database owner, or a delegated internal manager operating under policy, often with security or PAM oversight for higher-risk changes. The third-party team can explain the work, but it should not be the final authority on whether DBA rights are granted.

Good practice is to treat the approval as a controlled access decision, not a conversation. The approver should confirm four things before granting access:

• the task is legitimate and tied to a specific change, incident, or maintenance window;
• the requested privilege level is the minimum needed for the job;
• the duration is temporary and clearly bounded;
• the access path is logged, monitored, and removed after use.

Where possible, access should be time-boxed and issued through a governed workflow rather than by informal email or chat approval. That makes it easier to verify who authorised the exception, what scope was approved, and whether the privilege was actually revoked at the end of the window. For third-party work, the approval record should also identify the named internal owner who will answer for the decision later if the access was misused or the task exceeded scope.

Operationally, this works best when the approver is empowered to say no. If the request lacks a clear change ticket, the scope is vague, or the vendor asks for standing DBA rights instead of a limited window, the request should be revised before approval. These controls tend to break down in fast-moving production incidents where teams bypass the workflow and grant access first, then try to document the decision afterward.

Common Variations and Edge Cases

Tighter approval control often increases coordination overhead, so organisations have to balance speed against accountability. The right approver can vary by environment, but the principle does not change: the person approving temporary DBA access should be internal, authorised, and able to judge whether the exception fits policy.

There are a few common edge cases. In emergency recovery, an internal incident commander may authorise access on behalf of the normal owner, but that delegation should still remain inside the organisation. In managed service arrangements, a third-party may operate the platform, but approval should still come from the customer side when the system is production and the privilege is materially sensitive. For regulated environments, the approval trail often needs to show separation of duties as well as time limitation.

Where teams confuse technical expertise with approval authority, access tends to drift. The contractor may know exactly which command is needed, but that does not make the contractor the right approver. The approval decision belongs to the party accountable for the production system, while the requester provides the task rationale and the approver constrains the privilege to the minimum viable window.

Practitioner Guidance

What to prioritise: Make the approval owner explicit in the access workflow. If a third party can request DBA rights, the organisation should still have one named internal approver responsible for validating scope, duration, and business need before access is issued.

What to verify: Check that the approval record shows who authorised the access, what maintenance task justified it, when the privilege expires, and how revocation is confirmed. If any of those fields are missing, the approval is not yet audit-ready.

Decision rule: If the request is open-ended, recurring, or broad enough to function like standing access, treat it as a governance problem rather than a temporary privilege request and escalate it for redesign.

Practitioner takeaway: temporary privileged access is safest when the approver is the accountable internal owner, because the control failure is rarely the grant itself, it is the drift from a bounded exception into unmanaged production authority.

Related resources from NHI Mgmt Group

• How can organisations secure third-party privileged access in hybrid environments?
• Should organisations treat third-party access as a privileged identity risk?
• When should organisations treat third-party SaaS access as privileged access?
• Who is accountable when third-party or machine access is over-privileged?