Reviews lose comparability, so teams end up certifying different privilege models with different levels of detail and different approval paths. That creates blind spots around overbroad grants, dormant accounts, and access that was changed informally outside the normal process. The control fails because the evidence is fragmented.
Why Separate PostgreSQL and MySQL Review Paths Break Control Comparability
When database access reviews split along engine lines, the review ceases to be one control and becomes two different audit exercises. PostgreSQL and MySQL often express privilege in different objects, scopes, and administrative habits, so the reviewer is no longer judging the same thing with the same evidence. That makes it hard to tell whether access is consistently justified or merely differently documented.
The practical failure is not just administration overhead. A split review model encourages teams to compare unlike cases as if they were equivalent, which weakens certification quality and makes exception handling harder to defend. The result is a control that may look complete on paper while hiding inconsistent standards underneath.
Teams usually notice the problem first in the evidence package. One database may show granular role membership and explicit grants, while the other relies on broader inherited access or legacy conventions, so the reviewer cannot cleanly compare entitlement scope, approval rigor, or recertification logic across platforms.
What Becomes Invisible When Privilege Models Are Reviewed in Isolation
Once the review is siloed, blind spots appear around overbroad grants, dormant accounts, and informal changes that never re-enter the normal approval path. The issue is often not that one database is uniquely risky, but that the organisation loses a single view of who can do what across both engines.
That is especially important because access review is supposed to answer one governance question: is this access still required, still appropriate, and still aligned to role or function? If the answer depends on which engine the account happens to live in, the control is measuring process variance instead of entitlement risk.
Fragmented review also makes drift harder to detect. A privilege that would trigger concern in one platform may be accepted in the other because the reviewer is comparing against a different template, a different approver, or a different depth of evidence. Over time, that turns exceptions into local custom rather than managed risk.
For a broader view of how access certification should stay comparable across systems, the Access Reviews and Certification Guide is a useful reference point, and the IAM and IGA Basics guide explains why entitlement review only works when the governance model is consistent.
How to Rebuild a Single Review Standard Across Database Platforms
The fix is to standardise the decision model, not the database syntax. The review should ask the same questions for PostgreSQL and MySQL: who owns the access, what business function requires it, what level of privilege is actually needed, and what evidence justifies continuation.
That means normalising entitlement descriptions into common business categories before certification, so reviewers see comparable access profiles even if the underlying permissions differ. It also means defining the approval path once, instead of letting each platform inherit its own informal threshold for what counts as acceptable access.
Where platform-specific detail matters, keep it as supporting evidence rather than the basis of the decision. Reviewers need enough technical context to spot excessive privilege or stale accounts, but the governance question should remain stable across both systems. If the control cannot survive that abstraction, it is too platform-specific to be a reliable certification control.
Practitioners often get better results when they pair database review with role design and lifecycle discipline. The Role Mining and Role Design Guide helps reduce ad hoc privilege shapes, while the Joiner-Mover-Leaver (JML) Guide is useful when access changes need to stay aligned with employment and function changes over time.
Risk and Threat Considerations
Separate review tracks increase the chance that excessive database privilege, dormant accounts, or unapproved changes survive because no one is comparing like with like. The control failure is usually cumulative, not dramatic: each engine looks governable on its own, but the organisation loses a single evidence trail for access assurance.
Failure mechanism: Differences in privilege structure, reviewer judgment, and approval workflow create fragmented evidence, so weak access can pass certification in one path even when it would be challenged in the other.
Impact: Overbroad grants, stale access, and informal privilege changes can persist longer, raising the likelihood of unauthorized data access and weakening auditability.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5 sets the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | AC-2 — Account Management | Database access reviews depend on consistent account and entitlement review across platforms. |
| AC-6 — Least Privilege | The question centers on overbroad grants and privilege creep in database access review. | |
| AU-6 — Audit Review, Analysis, and Reporting | Fragmented evidence and inconsistent review trails are the control failure described. | |
| Recommendation — Standardize review criteria for database accounts and entitlements across both engines. Review database grants against least-privilege requirements before recertifying access. Consolidate audit evidence so reviewers can compare access decisions consistently. | ||
| ISO/IEC 27001:2022 | A.5.15 — Access control | The topic is fundamentally about consistent access control governance across databases. |
| A.5.18 — Access rights | Periodic review of database access rights is the core governance activity discussed. | |
| Recommendation — Apply one access-control policy and review standard across PostgreSQL and MySQL. Recertify database access rights on one schedule using one entitlement model. | ||
Practitioner Guidance
What to verify: Require one certification standard for both PostgreSQL and MySQL, with shared entitlement categories, shared approval criteria, and a common definition of excessive privilege. If reviewers cannot explain why two similar accounts were handled differently, the control is not yet consistent.
What good looks like: The reviewer sees one comparable access record per user or service, regardless of engine, and can trace each decision back to the same governance rule set. Platform detail should inform the judgment, not redefine the control.
Common mistake: Treating database-specific admin habits as a substitute for standardised access governance. That usually produces clean-looking reports with weak comparability, which is exactly how overprivilege and stale access slip through.
Practitioner takeaway: The goal is not to make PostgreSQL and MySQL identical, but to make their access reviews comparable enough that governance can spot exceptions instead of inheriting them.
Related resources from NHI Mgmt Group
- What breaks when access reviews and certifications are handled separately for each cloud platform?
- How should security teams run access reviews for non-human identities?
- When do NHI access reviews create more value than a one-time cleanup?
- What breaks when vendor access reviews are handled manually at scale?