The QSA — your Qualified Security Assessor — shows up for the annual assessment. They want Requirement 10 evidence for one cardholder account number. Six-month lookback. Every access, every actor, every authorization method, every masking decision. They want it for PAN 4111-****-****-1234. They want it within twenty days.
In most stacks, this is a forty-five-day project. Your cardholder access logs are in eight systems. Your payment gateway. Your tokenization service. Your fraud platform. Your call-center recorder. Your data warehouse. Your customer-service tool. Your refunds processor. Your chargeback handler. Reconciling timestamps across eight systems is hard. Reconciling them in a way that the auditor will accept is harder.
And if you miss a single access, the auditor finds it, and you fail PCI. Losing your merchant ability is existential. There's no graceful way to recover from a non-conforming PCI report — you go back into remediation, you lose card-processing capability for the duration, and you accept whatever penalty your acquirer adds.
What Req 10 + Req 11 actually need
The two requirements are tangled. Req 10 wants the access log. Req 11 wants proof that the access controls actually work — not just that the log exists, but that unauthorized reads were prevented from happening.
If your stack has a planner that gates cardholder access at decision time and writes both authorized and denied reads to a chained audit log, Req 10 and Req 11 are evidenced by the same primitive.
The one-query reconstruction
MATCH (pan:CardholderData)
WHERE pan.token = 'tok_4111xxxxxxx1234'
OPTIONAL MATCH (pan)<-[a:ACCESSED]-(actor:User)
WHERE a.ts > datetime() - duration('P6M')
OPTIONAL MATCH (a)-[:AUTHORIZED_BY]->(auth:Method)
OPTIONAL MATCH (a)-[:FOR_PURPOSE]->(p:Purpose)
RETURN pan, collect(a), collect(actor), collect(p)The tokenized PAN is identified. Six months of access events, each with its actor, its authorization method, and its declared purpose. Forty-two reads by the fraud team for fraud review. Twenty-nine reads by the call center after step-up authentication. Two reads by the refunds processor for chargeback handling. Zero unauthorized. Requirement 10 satisfied in seventy seconds.
The Req 11 proof
The harder question is whether the access controls are actually firing. In a planner-gated system, denied reads are chained too. The chain shows 168 attempted reads that didn't have proper authorization — every one of them blocked at the planner level, never reaching cardholder data. The denials are recorded with the actor, the purpose claim, the missing authorization. Req 11 is evidenced by the same chain that evidences Req 10.
The CDE boundary walk
The third question is where the PAN flowed through. The lineage walk shows tokenization, masking, the fraud model, storage. Each hop signed at write. The cardholder-data environment boundary is provably enforced — no PAN ever exits the CDE.
The GDPR + PCI dual compliance
The trickiest moment in PCI is when GDPR shows up too. A customer asks for their data deleted under privacy law. But PCI requires retention of cardholder access logs for fraud investigation. Most stacks have to violate one or the other.
Crypto-shred resolves it. Destroy the customer's per-subject encryption key. The PII becomes ciphertext nobody can read. The tokenized PAN chain stays intact for PCI retention. Both standards, honored.
The numbers
A forty-five-day, $80,000 evidence reconciliation project becomes a seventy-second query. Req 10 + 11 + 12 evidenced together. Your annual assessment scores compliant on every relevant control. No remediation. No fee uplift. No existential risk to your card-processing capability.