How to Become PCI Compliant: A Plain-English Guide
Published July 5, 2026
To become PCI compliant, you work out how your business handles card data, complete the Self-Assessment Questionnaire that matches your setup (or a formal audit if you are a large merchant), close any gaps against the 12 requirements, and report the results to your bank each year. That is the whole arc, and for many smaller businesses it is more manageable than the acronym makes it sound. This guide walks through each step in plain English, aimed at the owner or operator who has been told they need to be PCI compliant and wants to know what that actually involves, what it costs, and where the real work is.
What PCI compliance is, and who needs it
PCI DSS, the Payment Card Industry Data Security Standard, is a set of security requirements for any business that stores, processes, or transmits payment card data, or that could affect the security of the systems that do. If you take credit or debit cards, in any form, it applies to you. The standard is maintained by the PCI Security Standards Council, and the current version is PCI DSS v4.0.1, the only version supported since the end of 2024.
One thing to clear up early, because it causes real confusion: PCI is not a government law. It is a contractual requirement that flows from the card brands (Visa, Mastercard, and the others) down through your bank or payment processor to you. You agreed to it when you signed up to accept cards. That distinction matters for how it is enforced, which we come back to at the end.
Step one: figure out how you handle card data
Everything about your PCI workload comes down to one question: how does card data flow through your business? A shop that runs cards through a standalone terminal that connects straight to the bank touches very little card data on its own systems. An online store that accepts payments through a hosted page the customer is redirected to touches almost none. A business that types card numbers into its own software, stores them, or runs its own checkout page touches a lot.
The less card data your own systems see, the fewer requirements apply and the shorter your path to compliance. This is why "reducing scope" is the single most valuable move in PCI: the more you can hand the sensitive part to a validated provider, the smaller your own obligation becomes. Before anything else, map out exactly where card data enters, where it goes, and where it rests. That map decides everything that follows.
Step two: identify your SAQ
Most businesses validate PCI compliance with a Self-Assessment Questionnaire, or SAQ. There is not one questionnaire, there are several, and each is built for a specific way of taking cards. Picking the right one is the difference between answering a couple dozen questions and answering a few hundred. Here is the plain-English version:
| If you take cards this way | Your SAQ is usually | Roughly how much it covers |
|---|---|---|
| Card-not-present, with all payment handling fully outsourced (for example, an e-commerce site that redirects to a hosted payment page) | SAQ A | The shortest path |
| An e-commerce site where the payment fields are embedded from a provider but the page is yours | SAQ A-EP | Longer than A |
| Standalone, dial-out or internet terminals only, no electronic card storage | SAQ B or B-IP | Short |
| A web-based virtual terminal, one card at a time, nothing stored | SAQ C-VT | Moderate |
| Payment application connected to the internet, no electronic storage | SAQ C | Moderate |
| Everything else, including any storage of card data | SAQ D | The full set |
A short but important caveat: you do not get to simply pick the questionnaire you like. The bank or processor you report to, what PCI calls your compliance-accepting entity, has the final say on which SAQ and what validation your business needs. Confirm it with them before you invest time in the wrong one. The Council keeps the current list in its Getting Started guide.
Step three: meet the 12 requirements
Every SAQ is a subset of the same twelve core requirements. Your questionnaire simply asks about the ones that apply to your setup. In plain terms, the twelve are:
- Build and maintain a secure network. (1) Put proper network security controls in place, and (2) stop using vendor default passwords and settings.
- Protect stored account data. (3) Protect any card data you store, and (4) encrypt it whenever it crosses open or public networks. The best version of this requirement is not storing card data at all.
- Maintain a vulnerability management program. (5) Protect every system against malware, and (6) develop and maintain secure systems and software, which means patching and secure updates.
- Implement strong access control. (7) Give people access only to the card data their job needs, (8) make sure every user is uniquely identified and authenticated, with multi-factor authentication where required, and (9) restrict physical access to anywhere card data lives.
- Monitor and test regularly. (10) Log and monitor all access to card data and the systems around it, and (11) test the security of those systems on a schedule.
- Maintain a security policy. (12) Back all of it with written policies and a real security program your team actually follows.
Most of these overlap heavily with plain good security and with what your cyber insurance carrier already expects. If you have done that work, you are partway there. If you have not, PCI is a reasonable forcing function to finally get it done, and it pairs naturally with ongoing managed IT and security.
Step four: the two kinds of testing PCI asks for
Requirement 11 is where two specific, often-confused activities live. It is worth separating them clearly.
Quarterly vulnerability scans. If your business has systems reachable from the internet in scope, including most e-commerce setups, you need an external scan at least once every three months, run by a PCI-approved scanning vendor (an ASV), with any issues fixed until the scan passes. This is an automated check that your internet-facing systems have no known holes.
Penetration testing. When your setup puts you on the full assessment path (SAQ D or a formal audit), Requirement 11.4 adds penetration testing: internal and external tests at least once every twelve months and after any significant change. E-commerce merchants whose own web pages are part of the payment flow (SAQ A-EP) owe an external penetration test too. A penetration test is a hands-on exercise where a tester actively tries to break in, which finds things a scanner cannot. The key nuance most guides miss: penetration testing does not apply to every merchant. If you take cards only through standalone terminals or fully outsource your online payments, you very likely do not need one for PCI. If you store or fully handle card data, or your own e-commerce page touches payments, it enters the picture. Our specialist practice breaks down exactly which merchants PCI requires a penetration test for, SAQ by SAQ.
Step five: collect the evidence and report
Here is the part that separates businesses that stay compliant from businesses that scramble every year: PCI is not a one-time form, it is an ongoing habit of keeping proof. The Council frames it as a continuous cycle of assess, remediate, and report. In practice that means keeping the things that show your controls are running: passing quarterly scan reports, your written policies, records of access reviews and patching, and the attestations from any providers who handle card data on your behalf.
Once a year you pull it together, complete your SAQ (or your auditor completes a Report on Compliance if you are a large merchant), sign the Attestation of Compliance, and submit it to your bank. Larger businesses may have an on-site assessment by a Qualified Security Assessor; smaller ones typically self-attest. Either way, the yearly report is easy when the evidence has been accumulating all along and painful when you are reconstructing a year of history the week it is due. Building that evidence habit is the core of what a good compliance partner sets up, and it is the same discipline behind our compliance readiness work across frameworks.
What it costs, and what non-compliance costs
PCI cost scales with scope, which is why step one pays off. A small merchant on SAQ A with outsourced payments might spend very little beyond time. A business on SAQ D with card data in its own systems, quarterly scanning, annual penetration testing, and remediation to fund is looking at a real project. The honest range is wide, so anyone quoting a flat PCI price before understanding how you take cards is guessing. Reducing scope is the lever that moves the number most.
On the other side, the cost of non-compliance is real but often misunderstood. There is no government fine. What happens instead is that the card brands define penalties, and your bank enforces them through your contract, typically as fines passed down after a security problem, higher processing fees, or in the worst case losing the ability to accept cards at all. If card data is stolen and you were not compliant, the liability lands on you. None of that requires scare numbers to make the point: compliance is straightforwardly cheaper than the alternative.
Frequently asked questions
Is PCI compliance required by law?
Not by a government law in the United States. PCI DSS is a contractual requirement from the card brands, enforced through your agreement with your bank or payment processor. It is mandatory in the sense that your ability to accept cards depends on it, and a few states reference it in statute, but it is not a federal law.
How do I know which SAQ my business needs?
It depends on how you take cards. A business using only standalone terminals uses a different, shorter questionnaire than one that handles card data on its own website. Your bank or processor is the final word on which one applies, so confirm it with them before you start filling anything in.
Can I do PCI compliance myself with a self-assessment questionnaire?
Often, yes. Most smaller merchants validate with a Self-Assessment Questionnaire rather than a formal audit. The questionnaire is a checklist of the controls that apply to your setup. The work is not in the form, it is in genuinely meeting the controls and keeping the evidence, which is where an IT partner usually helps.
What happens if my business is not PCI compliant?
The card brands define penalties, and they are enforced by your bank through your contract, not by a government agency. Beyond fines passed down after a problem, the bigger risks are higher transaction fees, losing the ability to accept cards, and carrying full liability if card data is stolen. Compliance is cheaper than any of those.
How long does it take to become PCI compliant?
It depends where you start. A small merchant with a simple, outsourced setup can validate in a few weeks. A business that stores card data on its own systems and needs to reduce scope, fix gaps, and stand up quarterly scanning should plan for a few months. The first assessment is the slow one; renewals are faster.
Is a vulnerability scan the same as PCI compliance?
No. A quarterly scan by an Approved Scanning Vendor is one requirement for many merchants, not the whole thing. PCI compliance is the full set of controls plus the yearly report. The scan proves your internet-facing systems are clean; the rest of the requirements cover everything else.
Getting PCI compliant without the scramble
Becoming PCI compliant comes down to knowing how you handle card data, meeting the requirements that apply to your setup, and keeping the proof current so the yearly report is a formality instead of a fire drill. The businesses that find it painless are the ones that reduced their scope early and built the evidence habit, not the ones that treated it as a form to fill in at the deadline. If you are staring at a questionnaire from your bank and not sure where you stand, Desert Lakes Solutions offers a no-pressure discovery call to map your card data flow, identify the right SAQ, and lay out exactly what readiness takes. Book a discovery call and we will give you the straight version.
