A PCI-DSS audit lives or dies on what your database logs, encrypts, and restricts, not on what your firewall does. This guide walks through the exact sequence to get a MySQL, PostgreSQL, MongoDB, or MariaDB environment audit-ready before a QSA shows up in 2026.

TL;DR

• How to prepare a database for a PCI-DSS audit in 2026 starts with scoping the CDE, not encryption.
• Requirement 10 logging failures cause more audit findings than missing patches; centralize logs 90 days before the assessment.
• PCI-DSS certified database audits catch scope creep and weak access control before the QSA does.
• Skip native DB password policies for production PCI systems in 2026; enforce RBAC with unique service accounts instead.

Why this matters

Database findings account for a disproportionate share of failed PCI-DSS assessments, and the pattern repeats every cycle: teams harden the network perimeter and forget that Requirement 3 (protect stored cardholder data), Requirement 8 (unique IDs and access control), and Requirement 10 (log and monitor access) all point straight at the database layer. A QSA doesn't ask if you have a firewall. They ask for a list of every database user with SELECT access to the cardholder data environment (CDE), and they want 90 days of audit log history to prove it.

If your database team has never sat through a PCI-DSS assessment, the gaps show up in access control and logging, not encryption. Most teams over-invest in TDE and under-invest in Requirement 10. Mydbops runs PCI-DSS and ISO certified PCI-DSS database services for fintech for exactly this reason: audit prep is a database engineering problem before it's a compliance paperwork problem.

What you'll need

• A complete CDE inventory - every table, schema, replica, backup, and log stream that stores, processes, or transmits PAN, track data, or CVV. Missing a read replica is the single most common scoping mistake in 2026 audits.
• Config file access - my.cnf, postgresql.conf, mongod.conf, or equivalent, plus current audit/log plugin settings.
• An audit date - from your QSA engagement letter or internal compliance calendar. Work backward from it; most fixes below need 4 to 6 weeks of lead time.
• Encryption documentation - key rotation schedule, TDE or column-level encryption config, and who holds the keys.
• A DBA who can change production config without downtime - access control and audit logging changes touch live systems; this is where a database consulting services engagement usually gets pulled in.

The steps

1. Scope the cardholder data environment (CDE) first

Scoping tells you which databases the rest of PCI-DSS even applies to. Get it wrong and you either over-engineer systems that don't touch cardholder data or, worse, miss one that does.

List every primary, replica, and backup instance that stores PAN, track data, or CVV, plus any staging or analytics database that receives a copy through ETL. In 2026, the most common scoping failure on compliance-heavy audits isn't a production database, it's a forgotten reporting replica or a QA environment seeded with production data.

Expected outcome: a signed-off CDE diagram with every database instance, replica, and backup location labeled in-scope or out-of-scope, reviewed by whoever owns the QSA relationship.

Common mistake: treating "out of scope" as a one-time label instead of re-verifying it after every schema change or new replica.

2. Encrypt cardholder data at rest and in transit

Requirement 3.4 and 4.2 require PAN to be unreadable wherever it's stored and encrypted in transit between the application and the database.

Turn on TDE at the storage engine level for MySQL InnoDB, or use PostgreSQL's pgcrypto or pg_tde, and enforce TLS 1.2 or higher on every connection string, including replication traffic between primary and replica. Truncate or tokenize PAN wherever full card numbers aren't operationally necessary; most databases only need the last four digits for display.

Expected outcome: zero plaintext PAN in table dumps, query logs, or replication streams, with TLS enforced on 100% of client and inter-node connections.

Common mistake: encrypting the primary database and forgetting the same setting on read replicas, backups, or a disaster-recovery instance in another region.

3. Enforce least-privilege access control (Requirement 8)

Requirement 8.2.3 and 7.2 require unique IDs per user and access restricted to what a role actually needs. Shared "app_user" accounts with blanket SELECT and UPDATE across every table fail this every time.

Audit every database account, remove shared credentials, and map each remaining account to a named individual or service with the minimum grants that job requires. For fintech platforms in particular, database security audit services engagements usually start here, because payment schemas accumulate broad grants over years of ad-hoc fixes.

Expected outcome: a role matrix where every account is traceable to a person or a service, with no account holding write access to tables it doesn't touch in production.

Common mistake: fixing application-layer roles but leaving DBA and monitoring tooling accounts with god-mode grants.

4. Turn on and centralize Requirement 10 audit logging

Requirement 10 needs a record of every access to cardholder data, available for at least 12 months, with the most recent 3 months immediately accessible.

Enable the MySQL Enterprise Audit plugin, Percona's audit_log, pgAudit for PostgreSQL, or MongoDB's native auditing, and ship logs to a central, tamper-evident store outside the database host itself. Set retention to 12 months minimum, and test that you can pull a 90-day log slice for a specific table in under an hour.

Expected outcome: centralized, queryable audit logs covering every SELECT, INSERT, UPDATE, and DELETE against CDE tables, retained for the full 12-month window.

Common mistake: enabling audit logging two weeks before the audit. You need 90 days of continuous history by the time the QSA asks for it, which makes this the step with the longest lead time on the list.

5. Patch and harden the database engine (Requirement 6)

Requirement 6.3.3 in PCI-DSS 4.0 requires critical and high-severity vulnerabilities patched within a defined window, and an unpatched CVE on a database engine is one of the fastest ways to fail a technical review.

Check the current version of MySQL, PostgreSQL, MongoDB, or MariaDB against the vendor's security advisory list, patch anything flagged critical, and disable default accounts, sample databases, and unused stored procedures. Restrict network exposure so the database only accepts connections from the application and ProxySQL or PgBouncer tiers, never directly from the internet.

Expected outcome: no database instance running an end-of-life version or carrying an unpatched critical CVE.

Common mistake: patching production but skipping a staging or DR replica running an older engine version; QSAs check both.

6. Validate backup encryption and retention (Requirement 3.4, 9.5)

Encryption and retention rules extend to backups, not just live databases. An unencrypted backup file sitting on a shared drive is a full-scope finding on its own.

Confirm every backup job encrypts the output, verify the encryption key isn't stored next to the backup, and check retention against your data retention policy rather than just your recovery-point objective. Restore-test at least one backup before the audit; a backup that can't restore doesn't count as a control.

Expected outcome: every backup, including cross-region and cold-storage copies, encrypted with keys managed separately from the storage location.

Common mistake: encrypting nightly backups but leaving an old manual export from a migration project sitting unencrypted on a file share.

7. Run a pre-audit vulnerability and configuration scan (Requirement 11.3)

Requirement 11.3 requires quarterly internal vulnerability scans and an annual penetration test. Running one against the database tier before the QSA does is the cheapest way to fix findings on your own terms.

Scan for default ports, weak TLS ciphers, missing patches, and misconfigured grants, then re-run the scan after remediation to confirm a clean pass. Budget one to two weeks between the scan and the audit date to fix what it finds.

Expected outcome: a documented scan report with zero open critical or high findings on any in-scope database.

Common mistake: scanning the production database but skipping the ProxySQL, HAProxy, or connection-pooling layer in front of it; that layer gets audited too.

8. Document everything the QSA will ask for

A QSA works from evidence, not intent. A control that isn't documented with a timestamp and an owner might as well not exist during the interview.

Assemble the CDE diagram, access control matrix, audit log samples, patch records, encryption key management policy, and backup test results into one package before the assessment starts. Assign one owner who can answer follow-up questions on each document without pulling in three other people.

Expected outcome: a single evidence folder that maps one-to-one to the PCI-DSS requirements being tested.

Common mistake: having the right controls in place with no paper trail proving when they were implemented; QSAs test for "since when," not just "does it exist."

Troubleshooting

• Audit logs are eating disk space fast. Ship logs off the database host to a log aggregator or object storage with lifecycle rules. Don't disable logging to save space; that's a bigger finding than the storage cost.
• A legacy MySQL 5.7 instance is past end-of-life and can't be patched. Isolate it behind stricter network controls immediately and put a migration date in the audit evidence package. QSAs accept a documented remediation plan more readily than silence.
• A shared database mixes CDE and non-CDE data. Segment by schema or move non-PCI workloads to a separate instance. Mixing scope inflates the audit and increases the chance of a finding bleeding across systems.
• Native database password policies don't meet Requirement 8.3.6 (12+ characters, complexity). Enforce policy at the identity provider or connection layer instead of relying on database-native password rules, which are inconsistent across MySQL, PostgreSQL, and MongoDB.
• A connection pooler sits between the app and database and isn't covered by any audit log. Add logging at the proxy layer too; QSAs increasingly ask for the full connection path, not just the database engine.
• Backup encryption keys are stored in the same bucket as the backups. Move keys to a separate KMS or vault; co-located keys and backups fail Requirement 3.4 on inspection.

Tools and resources

• MySQL Enterprise Audit plugin or Percona's audit_log plugin for MySQL and MariaDB installations
• pgAudit for PostgreSQL, tuned to log DML on CDE tables specifically to avoid log bloat
• ProxySQL or PgBouncer configured with connection-level logging in front of the database tier
• pt-query-digest and Percona Toolkit for auditing query patterns against CDE tables before the scan
• E-commerce platforms processing card payments directly on the database layer carry particular scoping risk; see the MySQL RDS audit-log retention guide for a practical retention and archival pattern that supports PCI-DSS logging without unnecessary storage cost

What to do next

Once the database-specific controls above are in place, audit prep expands to application-layer tokenization, network segmentation, and vendor risk management, all dependent on the CDE inventory built in step one. Teams operating high-volume MySQL RDS workloads can review the Swiggy AWS DMS RDS case study; the same audit-prep principle applies: nail the CDE map before anything else.

FAQ

What is PCI-DSS Requirement 10 for databases?

Requirement 10 requires you to log and monitor every access to cardholder data, including who accessed it and when. For databases this means audit logging on every SELECT, INSERT, UPDATE, and DELETE against CDE tables, retained for at least 12 months with 3 months immediately accessible.

How long must database audit logs be retained for PCI-DSS?

PCI-DSS Requirement 10 requires 12 months of audit log history, with the most recent 3 months available for immediate analysis. Logs older than 3 months can move to colder storage as long as they're retrievable within a reasonable window.

Does encryption at rest satisfy PCI-DSS Requirement 3?

Encryption at rest covers part of Requirement 3, but you also need key management separate from the encrypted data, truncation or tokenization where full PAN isn't needed, and encryption extended to backups and replicas, not just the primary database.

Can a shared database pass a PCI-DSS audit?

A database mixing cardholder data with unrelated workloads can pass, but only if access controls and logging are scoped to the CDE tables specifically. Most teams find it faster to segment the CDE into its own schema or instance than to prove isolation inside a shared one.

How much does a PCI-DSS database audit cost in 2026?

Cost depends on the number of in-scope database instances, the QSA's scope, and how much remediation is needed before the assessment starts. Check current pricing directly with your QSA or compliance partner rather than assuming a flat rate.

What database engines are PCI-DSS compliant?

PCI-DSS doesn't certify specific database engines. MySQL, PostgreSQL, MongoDB, MariaDB, and MSSQL can all pass an audit when configured with encryption, access control, and Requirement 10 logging in place. Compliance is a configuration and process outcome, not a feature of the engine itself.

How long does PCI-DSS database audit prep take?

Most database audit prep takes 4 to 6 weeks minimum, driven mainly by the 90-day audit log history Requirement 10 expects to see by assessment time. Scoping and access control cleanup can move faster, but logging history can't be backfilled.

Is MongoDB PCI-DSS compliant?

MongoDB can support a PCI-DSS compliant deployment when native auditing, field-level encryption, and role-based access control are configured correctly. The database itself isn't compliant out of the box; the configuration and monitoring around it determines the audit outcome.

One last thing

The finding that kills most database audits isn't encryption, it's Requirement 10 logging turned on too late. Teams spend weeks hardening TDE and TLS, then discover during the audit that centralized audit logs only cover the last 3 weeks instead of the 90 days a QSA expects. Turn on logging the day audit prep starts in 2026, not the week before the assessment.

Need a PCI-DSS ready database review?

PCI-DSS and ISO certified audits across MySQL, PostgreSQL, and MongoDB.