When a contract ends, the engineering team often forgets to rotate the service account that a CI pipeline uses to write transaction logs into a persistent store. Weeks later, a security audit discovers that the same credential still exists, and the logs contain raw card numbers that were never encrypted at rest.
PCI DSS treats any repository that retains cardholder data as "long‑term memory" and subjects it to a strict set of controls. The standard does not care whether the data lives in a relational database, a NoSQL cache, or a file‑system bucket; it cares that every byte of stored PAN (Primary Account Number) is protected, that access is tightly scoped, and that the organization can prove who touched the data and when.
What PCI DSS expects for long‑term memory
Requirement 3 of PCI DSS mandates that stored cardholder data be rendered unreadable wherever it resides. This means encryption at rest with strong keys, tokenization, or irreversible hashing for PANs that must be retained for business purposes. Requirement 7 requires that access be limited to a need‑to‑know basis, enforced by unique IDs for each user or process. Requirement 10 calls for logging all access to cardholder data, including successful and failed attempts, the exact query or command, and the timestamp. Finally, Requirement 12 demands that the organization retain these logs for at least one year and be able to produce them on demand for auditors.
In practice, compliance teams must answer three questions during an audit:
- How is the data encrypted or masked when it is stored?
- Who accessed the data, what actions did they perform, and was the access authorized?
- Can we demonstrate that access was reviewed and approved according to policy?
Typical gaps in existing implementations
Many teams rely on static credentials that are baked into CI/CD pipelines or shared among multiple engineers. Those credentials often have broad privileges, read, write, and admin, across the entire database. Because the connection goes straight from the client to the database, the database itself becomes the sole point of control. It can enforce encryption at rest, but it rarely provides fine‑grained command‑level audit or inline masking of query results. When a developer runs a SELECT that returns a credit‑card column, the raw numbers flow back to the terminal unfiltered, and no record is kept of that specific query.
Even when logging is enabled, the logs are usually stored on the same host that runs the database. If an attacker compromises that host, they can tamper with or delete the logs, breaking the audit trail required by Requirement 10. Moreover, because the access control check happens before the connection is established, there is no way to inject a real‑time approval step for high‑risk commands such as bulk export or table truncation.
The control surface you need
PCI DSS compliance demands a single, enforceable boundary where identity, policy, and data flow intersect. This boundary must:
- Authenticate every request with a verified identity (OIDC, SAML, or service‑account token).
- Authorize the request against a least‑privilege policy that can be changed without redeploying the target system.
- Inspect the wire‑level protocol to apply inline masking of sensitive fields before they reach the client.
- Require just‑in‑time approval for commands that exceed a defined risk threshold.
- Store the full session, including commands, responses, and approval decisions, in a location that is separate from the database, so the database cannot modify the audit data.
Only when these controls sit in the data path can an organization be confident that the evidence it presents to auditors truly reflects what happened.