Note that these requirements must also apply to UNIX systems administrators and anyone else with root access.
Any root or superuser rights must be tied to a specific, documented business need.
Access must follow the principle of least privilege.
“Just in case” access is not compliant.
Approval workflow — documented request and managerial approval before escalation.
Root access must be tied to individual identities — no shared root accounts without unique tracking (e.g., using sudo with named accounts).
Use of root must be tied back to an individual (via sudo with logging or a PAM solution).
Use named accounts for daily DBA work; escalate to root via sudo only when necessary.
All commands run with root or DBA superuser privileges must be logged and monitored, and reviewed.
Capture who elevated privileges, what commands they ran, and when.
PCI DSS 4.0 explicitly calls for audit trails that include the user ID, type of event, and timestamp.
Real-time alerts for sensitive commands.
Audit everything — central logging (e.g., SIEM) for all privileged commands.
Review the logs.
See also: CyberArk, BeyondTrust, Teleport
Policies must define when and how root access is granted.
Approval must be documented and time-bound (no permanent standing root unless justified).
Where possible, split admin duties between OS admins and DBAs so that no single person can bypass all controls.
If DBAs need root for patching or performance troubleshooting, it should be temporary, with privilege escalation and automatic expiry.
Just-in-time access — grant root rights for a limited duration and revoke automatically.
Segregate environments — production, staging, and development must have separate credentialing.