The Database Side of PCI DSS: Which Controls Bind You?

In an organisation subject to the card payment standard, the application, network and encryption sides are usually mature. Friction at assessment time tends to appear in database operations: who pushed a script to production, who pulled data, what that access rested on and how you show it. This article maps four requirements of the standard onto the database side and lists the typical findings.

Where the Database Sits in the Cardholder Data Environment

The cardholder data environment covers every component that stores, processes or transmits cardholder data. The database sits right at the centre of that definition and usually enters scope on three counts at once: it stores the data, it is the access point to the data, and every script that runs on it can change the data.

The practical consequence: the controls you built for the application layer are expected to have a counterpart at the database layer. If the application has code review and a deployment record, the database is expected to have a record and an approval for its changes too.

Requirement 6: Changes Are Managed Securely

The sixth requirement covers developing and maintaining secure systems; its change management section asks that changes to all system components be managed securely. "All system components" includes the database, and in practice four things are looked for: documented impact, approval by authorised parties, functional testing and a rollback plan.

On the database side the weakest of these four is usually the rollback plan. For an application release, rollback means redeploying the previous package and it is easy to show. For a database, the rollback plan is often no more than the sentence "we would restore from backup". When an assessor hears that, the follow up question arrives: when did you last test this plan, and what was the restore time.

The second weak link is the scope of the approval. The application release was approved, but the database script travelling inside it was never separately assessed. Once the approval covers the release, the database change becomes invisible.

Requirement 7: Access on a Need to Know Basis

The seventh requirement asks that access to system components and cardholder data be limited by business need. On the database side this turns into two separate questions, and the second one usually has no answer.

First question: which account has rights on which table? This is answerable; the database has its own permission tables.

Second question: how many times did that authorised person reach cardholder data last month, on what business grounds, and where is the extracted data now? A permission list does not answer this. Permissions show the possibility of access; they do not show the reason for actual access. A need to know principle is measured by the access that happened, not by the access that could have happened.

Requirement 8: Unique Identity and Attribution

The eighth requirement covers identifying users and authenticating access. The key nuance: the standard does not ban shared accounts outright, it bans unattributable use. If an action can be tied back to an individual, the mechanism is acceptable.

In database operations there are two distinct identities here, and they should not be conflated:

The right sentence in the meeting is this: do not try to split the application pool account, that is an architectural choice. What deserves attention are the accounts people use by hand. Where there are no personal administrator accounts, the operation identity comes from the record layer and the attribution gap closes.

Requirement 10: Logging and Monitoring Access

The tenth requirement asks that all access to system components and cardholder data be logged and monitored. Most organisations read this as a log collection problem: they turn on database auditing, deploy a monitoring tool and ship the logs to a central platform. That is a correct and necessary implementation.

What is missing is not the log but the integrity and the meaning of the log. An assessor asks two things. First: how do you show this record was not altered? If the administrator of the system holding the record is also the person producing records, that question is not easy to answer. Second: was this access permitted? A log cannot answer that, because the permission decision never reaches it.

The Four Most Common Database Side Findings

• The approval covered the release; the database change was never assessed separately. There is a release record, but no assessment of what the script inside it does.
• The rollback plan is unwritten or never tested. "We would restore from backup" is a hope, not a plan.
• Production data extractions leave no record. Files pulled for support or analysis have no stated reason, no recipient and no retention period.
• Emergency work never gets its post review. A record was opened, the review step was never closed, and nothing counts how many are outstanding.

The Evidence the Assessor Will Ask For

On assessment day what gets asked for is not a policy document but a chain running through one single event. Measure how long it takes your organisation to assemble it:

• For a randomly chosen production change: the script, the rule that made it risky and who approved it.
• Proof that the text which ran was the text that was approved.
• For a read from a table holding cardholder data in the same period: the stated reason, the masking decision and the delivery address.
• A demonstration, independent of the team holding the records, that they have not been altered since they were produced.
• The list of requests rejected last quarter. If it is zero, you cannot show the control filters anything.

If you can show these five from one record within minutes, the database side is assessment ready. If you show them by collecting screenshots from different systems, that preparation is a cost you pay again at every assessment.