Database superuser grants drift faster than any other privilege, and generic access reviews rarely look inside the database engine where they live. A quarterly certification in the identity governance tool might confirm that a DBA still needs "production database access", yet never ask who holds sysadmin, GRANT OPTION, SYSDBA or SUPERUSER, or who used the break-glass login last month. This template is a ready-to-use procedure for a recurring database privileged access review: what to extract from each engine, who certifies it, what evidence to keep and how to remove access that fails. It is for DBA managers, IAM and PAM teams and internal auditors. The review method itself (campaign design, reviewer fatigue, closing the loop) is in the Access Reviews Guide; the operating model for DBA access is in DBA Privileged Access. This page does not repeat them.
How to use this template
- Replace the placeholders: [Organisation], [Review owner], [Database platform owner], [PAM tool], [Ticketing system] and the timings in square brackets.
- Set the scope list first: fill in the inventory table in section 2 before the first campaign. A review is only as good as the list of instances it covers.
- Keep the extraction queries with the template: section 4 lists the catalog views each engine exposes. Your DBAs should turn these into saved, read-only reports so every cycle pulls the same data the same way.
- Adjust frequencies to your obligations: the quarterly cadence below is our NHI Mgmt Group recommendation for production privileged access; SOX in-scope systems or regulated data may need your auditors' agreed cadence instead.
- Store the completed record: each cycle produces the evidence pack in section 8. Keep it with your other access review evidence.
1. Purpose and scope
1.1 This procedure sets how [Organisation] reviews and certifies privileged access to database engines and managed database services, so that only named, approved and currently needed identities hold administrative rights.
1.2 It covers every production and production-equivalent database instance (including replicas, disaster recovery copies and restored copies holding live data), on premises and in cloud managed services, and every identity type: named DBA accounts, shared or built-in administrative logins, groups mapped to administrative roles, service accounts, application accounts holding elevated rights and automation such as migration pipelines.
1.3 Non-production instances that hold copies of production data are in scope. Purely synthetic test instances are out of scope unless [Review owner] adds them.
2. Inventory and privileged definitions
2.1 [Database platform owner] maintains the in-scope instance list below, reconciled each cycle against the CMDB and cloud account inventories.
| Instance or service | Engine and version | Environment | Data classification | Business owner | Technical owner | Regulatory scope |
|---|---|---|---|---|---|---|
| [instance name] | [engine, version] | [Production / DR / copy] | [classification] | [name] | [name] | [SOX / PCI DSS / none] |
2.2 For this procedure, a grant is privileged if it appears in the table below or lets the holder grant rights to others, change security or audit settings, read all data regardless of object grants, or stop the service.
Engines are listed alphabetically; the order is not a ranking.
| Engine | Treat as privileged (minimum list) | Where to read it |
|---|---|---|
| Microsoft SQL Server | sysadmin; securityadmin (Microsoft says to treat it as equivalent to sysadmin); serveradmin; setupadmin (linked servers); bulkadmin; dbcreator; ##MS_LoginManager##, ##MS_DatabaseManager## and ##MS_SecurityDefinitionReader## (SQL Server 2022 and later); db_owner in each database; CONTROL SERVER | sys.server_role_members joined to sys.server_principals; sys.server_permissions; sys.database_role_members per database |
| MySQL | SUPER (deprecated); SYSTEM_USER; CONNECTION_ADMIN; SYSTEM_VARIABLES_ADMIN; ROLE_ADMIN; SET_USER_ID; FILE; PROCESS; SHUTDOWN; GRANT OPTION; global (*.*) grants | SHOW GRANTS per account; mysql.user for static global privileges; mysql.global_grants for dynamic privileges |
| Oracle Database | SYSDBA, SYSOPER, SYSASM, SYSBACKUP, SYSDG, SYSKM; the DBA role; ANY system privileges; GRANT ANY PRIVILEGE and GRANT ANY ROLE | V$PWFILE_USERS (one column per administrative privilege, plus ACCOUNT_STATUS and LAST_LOGIN); DBA_ROLE_PRIVS; DBA_SYS_PRIVS |
| PostgreSQL | SUPERUSER; CREATEROLE; REPLICATION; BYPASSRLS; CREATEDB; membership of roles holding these; ADMIN OPTION on role grants | pg_roles (rolsuper, rolcreaterole, rolreplication, rolbypassrls, rolcreatedb, rolcanlogin, rolvaliduntil); pg_auth_members |
| Cloud managed instances | The provider's initial administrative user (for example the Amazon RDS master user, which receives rds_superuser on RDS for PostgreSQL and the DBA role on RDS for Oracle; the Azure SQL Database server admin and Microsoft Entra admin); plus the cloud control plane roles that can reset those passwords | The engine views above, plus the cloud IAM policy or role assignments on the database resource |
2.3 Engine privileges change between versions. [Database platform owner] confirms the list against the vendor documentation for each version in the inventory at least once a year.
3. Roles and responsibilities
| Role | Responsibility in the review |
|---|---|
| [Review owner] (IAM or GRC) | Runs the campaign, tracks completion, escalates overdue decisions, signs off the evidence pack |
| [Database platform owner] | Produces the extracts, explains each grant, carries out removals, confirms removal |
| Line manager of each named holder | Confirms the person still needs the role for their current job |
| Data or business owner | Certifies access to their data for non-DBA holders (analysts, application accounts with elevated rights) |
| Service owner | Certifies each service, application or automation account, its purpose and its secret storage |
| Independent reviewer (security or internal audit) | Certifies DBA team members, since a DBA manager approving their own team's sysadmin rights is a segregation of duties gap |
3.1 No one certifies their own access. Reviewers who hold the privilege under review are replaced by the next level of management or by the independent reviewer. See the Segregation of Duties Guide.
4. Extraction
4.1 [Database platform owner] runs read-only extraction reports against every in-scope instance during the first [5] working days of the cycle and records the run time, the account used and the instance list covered.
4.2 Extracts are taken from the engine catalog, not from the identity governance tool or the PAM vault alone. Grants made directly in the database (outside the provisioning process) only show up here.
4.3 For each privileged grant the extract records: instance, principal name, principal type (login, user, role, group, certificate or external), privilege or role held, how it is held (direct or through role membership, including nested roles), authentication type, account status, created date where the engine records it and last login where available.
4.4 Group-mapped access is expanded. Where a Windows or Microsoft Entra group, an LDAP group or a cloud IAM group maps to an administrative role, the extract lists the group's current members from the directory.
4.5 Last-use evidence is gathered from [PAM tool] session logs and database audit logs for the review period. Note that some engines do not populate last login for every connection type: Oracle documents that V$PWFILE_USERS.LAST_LOGIN is not populated for administrative-privilege connections except remote sessions with the 12.2 password file format. Where the engine view is blank, use the audit trail. See the Database Audit Log Detection Guide.
5. Review questions
5.1 Reviewers answer these questions for each grant. Any "no" or "unknown" is a revoke unless an exception is approved under section 7.
| # | Question | Evidence the reviewer sees |
|---|---|---|
| Q1 | Is this a named, individually owned identity, or a documented shared or built-in account with a named owner? | Principal name, owner field, HR record |
| Q2 | Does the holder's current role need this level of privilege, rather than a narrower role (for example ##MS_ServerStateReader## instead of sysadmin, or a dynamic MySQL privilege instead of SUPER)? | Job role, privilege held, narrower options from section 2 |
| Q3 | Was the privilege used in the review period? | Last login, PAM sessions, audit events |
| Q4 | Is the grant standing, or is it issued just in time through [PAM tool]? | Grant type, PAM policy |
| Q5 | Is it held directly or through a group or role whose membership is governed elsewhere? | Grant path from 4.3 and 4.4 |
| Q6 | For service and application accounts: is the purpose documented, is the secret in an approved vault, and is interactive login blocked? | Service account record, vault entry, login restrictions |
| Q7 | Can the holder change or disable the audit that records their own actions? | Audit configuration ownership |
5.2 Application accounts are held to a stricter test: an application should not run as the initial administrative user. AWS, for example, recommends against using the RDS master user directly in applications and advises a separate user with only the privileges the application needs. See the Service Account Security Guide.
6. Built-in, shared and emergency accounts
6.1 Built-in administrative logins (sa, postgres, SYS and SYSTEM, root, the cloud initial administrator) are reviewed every cycle even when unchanged. For each, record: whether it is enabled, where its credential is stored, who can check it out, and every use in the period.
6.2 Each recorded use of an emergency or break-glass account must match an incident or change ticket in [Ticketing system]. Any use without a ticket is raised as a security incident, and the credential is rotated after every use. See the Break Glass Access Procedure Template.
6.3 Accounts that cannot be limited (for example, Microsoft documents that the Azure SQL Database server admin login has all available permissions and cannot be limited) are held as emergency credentials, not used for daily work, and named in the evidence pack with their custody arrangements.
6.4 Cloud control plane roles that can reset the database administrator password are reviewed alongside the database, because they are an indirect route to the same access.
7. Decisions, removal and exceptions
- Decision options: Certify, Reduce (replace with a narrower role), Convert (move to just-in-time through [PAM tool]) or Revoke.
- Removal deadline: revocations are completed within [5] working days of the decision; [2] working days for leavers and for accounts with no identifiable owner. These targets are our recommendation.
- Removal method: removals go through the normal change process as standard changes, with the DBA recording the exact statement or console action used.
- Confirmation: [Database platform owner] re-runs the extract for the affected instance after removal and attaches the result. A ticket closed without a fresh extract is not closed.
- Exceptions: an exception needs a business justification, compensating controls (session recording, alerting, extra logging), an owner and an expiry no later than the next cycle. Exceptions are re-reviewed, never rolled over automatically.
- Escalation: decisions outstanding after [10] working days go to [CISO or equivalent]. Undecided grants are revoked at the cycle close unless the CISO records a decision.
8. Evidence pack
8.1 Each cycle produces and retains for [retention period]:
- Scope: the instance list and its reconciliation against the CMDB and cloud inventories.
- Extracts: raw outputs with run time, account used and a hash of each file.
- Decisions: each grant with reviewer, decision, date and reason.
- Removals: change tickets and post-removal extracts.
- Emergency use: each use of a built-in or break-glass account matched to its ticket.
- Exceptions: the register with expiry dates.
- Sign-off: [Review owner] and [Database platform owner] sign-off, with metrics from section 9.
9. Metrics
| Metric | How to measure | Target (our recommendation) |
|---|---|---|
| Coverage | In-scope instances extracted / instances in the inventory | 100% |
| Standing privileged grants | Count of standing sysadmin, SUPERUSER, SYSDBA, DBA and equivalent grants to humans | Falling each cycle |
| Unused privilege | Privileged grants with no use in the period / all privileged grants | Under 10% |
| Removal time | Median days from revoke decision to confirmed extract | 5 working days or fewer |
| Out-of-band grants | Privileged grants found in extracts with no provisioning record | Zero |
| Unmatched emergency use | Break-glass sessions without a ticket | Zero |
10. Approval and review of this procedure
10.1 This procedure is owned by [Review owner], approved by [CISO or equivalent] and reviewed annually or after a material change to the database estate. Version: [x.y]. Approved: [date].
Implementation guidance
Start with one engine and one environment. Run the first cycle on production instances of your most common engine, prove the extract and removal steps work end to end, then add engines. The first cycle typically finds grants that no one can explain; give it longer timescales and treat it as a clean-up rather than a pass or fail.
Automate the extract, not the decision. Saved read-only queries feeding your identity governance tool or a spreadsheet are fine. The decision stays with a human who understands the job, and the confirmation step (a fresh extract after removal) is what auditors test.
Reduce the population before you review it. Every grant converted to just-in-time elevation through [PAM tool] leaves fewer standing grants to certify. MySQL documents dynamic privileges that replace the deprecated SUPER, and SQL Server 2022 adds ##MS_ roles that cover common operational tasks; moving holders to these narrower options is often the quickest win. See the Least Privilege Techniques Guide and the engine guides for Microsoft SQL Server Security Guide, MySQL Security Guide, Oracle Database Security Guide and PostgreSQL Security Guide.
Common mistakes. Reviewing the identity governance entitlement ("prod DB admin group") without expanding what it grants inside each instance; skipping DR replicas and restored copies; leaving PostgreSQL CREATEROLE out of scope (PostgreSQL documents that a CREATEROLE user holding ADMIN OPTION on a role can grant that role back to itself and gain its privileges); certifying service accounts by name without checking where their secrets live; and closing removals without a fresh extract.
Framework mapping. NIST SP 800-53 Rev. 5 AC-2 Account Management, AC-6(5) Privileged Accounts, AC-6(7) Review of User Privileges, AC-6(9) Log Use of Privileged Functions, AC-5 Separation of Duties and AU-9(4) Access by Subset of Privileged Users; NIST CSF 2.0 PR.AA-05. For SOX in-scope databases see the SOX IT General Controls (ITGC) Guide.
References. Microsoft: Server-level roles (SQL Server) · Microsoft: Authorize database access to SQL Database · MySQL: Privileges provided by MySQL · MySQL: Grant tables · Oracle: V$PWFILE_USERS · PostgreSQL: Role attributes · AWS: Master user account privileges (Amazon RDS) · NIST: SP 800-53 Rev. 5
Related NHI Mgmt Group resources: DBA Privileged Access · Access Reviews Guide · Access Review Checklist · Privileged Access Management Guide · Database Security Guide