pci-basics

---
name: pci-basics
description: Turns your card terminal setup, your network layout and your acquirer's paperwork into the correct PCI DSS Self-Assessment Questionnaire type for your actual equipment, a plain answer to which of the twelve requirement areas apply to you and which do not, a gap list against the requirements that do apply, and a completed Attestation of Compliance ready to send to your acquirer. Use when your acquirer asks for a PCI DSS certificate, when you are choosing a new terminal or till system, or when nobody in the business can say which SAQ you are supposed to be filing.
---

# The card security duty you already signed up to, answered with the right form instead of the wrong one

You give this how your card terminal connects (standalone dial or IP, integrated with your till, or a separate PIN pad on a till line), whether it is part of a listed point-to-point encryption solution, whether you take card details over the phone or store any card number anywhere, and your acquirer's own correspondence about your merchant level. You get back the specific SAQ type your equipment actually qualifies for, named and justified line by line against the eligibility criteria, a plain list of which of the twelve PCI DSS requirement areas that SAQ actually asks about, a gap list against the ones that do, and a completed Attestation of Compliance. It will not tell you that you are secure. A completed SAQ is a self-assessment against a published standard, not an independent finding, and the skill says so on every file it produces.

## What it does

1. **Establish that this is a contract duty you already accepted, not a voluntary scheme.** When the business signed its merchant agreement, it accepted the card scheme's own compliance programme: Visa's Account Information Security programme and Mastercard's Site Data Protection programme both require merchants to validate against PCI DSS, and the acquirer's own agreement is the mechanism that carries the duty down to you. The council that writes the standard says it plainly of the current version: "To address stakeholder feedback and questions received since PCI DSS v4.0 was published in March 2022, the PCI Security Standards Council (PCI SSC) has published a limited revision to the standard, PCI DSS v4.0.1," which "contains no additional or deleted requirements" against v4.0, only corrections and clarifications. Establishing this first stops the conversation from treating PCI DSS as an optional add-on a supplier is trying to sell.

2. **Confirm the current standard and which deadline has already passed.** PCI DSS v4.0.1 is the currently supported version; v4.0 itself was retired on 31 December 2024, after which v4.0.1 became the only supported version. A set of new requirements that were future-dated when v4.0 was first published became mandatory on 31 March 2025. Checked against today, 23 September 2026, both dates are in the past: the business is being assessed against v4.0.1 in full, with no future-dated requirement still pending.

3. **Map the actual card-taking equipment to an eligibility list, not to a name someone remembers from a form.** Each SAQ type has a published eligibility criteria section, and a business is eligible for the shortest one it genuinely meets, never the shortest one it would prefer. Write down, for every way the business takes a card: is it a standalone terminal, an integrated till and card system, a virtual terminal typed into a browser, or a phone order; is any card number ever written down, typed into a spreadsheet, or stored on a computer; is the terminal on the same network as anything else in the building.

4. **Test against SAQ P2PE first, because it is the narrowest and the easiest to rule in or out.** The eligibility criteria state that a P2PE merchant confirms "All payment processing is via a validated PCI-listed P2PE solution," that "The only systems in the merchant environment that store, process or transmit account data are the payment terminals from a validated PCI-listed P2PE solution," and that the merchant "does not otherwise receive, transmit, or store account data electronically," with "all controls in the P2PE Instruction Manual (PIM) provided by the P2PE Solution Provider" implemented. If the acquirer's own paperwork names a listed P2PE solution and nothing else touches a card number, this is the answer, and it asks the fewest questions of any SAQ.

5. **Test against SAQ B-IP next, for a standalone terminal that is not part of a listed P2PE solution.** The criteria describe "merchants that process account data only via standalone, PCI-listed approved PIN Transaction Security (PTS) point-of-interaction (POI) devices with an IP connection to the payment processor," where "the standalone, IP-connected PTS POI devices are not connected to any other systems within the merchant environment (this can be achieved via network segmentation to isolate PTS POI devices from other systems)," and where "the merchant does not store account data in electronic format." A terminal plugged into the same router as the till, the office computer and the guest Wi-Fi fails this test the moment it shares a network with anything else, whatever its own settings say.

6. **Test against SAQ A only where every card transaction is genuinely handed to someone else.** The criteria require that "the merchant accepts only card-not-present (e-commerce or mail/telephone-order) transactions," that "all processing of account data is entirely outsourced to PCI DSS compliant third-party service provider (TPSP)/payment processor," and that "the merchant does not electronically store, process, or transmit any account data on merchant systems or premises." A venue taking a table booking deposit through a hosted payment page it never touches can meet this. A venue that takes a card number over the phone and keys it into anything itself cannot.

7. **Land on SAQ D where none of the narrower forms fit, and say so plainly rather than forcing a fit.** SAQ D applies to a merchant whose environment does not meet any narrower SAQ's eligibility criteria, and it is the only SAQ that asks about all twelve PCI DSS requirement areas rather than a subset. It is more work, and picking a narrower SAQ that does not genuinely apply does not reduce that work, it removes evidence the business would need if a breach or a compliance review ever tested the claim.

8. **Once the SAQ type is settled, list only the requirement areas it actually contains, and stop treating the rest as relevant.** The twelve PCI DSS requirement areas cover a firewall configuration, vendor default password changes, stored cardholder data protection, encrypted transmission, anti-malware, secure systems and applications, restricted access by business need to know, unique user IDs, restricted physical access, logging and monitoring, regular testing, and an information security policy. A narrow SAQ such as B-IP or P2PE asks a short list of questions drawn from only some of these areas, because the eligibility criteria have already removed most of the attack surface the full set exists to cover. Answering areas the chosen SAQ does not ask about is wasted work; skipping an area it does ask about is the gap this step exists to catch.

9. **Hand the mapping and the gap check to Codex once the equipment facts are settled.** Put the terminal and network description, the acquirer correspondence naming the merchant level, any P2PE solution documentation, and the answers to steps 3 to 8 in one working folder and run, from that folder:

   ```
   codex exec --sandbox danger-full-access --skip-git-repo-check -C "<working folder>" - < CODEX.md
   ```

   Claude hands over which SAQ type the equipment qualifies for and why, and the facts against each requirement area that SAQ contains. Codex returns the SAQ mapping record, the requirement area checklist marked met or gap, and a draft Attestation of Compliance populated with the facts supplied. Codex never chooses the SAQ type itself and never marks a requirement met without a supplied fact behind it.

10. **File the Attestation of Compliance where the acquirer can be sent it the day it is asked for, and set a date to redo the whole check.** An AOC is a point-in-time record; a new terminal, a new till integration, or a network change can move the business into a different SAQ the same day it happens. Set a date, at minimum every twelve months, to run this whole process again rather than sending the acquirer the same form from a setup that no longer exists.

## Then it checks

1. The SAQ type named is justified against that SAQ's own published eligibility criteria, quoted or paraphrased line by line, not chosen because it is the shortest form.
2. Every way the business takes a card is accounted for in the equipment description, including phone orders and any deposit taken through a website.
3. Where a P2PE solution is claimed, the acquirer or provider documentation naming it as PCI SSC-listed and validated is on file, not assumed from a supplier's marketing.
4. Every requirement area the chosen SAQ contains has a stated fact behind it, met or gap, and no area outside that SAQ's scope is treated as required.
5. The Attestation of Compliance is signed, dated, and named to a specific person at the business, not left generic.
6. A date is set for the next full review, no later than twelve months from this one, or from any equipment or network change, whichever is sooner.

Any check fails: name it, redo that step once. Failed twice: say what is wrong and stop.

## Rules
- Public information only.
- Never invent a fact, a number or a quote.
- Anything sent in someone's name says whose name it is.
- Never claim a PCI DSS self-assessment proves the business is secure or cannot be breached. It is evidence of a self-assessment against a published standard on a given date, and stating more than that misrepresents what the document is.
- Never choose the shortest SAQ available where the equipment does not genuinely meet its eligibility criteria. A wrong SAQ answered perfectly is worse than the right SAQ answered honestly, because it removes the evidence the business would need later.
- Never state a breach rate, a fraud loss figure or any comparison to a typical UK hospitality business's card security. No published figure exists for a single independent venue.
- Never mark a requirement area met without a supplied fact naming what satisfies it. An assumption that a firewall or a password policy "probably" exists is a gap, not a pass.
- This output is a working document prepared for the owner to check against their own acquirer correspondence and equipment, and for their IT provider or card terminal supplier to confirm the technical facts before the Attestation of Compliance is sent. It applies published PCI SSC criteria to facts supplied. It is not a penetration test, not an independent security assessment and not a guarantee of compliance.

## Built from
- PCI Security Standards Council, "Just Published: PCI DSS v4.0.1", https://blog.pcisecuritystandards.org/just-published-pci-dss-v4-0-1, read 23 September 2026: the publication reason, the retirement of v4.0 on 31 December 2024, and the 31 March 2025 effective date for future-dated requirements, in step 2.
- PCI Security Standards Council, "Self-Assessment Questionnaire A, PCI DSS v4.0", https://listings.pcisecuritystandards.org/documents/PCI-DSS-v4-0-SAQ-A.pdf, read 23 September 2026: the SAQ A eligibility criteria quoted in step 6.
- PCI Security Standards Council, "Self-Assessment Questionnaire B-IP, PCI DSS v4.0", https://listings.pcisecuritystandards.org/documents/PCI-DSS-v4-0-SAQ-B-IP.pdf, read 23 September 2026: the SAQ B-IP eligibility criteria quoted in step 5.
- PCI Security Standards Council, "Self-Assessment Questionnaire P2PE, PCI DSS v4.0", https://listings.pcisecuritystandards.org/documents/PCI-DSS-v4-0-SAQ-P2PE.pdf, read 23 September 2026: the SAQ P2PE eligibility criteria quoted in step 4.
- Visa, "Security and Compliance" (Account Information Security programme), https://corporate.visa.com/en/resources/security-compliance.html, read 23 September 2026: the statement that transaction volume determines merchant level and that "Acquirers must ensure that their merchants validate at the appropriate level," in step 1.
- Mastercard, "Site Data Protection (SDP) Program & PCI", https://www.mastercard.com/global/en/business/cybersecurity-fraud-prevention/site-data-protection-pci.html, read 23 September 2026: the Level 3 merchant threshold of "greater than 20,000 but less than or equal to one million total combined Mastercard and Maestro electronic commerce transactions annually," in step 1.

# pci-basics

## You are given
A description of every way the business takes a card: terminal type (standalone dial, standalone IP-connected, integrated with the till, virtual terminal, phone order), whether the terminal shares a network with any other device, and whether any card number is ever written down, typed, or stored electronically anywhere in the business. Documentation from the acquirer or the terminal or till provider naming any point-to-point encryption solution as PCI SSC-listed and validated, where one is used. The acquirer's own correspondence stating the business's merchant level, where supplied. The SAQ type already determined by Claude against the published eligibility criteria, with the reasoning. For each requirement area that SAQ contains, the facts already established about whether it is met, and by what. The name, job title and contact details of the person who will sign the Attestation of Compliance. All judgement calls, including which SAQ type applies, have already been made by Claude and are supplied to you as a finished decision with its reasoning.

## Produce
Write into a `./pci-basics-output/` folder:

1. `saq-determination.md` recording, on separate lines: the SAQ type determined; each eligibility criterion for that SAQ type, copied from the brief, marked `met` or `not met` against the supplied equipment facts; and the conclusion restated once at the end. This file restates a decision already made; it does not remake it.
2. `requirement-checklist.csv` with columns: `requirement_area`, `in_scope_for_this_saq`, `fact_supplied`, `status`, `evidence_reference`. One row per PCI DSS requirement area (firewall configuration, vendor default settings, cardholder data protection, encrypted transmission, anti-malware, secure systems and applications, access restricted by business need to know, unique user IDs, restricted physical access, logging and monitoring, regular testing, information security policy). `in_scope_for_this_saq` is `yes` or `no`, copied from what the brief states the chosen SAQ actually asks about. `status` is exactly one of `met`, `gap`, `not applicable to this saq`, and is `met` only where `fact_supplied` names a specific fact, never left `met` on an assumption.
3. `attestation-of-compliance.md` a draft AOC stating: the business name and address as supplied, the SAQ type and its version, the date of assessment, the signatory's name and job title as supplied, and a summary line for each requirement area's status from `requirement-checklist.csv`. Leave the signature line blank for the named person to sign by hand.
4. `gaps.md` a numbered list of: every requirement area marked `gap`; any equipment fact needed to confirm an eligibility criterion that was not supplied; any P2PE or SAQ B-IP claim with no supporting documentation reference supplied; and the AOC signatory field if left blank.
5. `next-review-date.md` one line stating the date twelve months from today, and one line stating that any change to card-taking equipment, till integration or network layout brings that date forward to immediately.

## Rules
- Codex records a determination already made, checks facts against a checklist, and drafts the AOC. It never chooses the SAQ type, never marks a requirement area met without a named fact, and never asserts the business is secure or compliant beyond what the supplied facts state.
- Never treat a supplier's marketing claim as proof of a PCI SSC listing. A P2PE or validated solution claim needs a document reference; without one it is a gap, not a pass.
- Never state a breach rate, a fraud figure or an industry comparison in any file.
- Use British English, GBP where a figure appears, and DD Month YYYY dates. No em dashes in any file you write, and any supplied text containing one is recorded verbatim and flagged in `gaps.md`.
- Every equipment description, document reference and name is copied exactly as supplied.
- Every file ends with this line: this is a working document prepared for the owner to check against their own acquirer correspondence and equipment, and for their IT provider or terminal supplier to confirm the technical facts before the Attestation of Compliance is sent. It applies published PCI SSC criteria to facts supplied and is not a penetration test, an independent security assessment or a guarantee of compliance.

## Return
The absolute path of every file written, the SAQ type determined and the count of its eligibility criteria marked `met`, the row count of `requirement-checklist.csv` and how many rows are `met`, `gap` and `not applicable to this saq`, whether the AOC signatory field was completed, the next review date, and the `gaps.md` item count.