PCI-DSS for Testers
PCI-DSS is the standard that governs how card data is handled. As a tester you are not the auditor — but you are the person who proves card data never goes where it should not. This lesson teaches that job.
1 The Hook
A fictional NZ ticketing company, Manaaki Tickets, took card payments for events. To keep things simple they had decided long ago to send all card payments through a hosted page provided by their payment provider, so that full card numbers never touched their own servers. That was the whole point — keep card data out, keep the burden of protecting it small.
Then a developer added a feature. To help the support team handle refunds faster, the checkout started writing the full card number into the application log alongside the order, “just for troubleshooting.” It worked. Refunds were easier. And for months, every card number that passed through checkout was sitting in plain text in log files that dozens of staff, and the log-aggregation tool, could read.
Nothing visibly broke. The payments worked, the refunds worked, the logs looked normal to anyone not reading them closely. But the company had silently pulled full card numbers back into its own systems — the exact data it had designed its whole setup to avoid holding. A setup that had been low-risk was now storing the most sensitive data there is, in the least protected place, with no encryption and broad access.
Here is the lesson hidden in that story. The testers tested that payments and refunds worked. No one had a test that asserted card numbers never appear in a log, a database column, an error message, or an analytics event. That single negative assertion — the full card number must not be here — is the heart of what a tester does for PCI-DSS.
2 The Rule
The safest card data is the card data you never hold. A tester’s core PCI job is not to police a checklist — it is to prove that full card numbers and sensitive authentication data never appear where they should not: not in logs, not in databases, not in error messages, not in analytics. Every place card data leaks into is a place that falls under the standard, so keeping it out keeps the burden small.
3 The Analogy
Handling whitebait at a riverside stand.
Whitebait is precious and it spoils fast, so a careful operator handles it in one clean, controlled spot and nowhere else. The moment a few slip onto the back bench, into an unwashed bucket, or into the boot of the car “just for now,” the problem spreads — now every one of those places has to be kept clean and watched, and the risk multiplies. The skill is not having a bigger rulebook. It is keeping the precious thing in as few places as possible.
Card data is the whitebait. Every system it touches comes under the standard and has to be protected. Manaaki Tickets let it slip onto the back bench — the log files — and suddenly the most precious data was in the least guarded place. A PCI-aware tester is the person checking the back bench, the bucket, and the boot, proving the card data only ever sat in the one clean spot it was supposed to.
4 What Counts as Cardholder Data
To test for card data leaks you must know exactly what you are looking for. PCI-DSS distinguishes a few categories, and the distinction drives what may and may not be stored.
The Primary Account Number (PAN) — the long card number — is the centre of it all. It is the single most sensitive identifier, and the presence of a PAN is what pulls a system into scope. Alongside it sit the cardholder name, the expiry date, and the service code; these are cardholder data too, and are protected when stored with the PAN.
Then there is sensitive authentication data — the security code printed on the card (often called CVV or CVC), the full magnetic-stripe or chip data, and the PIN. This category has a stricter rule of thumb: it must not be retained after a payment is authorised, even in encrypted form. The security code is there to prove the card is present at the moment of the transaction; keeping it afterwards is a serious finding. A common tester catch is a system that stores or logs the security code — it should be used and discarded, never persisted.
There is also the idea of masking and truncation. When a PAN must be shown to a person — on a receipt, in a support screen — only a limited portion may be displayed, with the rest hidden, so the full number is never exposed. A tester checks that wherever a card number is displayed, it is masked, and that the full PAN is never reachable through the display, an export, or an API behind it.
5 Scope — the Central Idea
The single most important PCI concept for a tester is scope. The scope is every system that stores, processes, or transmits cardholder data, plus everything connected to those systems. Every system in scope must meet the standard’s controls; every system out of scope does not. So the size of your scope is the size of your security and compliance burden.
This is why “the safest card data is the data you never hold” is not a slogan but a strategy. If your own servers never see a full PAN — because the card details are captured directly by your payment provider on a hosted page or in an embedded field that posts straight to them — then those servers are largely out of scope. Manaaki Tickets had achieved exactly that, and then the logging change quietly dragged the application servers back into scope by putting PANs on them.
For a tester, scope turns into a precise, checkable question: does card data flow into this system, and should it? Your job is to map where card data actually goes — not where the design says it goes — and to prove it stays out of everything that is meant to be out of scope. A leak into a logging system, an analytics pipeline, a backup, a test database, or an error tracker is a scope expansion, and it is precisely the kind of thing functional testing never notices because the feature still works.
6 Tokenisation and Scope Reduction
Tokenisation is the main technique for keeping scope small, and a tester needs to understand it well enough to verify it.
A token is a stand-in value that replaces the real card number. When a customer pays, the payment provider stores the real PAN in its own protected vault and hands your system back a token — a meaningless reference that maps to the card only inside the provider. Your system uses the token for everything afterwards: showing the saved card, taking a repeat payment, issuing a refund. The token is useless to an attacker because it cannot be turned back into a card number outside the provider’s vault.
The effect is scope reduction. If your systems only ever hold tokens, never PANs, then those systems do not store cardholder data, so they fall out of scope. A repeat-billing system that charges a customer monthly can do its whole job with tokens and never touch a real card number.
For a tester this creates two clear obligations. First, prove that where a token is expected, only a token is present — the system never receives or stores the real PAN by mistake. Second, prove that the token genuinely cannot be reversed in your environment: there is no endpoint, export, or lookup that turns a token back into a card number outside the provider. A “token” that your own system can de-tokenise is not reducing scope at all, and confirming that is a real test.
7 What a Tester Actually Verifies
Pulling it together, here is what a PCI-aware tester targets. The theme throughout is negative assertions — proving the dangerous data is absent.
- No PAN in logs: the full card number never appears in application logs, web-server logs, error trackers, or log-aggregation tools — the Manaaki Tickets defect.
- No PAN in storage it should not be in: no full card number in databases, backups, test data, message queues, or analytics events that are meant to be out of scope.
- No sensitive authentication data retained: the security code, stripe/chip data, and PIN are never persisted after authorisation, anywhere, encrypted or not.
- Masking on display: wherever a card number is shown to a person, it is masked, and the full PAN is not reachable behind the display, an export, or an API.
- Tokens where tokens belong: systems meant to hold tokens hold only tokens, and a token cannot be reversed to a PAN in your environment.
- No PAN in transit it should not be in: card data is not passed in URLs, query strings, or to third parties outside the intended payment flow.
- Encryption and access in scope: where cardholder data legitimately lives, it is encrypted and access is limited — though confirming the formal controls is the auditor’s remit, not yours.
Notice the boundary. You verify the behaviour — that card data is where it should be and absent everywhere else. The formal compliance assessment against the standard’s controls is done by a qualified assessor. Your value is finding the leaks before the assessor — or an attacker — does.
8 Building PCI Test Cases
A PCI test case is usually a negative assertion: after an action, the dangerous data must be absent from a specific place. The evidence is a search of that place showing nothing.
Here is the test case that would have caught the Manaaki Tickets leak:
Risk category: Card data leak / scope expansion (PAN in logs)
What it verifies: After a card payment and a refund, the full card number does NOT
appear in any application log, web-server log, or the log-aggregation tool.
Action: Complete a test card payment, then a refund, using a known test PAN.
Acceptance criteria: A search of all log destinations for the test PAN (full and partial,
known patterns) returns ZERO matches of the full number. Only masked
forms may appear, and the security code must not appear at all.
Evidence required: The search query/method; the list of log destinations searched; the
zero-match result; the test PAN used.
Traceability: Risk R-11 (card data leaked into logging pulls servers into scope).
Result: [Pass / Fail]
Notice the shape. The acceptance criterion is a zero — zero occurrences of the full PAN — and the evidence is a reproducible search showing that zero, across an explicit list of places. It also names the destinations, so a reviewer knows you did not just check one log. This is the assertion Manaaki Tickets never had.
9 Common Mistakes
🚫 Only testing that payments work, never that card data is absent
Why it happens: Functional tests pass and the feature behaves correctly.
The fix: The Manaaki Tickets trap. Add the negative assertion: after a payment, search logs, databases, error trackers, and analytics for the test PAN and assert zero full-number matches. A working payment can still be leaking card data the whole time.
🚫 Storing or logging the security code
Why it happens: It arrives with the rest of the card details, so it gets captured and persisted along with them.
The fix: Sensitive authentication data — the security code, stripe/chip data, PIN — must not be retained after authorisation, even encrypted. Test specifically that the security code is used and discarded, never written to storage or a log.
🚫 Assuming a token cannot be reversed without checking
Why it happens: The word “token” implies safety, so its reversibility goes untested.
The fix: A token only reduces scope if it cannot be turned back into a PAN in your environment. Test that there is no endpoint, export, or lookup that de-tokenises in your systems. A reversible “token” gives you none of the scope reduction you think you have.
🚫 Putting real card numbers in test data and lower environments
Why it happens: Production-like data feels more realistic for testing.
The fix: Real PANs in a test database or a lower environment drag that environment into scope and create an unprotected store of card data. Use the designated test card numbers the schemes provide, and verify no real PAN ever lands in a non-production system.
10 Now You Try
Three graded exercises on card-data handling. Write your answer, run it for AI feedback, then compare to the model answer.
Read the description of a fictional NZ online store’s checkout below. Identify 3 card-data handling risks that would expand PCI scope or breach the standard, and explain the harm of each.
The store uses a hosted payment page so card numbers do not normally touch its servers. To debug a failed payment, the checkout writes the full request — including the card number and the security code — into the error tracker when a payment fails. Saved cards are stored as a token, but the store also keeps the first 6 and last 4 digits plus the expiry in its own orders database for “reconciliation”. The QA team tests refunds using a colleague’s real personal card because it is convenient.
List 3 card-data risks and the harm of each:
Show model answer
There are at least three serious risks here; all three are strong. 1. Full card number AND security code written to the error tracker — On a failed payment the checkout dumps the full PAN and the security code into the error tracker. Harm: it pulls the error-tracker (and the servers feeding it) into PCI scope, and persisting the security code after authorisation is a serious finding in its own right — sensitive authentication data must never be retained. This is the Manaaki Tickets failure with the security code added. 2. Real personal card used in testing — QA tests with a colleague's real card. Harm: real PANs in test activity and lower environments drag those environments into scope and create unprotected exposure of a real person's card. Use the schemes' designated test card numbers instead. 3. Storing first6/last4 + expiry "for reconciliation" — Storing limited PAN digits plus expiry is cardholder data and, depending on how it is held, can still carry obligations; the first-6/last-4 combination is more revealing than a simple last-4 mask. Harm: an avoidable store of cardholder data that adds scope; reconciliation should use the token and a masked last-4 only, with a clear justification for anything more. The trap: payments and refunds all work, so functional testing passes while card data is leaking into the error tracker and a real card is being exposed in test.
The test case below checks that a payment works but does nothing for card-data safety. Rewrite it as a card-data-leak test, with these fields: Test ID, Risk category, What it verifies, Action, Acceptance criteria, Evidence required, Traceability. Use a fictional NZ airline booking checkout as the context.
“Pay for a booking with a card. Check the booking is confirmed. Pass if payment succeeds.”
Rewrite as a card-data-leak test case:
Show model answer
Test ID: PCI-LEAK-008 Risk category: Card data leak / scope expansion (PAN or security code in logs, DB, error tracker, or analytics) What it verifies: After a booking payment, the full card number and the security code do not appear in any application log, web-server log, error tracker, analytics event, or the orders database (beyond an approved masked form). Action: Complete a booking payment with a known test PAN and a known test security code, then trigger a failed payment to exercise the error path. Acceptance criteria: A search of every log destination, the error tracker, analytics events, and the orders database for the test PAN returns zero full-number matches; the security code returns zero matches anywhere; only the approved masked PAN form may appear. Evidence required: The search method and the explicit list of destinations searched (logs, error tracker, analytics, DB); the zero-match results; the test PAN and security code used. Traceability: Risk register R-11 (card data leaks into out-of-scope systems and expands PCI scope). What makes it strong: the acceptance criterion is a zero (zero full-PAN matches, zero security-code matches), the action deliberately includes the error path where leaks hide, the evidence names every destination searched, and it traces to a numbered risk. The original verified only that payment succeeded — it could pass while card data leaks on every transaction.
Design a tokenisation and scope-reduction test plan of 5 test cases for a fictional NZ subscription service that bills a saved card monthly using tokens. Each case needs at least: an ID, what it verifies, an acceptance criterion, and the evidence required. Cover token-only storage, no PAN received, irreversibility, repeat billing with a token, and masked display.
Show model answer
TOK-01 | Verifies: saved cards are stored only as a token, never as a PAN | Acceptance criteria: the saved-card store contains tokens only; a search for full PAN patterns returns zero matches | Evidence required: schema/sample of the store; the zero-PAN search result TOK-02 | Verifies: the application servers never receive the real PAN | Acceptance criteria: the card details are captured directly by the provider; the app's inbound traffic and storage contain no full PAN | Evidence required: data-flow showing capture at the provider; search of app logs/DB for PAN returning zero TOK-03 | Verifies: a token cannot be reversed to a PAN in our environment | Acceptance criteria: there is no endpoint, export, report, or lookup that de-tokenises; only the provider can map token to PAN | Evidence required: review of available endpoints/exports; confirmation that none return a PAN from a token TOK-04 | Verifies: monthly repeat billing works using only the token | Acceptance criteria: a scheduled charge succeeds using the stored token; no PAN is needed or touched; the charge reconciles | Evidence required: the billing request showing a token (not a PAN); settled charge; reconciliation TOK-05 | Verifies: any card display is masked | Acceptance criteria: saved-card displays and receipts show only a masked form; the full PAN is not reachable via the UI, export, or API behind it | Evidence required: the masked display; an attempt to retrieve the full PAN via export/API showing it is not returned Strong plans: each case is specific, has a measurable criterion (often a zero), names concrete evidence, and together they cover token-only storage (TOK-01), no PAN received (TOK-02), irreversibility (TOK-03), token-based repeat billing (TOK-04), and masked display (TOK-05). Weak plans say "check tokenisation works" five times — that is the difference being marked.
11 Self-Check
Click each question to reveal the answer.
Q1: What is the core PCI job of a tester, in one sentence?
To prove that full card numbers and sensitive authentication data never appear where they should not — not in logs, databases, error messages, analytics, or lower environments — because the safest card data is the data you never hold and every place it leaks into expands scope.
Q2: What is “scope” and why does it matter so much?
Scope is every system that stores, processes, or transmits cardholder data, plus anything connected to them. Every in-scope system must meet the standard’s controls, so the size of scope is the size of the burden. Keeping card data out of a system keeps that system out of scope — which is why a leak into logs or analytics is a scope expansion.
Q3: How does sensitive authentication data differ from other cardholder data?
Cardholder data including the PAN may be stored if properly protected. Sensitive authentication data — the security code, full stripe/chip data, and PIN — must not be retained after authorisation at all, even encrypted. So finding the security code persisted anywhere is a finding regardless of how well it is protected.
Q4: How does tokenisation reduce scope, and what must a tester confirm about it?
A token replaces the real card number; the provider holds the PAN in its vault, and your systems hold only the meaningless token, so they fall out of scope. A tester must confirm two things: that only tokens, never PANs, reach those systems; and that a token cannot be reversed to a PAN in your environment — no endpoint, export, or lookup that de-tokenises.
Q5: Why is using a real card in test environments a problem?
A real PAN in a test database or lower environment drags that environment into scope and creates an unprotected store of someone’s real card data. You should use the designated test card numbers the schemes provide, and verify no real PAN ever lands in a non-production system.
12 Interview Prep
Real questions asked in NZ QA interviews for payments and security roles. Read the model answers, then practise your own version.
“You are testing a checkout. What do you do specifically for PCI-DSS?”
Beyond confirming the payment works, my core PCI job is the negative assertion: card data must not be where it should not. After a payment — and crucially after a failed payment, because error paths are where leaks hide — I search every log, the error tracker, analytics events, and the database for the test card number, and assert zero full-PAN matches. I check the security code is never persisted, since sensitive authentication data must not survive authorisation. I confirm any displayed card number is masked and the full PAN is not reachable behind it. And I verify tokens are used where expected and cannot be reversed in our environment. I am not the assessor, but I find the leaks before they do.
“What is PCI scope, and how does a tester help keep it small?”
Scope is every system that touches cardholder data plus everything connected to it, and each in-scope system carries the standard’s controls — so smaller scope is less risk and less cost. A tester keeps it small by proving card data only flows where it is meant to. I map where card data actually goes, not where the design claims, and I assert it stays out of logs, analytics, backups, and test environments. Catching a PAN that has leaked into a logging system — which silently expands scope while the feature still works — is one of the highest-value things I can do.
“A developer wants to log the full card number to debug failures. How do you respond?”
I’d explain that this is exactly the change that turns a low-risk setup into a high-risk one — it pulls the full PAN, and the systems holding the logs, into PCI scope, and if the security code goes with it that is a serious finding because sensitive authentication data must never be retained. For debugging we can log a masked card number and a transaction reference, which is enough to trace a failure without holding the dangerous data. Then I’d add a leak test: after a failed payment, search the logs and error tracker for the full PAN and assert zero matches, so the safe behaviour stays verified over time.