A read-only review of your MySQL estate against CIS Benchmark guidance, known CVEs, privilege structures, and encryption. You receive an engineer-led, prioritised remediation plan written so QSAs, or internal security teams can act without translation.
The real buying moment is rarely a vague worry — it is a specific compliance event with a date on it. If one of these is yours, the database section is usually the part nobody owns.
PCI DSS 4.0 is now the only version in force, so the “we passed under 3.2.1” position is gone. We review the requirements that land on the database: stored-data protection, access reviews, application-account credential handling and automated log review.
We produce the evidence for the database rows — the access matrix, the encryption and key-handling position, the log retention window — so you answer from a document rather than from memory.
The requirement cascades to processors. We audit your side and give you something to attest with — findings, not assurances.
A network finding is a symptom. We audit the engine: privilege structure, authentication plugins, network exposure and the CVE surface of your exact version.
Rule 6 names encryption, masking and tokenisation, access control, and logs retained for one year. Most MySQL estates are not configured for it. Obligations bite in May 2027, with a proposal to bring that forward to November 2026 under consideration.
The most common trigger of all. Being secure and being provable are different problems. The audit turns your current posture into dated, sampled evidence in a form an assessor accepts.
This is engine-level review, not a generalist compliance checklist. Each domain maps to findings your auditor asks about and your team can act on.
Every account and its effective grants, including inherited and wildcard privileges. Shared admin accounts, accounts without passwords, % host grants, orphaned application users, and service accounts whose credentials live in application config. Authentication plugin configuration and password policy.
TLS enforcement on client connections and on replication channels, certificate validity and cipher configuration. At rest: InnoDB tablespace encryption, keyring configuration and key separation, binary-log and backup encryption. Where disk-level encryption is the only protection, we say so plainly — for regulated data it is usually not sufficient alone.
We map your configuration against the CIS Benchmark for your MySQL version — CIS currently publishes benchmarks for MySQL Community and Enterprise 9.7, 8.4, 8.0, 5.7 and 5.6 — and report Level 1 and Level 2 findings separately, with a judgement on which Level 2 controls are worth the operational cost in your environment.
Known vulnerabilities affecting your exact version and build, with a triage: patch now, schedule, or compensate when patching is blocked. Includes support-lifecycle exposure. MySQL 8.0 moved to Oracle Sustaining Support on 21 April 2026; on Amazon RDS standard support ended 31 July 2026, with paid Extended Support to 31 July 2029. On 8.0, 8.4 is a mandatory stop — Oracle does not support skipping an LTS series.
Whether the audit log is configured to capture what your framework requires, whether it survives rotation, where it ships, and how long it is retained. This is where compliance programmes most often fail — Requirement 10 logging gaps produce more findings than missing patches — and it is the one thing a scanner cannot assess for you.
Listener exposure, firewall and security-group position, bastion and jump-host arrangements, proxy-layer configuration, and whether the replication topology and backup path introduce routes around your access controls.
Every firm in this category names frameworks. We map to the specific control — and to the exact MySQL artefact that satisfies it. That is the difference between a report and a checklist.
| Framework | Control we map to | The MySQL artefact |
|---|---|---|
| PCI DSS 4.0 | 3.5.1.2 — disk encryption alone is not sufficient for stored PAN on non-removable media | InnoDB TDE with keyring separation, or column-level encryption |
| PCI DSS 4.0 | 7.2.4 — access reviews every six months | Documented GRANT review with a repeatable extract |
| PCI DSS 4.0 | 8.6.x — application and system account credential management | Service-account inventory; credentials out of application config |
| PCI DSS 4.0 | 10.4.1.1 — automated audit-log review | audit_log shipping to your SIEM, with failure detection |
| HIPAA | §164.312(b) Audit Controls — a standard with no addressable escape hatch | A demonstrable mechanism recording and examining ePHI activity |
| HIPAA | §164.312(a)(1) Access Control | Unique user identification; emergency access procedure |
| GDPR | Art. 32(1)(d) — regularly testing and evaluating the effectiveness of measures | Why a recurring database audit is a legal obligation, not a discretionary spend |
| GDPR | Art. 32(1)(c) — restoring availability in a timely manner | Tested restores with an actual RTO/RPO, not a documented intention |
| India DPDP Rules 2025 | Rule 6(1)(a) — encryption, obfuscation, masking or virtual tokens | Column encryption; masked non-production copies |
| India DPDP Rules 2025 | Rule 6(1)(c) and 6(1)(e) — access logging, retained one year | Audit-log configuration and retention |
| RBI IT Directions 2023 | Para 19 — MFA for privileged users of critical information systems | Privileged-access review; elevated activity logged |
| RBI IT Directions 2023 | Para 26 — VA every six months, PT annually, by independent experts | Why an external assessment satisfies the wording |
| ISO 27001:2022 | A.8.15 Logging · A.8.16 Monitoring activities | Log coverage mapped to Annex A clause numbers |
We do not issue compliance certifications, and we are not your auditor. We give your auditor findings they do not have to take on trust.
Not a scan dump — a structured report with named sections, each written for the person who has to act on it.
Risk position in one page, for the person who signs off remediation.
Every finding with a severity, the affected object, the evidence, and the fix.
Control-by-control, Level 1 and Level 2 separated, with justified exceptions.
Version-specific, with a sequenced upgrade path where an upgrade is the real fix.
The extract your auditor asks for, in a form you can re-run yourself.
Where the topology undermines the controls, and how to close the gap.
Bucketed 0–30 days / 1–6 months / 6–24 months, each item costed in effort.
A working session to talk your team through the findings, the severities, and the plan.
Five steps, with the three things buyers actually ask about stated up front: what access we need, how much of your time it takes, and the risk to production.
| Step | What happens | Your effort |
|---|---|---|
| 1Scoping call | Instances, versions, platforms, and which framework you are answering to. | 45 min |
| 2Read-only access | Read-only credentials, your access route. No agent, no config change, no restart. | 30 min |
| 3Collection & review | Standard monitoring and information-schema queries. 100% non-invasive and read-only — negligible production impact. | None |
| 4Report & walkthrough | Findings, severities, remediation roadmap, and a live session to walk through it. | 60 min |
| 5Remediation | Optional, separate engagement — under no obligation. | Your call |
Free tools exist and they are good at what they do — a config scanner will hand you a long list of what is technically non-compliant. What it cannot do is tell you which of those findings matter, which you can safely act on, and how to defend the ones you cannot fix. That is the work.
A scanner will tell you local_infile is enabled. It will not tell you which application breaks when you disable it. Most CIS Level 2 controls carry an operational cost, and some are simply wrong for your workload.
Every real estate has controls it cannot meet. The finding that matters is the documented, justified exception — and that is a written argument, not a scan result.
Whether your audit log survives rotation. Whether replication traffic is encrypted end to end. Whether the backup path bypasses your access controls. Whether the privilege you granted three years ago is still in use.
Published Mydbops engagements where security, masking, and encryption were the driver, not borrowed proof from cost or performance projects.
On-premise MySQL and PostgreSQL under heavy regulatory scrutiny. We built automated masking across 20 hardened nodes, achieving 100% automated compliance and $20M+ of risk neutralised.
Read full case study →
A compliance-driven MySQL 5.6→5.7 migration with Transparent Data Encryption, proving that encryption at rest can be delivered on a live payment platform without an outage.
Read full case study →
A MySQL 8.4 LTS upgrade that swapped RDS Extended Support fees for six years of guaranteed security compliance. “Critical security patches through April 2032”, confirms Salsan Jose, CTO.
Read full case study →Mydbops has been instrumental in scaling our data infrastructure securely and reliably as we grew to serve one of India’s largest gaming audiences.
Their handling of stability and disaster recovery has kept our platform dependable for more than 100,000 customers.
The people reading your grants and cipher configuration run MySQL estates for a living. The credentials below are countable, and they sit at company level.
The team that implements the critical fixes your audit surfaces — a separate, quoted engagement.
Explore consulting →Continuous, secure management of your MySQL estate under least-privilege, NDA-backed access.
Explore remote DBA →End-to-end operation of your database environment when you want the whole thing off your plate.
Explore managed services →Tell us your MySQL versions, platforms, and which framework you are answering to. We will scope a read-only audit and hand your auditor findings they do not have to take on trust.
Book a scoping call →