How to become PCI compliant: the steps, and the requirements behind them

Who you prove it to

Becoming PCI compliant is not an application to the Council. The PCI Security Standards Council writes the standard (PCI DSS v4.0.1 is the version of the standard in force), and each card brand runs its own compliance program: “which entities need to validate compliance, validation levels, whether an entity is eligible to complete a Self-Assessment Questionnaire (SAQ) or must complete a Report on Compliance (ROC), and any fines or penalties.” The Council says it plainly: “Compliance validation requirements are set by brands, acquirers, payment facilitators, etc.”

For a small merchant that means one counterparty: your acquirer. If you want the background first, read what PCI compliance is. This page is the doing.

Step 1Map where card data goes

The Council's own assessment process starts here: “Scope – determine where payment account data is stored, processed, and transmitted, and which systems and networks are in scope for PCI DSS, and confirm the scope of the assessment.” In a shop, that means following one payment through each way you take cards: the counter, the website, the phone, the invoice that goes out by email.

Requirement 12.5.2 sets the minimum. PCI DSS scope is documented and confirmed “at least once every 12 months and upon significant change,” and the check covers, at a minimum:

1. 01Every data flow, for each payment stage (authorization, capture, settlement, chargebacks, refunds) and each channel
2. 02Your data-flow diagrams, brought up to date (Requirement 1.2.4)
3. 03Every place card data is stored, processed or sent, including file backups
4. 04Every system in the card data environment, connected to it, or able to affect its security
5. 05Every segmentation control, and why the networks it cuts off are out of scope
6. 06Every connection from a third party with access to the card data environment

Scope is the lever that decides how much work follows. The Council's Quick Reference Guide puts it in money terms: reducing scope “can lower the cost of the PCI DSS assessment, lower the cost and difficulty of implementing and maintaining PCI DSS controls, and reduce risk for the entity.” A till that never sees a card number, a checkout hosted by the processor, a phone line that never ends in a notepad: each one takes a piece of your business out of the questionnaire.

Step 2Confirm your level and SAQ

Your acquirer assigns your merchant level from your yearly card volume for each card brand. Visa, Mastercard and Discover set their own thresholds; ask your acquirer which level you are. Under the card brands' programs, your level helps decide whether you may self-assess with an SAQ or need a Report on Compliance. To see where your volume sits, try the merchant level calculator.

A Self-Assessment Questionnaire is a “Reporting tool used to document self-assessment results from an entity's PCI DSS assessment.” The Council publishes these SAQs for PCI DSS v4.0.1: A, A-EP, B, B-IP, C, C-VT, D for Merchants, D for Service Providers, P2PE and SPoC. Which one you file follows from step 1: how cards reach your processor. The SAQ type finder walks the eligibility questions channel by channel.

Then check the answer with the people who receive it. The SAQ Instructions say “Organizations are responsible to confirm they meet all eligibility criteria for a particular SAQ before commencing their self-assessment”, and that before you start an SAQ, you confirm with the organization you submit it to (usually your acquirer, the merchant bank) that you are eligible for it.

Your route by SAQ

Pick the SAQ you file. The receipt shows how big your form is, whether scans are on your list, and opens the checklist and the calendar already set to it.

Step 3Work through the requirements

Now the work itself. The Council's second assessment step: “Assess – perform the assessment on all in-scope system components to determine whether PCI DSS requirements have been met, by following the testing procedures for each PCI DSS requirement.” The full standard groups everything under 12 requirements:

You do not answer all of it. “Most SAQs include a sub-set of only those PCI DSS requirements that are applicable for a given environment,” and the size of that sub-set is where the payment setup you chose shows. The Council counts the PCI DSS v4.x requirements that apply to each SAQ A e-commerce setup: no access to your own webpage = 14; redirect to the processor = 27; processor iframe on your page = 27. SAQ A-EP (Direct Post or merchant script) = 139. Any other e-commerce setup = SAQ D, all requirements.

The PCI compliance checklist filters to your SAQ (the route planner in step 2 opens it already set) and keeps your ticks in the browser. If your site carries its own payment form, the payment gateway comparison shows which processors would move you to a shorter questionnaire.

Fix the gaps in order

The Council's word for this part is “Remediate — identifying and addressing any gaps in security controls, fixing identified vulnerabilities, securely removing any unnecessary payment data storage, and implementing secure business processes.” Start with the stored data. A card number you delete is one you never have to protect, and the rules on storing card information say what may stay. If the gap list is long, the Council's Prioritized Approach “maps all PCI DSS requirements into six risk-based security milestones” so you can fix the highest risks first.

Step 4Put the rules in writing

Requirement 12 is where a small business usually has nothing on paper. These are the documents that come up again and again, with the requirement each one answers. Your SAQ decides which of them your form asks about; the template sets its sections by SAQ.

The PCI policy template writes the policy from your answers, and the incident response plan template fills in the who-calls-whom part. The provider list is the one owners forget: your processor, your website host, the company that services your till. Each one goes on it.

Step 5Pass the quarterly ASV scans

PCI DSS 11.3.2 requires external vulnerability scans at least once every three months by an ASV approved by PCI SSC. Whether that is on your list depends on your SAQ. SAQ A for v4.x includes Requirements 11.3.2 and 11.3.2.1 (external vulnerability scans) for merchants whose pages redirect to, or embed, a processor's payment page. SAQ D covers all requirements, so it includes them too. SAQ A-EP carries 139 requirements; check the scan questions in your SAQ A-EP form or ask your acquirer. For the rest, the form says.

You cannot run this scan yourself. Merchants “must use only ASVs to perform external vulnerability scans at least once every three months as required by PCI DSS Requirement 11.3.2, and the ASV scan solution must be managed by the ASV.” Picking the vendor is your job, from the Council's list: our directory of approved scanning vendors makes it searchable, and the ASV comparison for small merchants weighs the ones that sell to shops.

A passing ASV scan has no vulnerability scored 4.0 or higher on CVSS and nothing that breaks PCI DSS. When a scan fails, you fix the failing vulnerabilities, ask the ASV for another scan, and repeat until a scan passes. In the first year, you do not need four passing scans if the most recent scan passed, a written policy requires scans at least every three months, and fixes were confirmed by rescan. More on reports, disputes and rescans in what an ASV scan is.

Step 6Sign the AOC and send it

The Attestation of Compliance is “the official PCI SSC form for merchants and service providers to attest to the results of a PCI DSS assessment, as documented in a Self-Assessment Questionnaire (SAQ) or Report on Compliance (ROC).” In an SAQ it is Sections 1 and 3; Section 2 holds your requirement answers. The Council's instruction: “Attest – complete the appropriate Attestation of Compliance (AOC) in its entirety. Official AOCs are only available on the PCI SSC website.”

Then “Submit”: the SAQ or ROC and the AOC, “along with other requested supporting documentation such as ASV scan reports,” to whoever manages your compliance program. For scan reports the ASV Program Guide adds: “Scan customers should contact their acquiring bank or each Participating Payment Brand to determine to whom results should be submitted.” Some ASVs send them for you, if you agree that with them. If something is not in place, the last step is “Remediate – if required, perform remediation to address requirements that are not in place, and provide an updated report.”

Skipping this step is what shows up on a statement. A PCI non-compliance fee on a merchant statement comes from the acquirer or processor under its card-brand program, never from the PCI Security Standards Council. The guide to PCI compliance fees explains where each line comes from, and the AOC, ROC and QSA guide walks the form section by section.

Step 7Put next year on the calendar

The Council treats compliance as a loop, not a filing. Its last ongoing step is “Monitor and Maintain — confirming that security controls put in place to secure the payment account data and environment continue to function effectively and properly throughout the year.” These jobs recur on the standard's own clock:

Make it a calendar, not a memory

The PCI deadline calendar turns your SAQ, the date on your last AOC and your last passing scan into a year of dated reminders, as an .ics file most calendar apps can import. Next year starts back at step 1, with one question: did anything change in how you take cards?

Quick reference

Questions