If you take credit or debit cards, you need to be PCI compliant. That’s true whether you run one card terminal in a shop or a website with thousands of orders. For most small businesses, being compliant means scoping your payment setup tightly, filling out the right annual self-assessment, and keeping the rest of your IT environment in decent shape. It rarely means hiring an auditor. It does mean doing the work every year, not once.
We’re an MSP, so we have a bias here. We’d rather you read this and do the simple parts yourself than be talked into something you don’t need. Read the rest with that in mind.
TL;DR
- PCI DSS applies to every business that accepts card payments, regardless of size or how you process them.
- Most small merchants validate with an annual Self-Assessment Questionnaire (SAQ). Your acquiring bank tells you which one.
- Square, Stripe and similar processors shrink your scope. They don’t remove your responsibility for your own network and devices.
- The cheapest compliance is the smallest scope: keep card data off your systems wherever you can.
- Treat it as a yearly cycle, not a one-time project.
What PCI compliance actually is
PCI DSS is the Payment Card Industry Data Security Standard. It is a baseline set of security requirements for any company that accepts card payments and has to protect cardholder data. The PCI Security Standards Council writes it. It is not a law. The card brands and your bank enforce it through your merchant agreement.
That distinction matters in two ways. First, nobody from the government shows up. Your acquiring bank asks you to validate, and if you don’t, you can face fines, reimbursement of fraudulent transactions, or losing the ability to take cards. Second, a separate legal duty exists on top. The Federal Trade Commission expects businesses to keep reasonable data security for customer information, and card data is squarely in that bucket.
The current version is PCI DSS v4.0.1, and the Council has published the matching SAQs. If a guide you find still talks about v3.2.1, it’s out of date.
Merchant levels: where you probably fit
People search for “merchant level” constantly, so here is the honest version. Levels 1 through 4 come from the card brands’ compliance programs, not from the standard itself. They are mostly set by how many card transactions you process in a year, and they decide how you prove compliance.
| Level | Who it usually describes | Typical validation |
|---|---|---|
| Level 4 | Smaller merchants | Annual SAQ, sometimes with quarterly vulnerability scans |
| Levels 1 to 3 | Higher transaction volumes | More formal validation, which can include an outside assessor |
Small merchants are often assigned Level 4, which frequently means a self-assessment rather than a third-party audit. Two cautions:
- The exact thresholds and rules differ by card brand and by acquirer. Ask your bank which level it has you at and don’t guess from a chart.
- A lower level doesn’t mean fewer security obligations in practice. It changes how you report, not whether the controls matter. A breach at a Level 4 merchant is just as expensive for the customers whose cards were stolen, and often for you.
A breach can also move you up a level. Banks and card brands can reclassify a merchant after an account-data compromise.
Does using Square, Stripe or a similar processor make you compliant?
No, but it helps a lot. This is the most common misunderstanding we run into.
A modern processor handles card data on its side. If you use its encrypted terminals or hosted payment pages, the card number never lands on your computers. That often qualifies you for a shorter SAQ, and many processors pre-fill parts of it for you.
What the processor does not cover:
- Your local network. If your payment terminal shares a flat network with the front-desk PC, a guest WiFi and a smart TV, that’s your problem.
- Your own processes. Card numbers written on paper, taken over email, or typed into a spreadsheet pull your whole office into scope.
- Your validation. You still have to complete and submit your SAQ each year.
In short, the processor secures its piece. You secure yours, and you remain responsible for the broader environment even if a breach starts at a weak point in your own network.
Shrink your scope first
Practitioners keep making the same observation: when PCI feels impossible, the cause is usually a sloppy payment setup, not the standard. Scope is the amount of your environment that touches card data, and every system in scope has to meet the requirements.
The levers are simple:
- Use point-to-point encrypted (P2PE) terminals. Card data is encrypted at the swipe, dip or tap, and your network never sees it in the clear.
- Use hosted payment pages for online sales. Your website sends the customer to the processor’s page or embeds its fields, instead of collecting card numbers itself.
- Stop keeping card numbers. No paper forms, no emailed numbers, no “we keep it on file” spreadsheets. If you need repeat billing, use the processor’s tokens.
- Separate the payment terminal from everything else. Put it on its own network segment so that a compromised laptop can’t reach it.
Do those four things and the question list in your SAQ often gets much shorter. That alone can save more money than any tool you could buy. We cover the cost side in more detail in our piece on PCI compliance cost.
A step-by-step plan for your first year
1. Call your acquiring bank
Your acquirer is your merchant bank, the company that settles your card sales. It sets your validation path. Industry guidance is blunt on this point: programs, deadlines and validation rules vary by brand and acquirer, and generic online advice can send you to the wrong form. Ask three questions: what is my merchant level, which SAQ do you expect, and when is it due?
2. Map how card data moves
Walk through every way a customer can pay you: in person, by phone, on your website, through an invoicing tool, by mail. For each, write down where the card number goes and who touches it. You’ll usually find one or two stray paths, such as a staff member who writes numbers on a sticky note. Kill those first.
3. Pick the right SAQ
The SAQ type depends on how you accept payments. A shop with a P2PE terminal and an online store using a hosted page look very different on paper from a business keying cards into a virtual terminal on an office PC. Choosing the wrong one is a common mistake, so confirm it with your bank before you spend hours on it.
4. Fix what the questionnaire exposes
Expect questions about:
- Firewalls and network segmentation
- Unique logins and multi-factor authentication for anyone with access to payment systems
- Patching and anti-malware on devices in scope
- Changing vendor default passwords
- Written security policies and staff awareness
- Logging and an incident response plan
This is where small offices stumble. It isn’t the card terminal. It’s the old router with the factory password and the PC missing six months of updates.
5. Run any required scans
Some payment setups require quarterly external vulnerability scans from an approved vendor. Your bank will tell you if yours does. Don’t skip them, because a failed or missing scan can hold up your validation.
6. Check your vendors
This step gets forgotten. The Council publishes questions small merchants should ask their vendors. Ask every provider that touches your payments, including your IT company, e-commerce platform and hosting, for its current Attestation of Compliance, and check that it covers the specific service you use. A big brand name is not proof.
7. Submit, then repeat
Sign the attestation and send it where your acquirer tells you. Then put next year’s date in the calendar. PCI is an annual validation, and the security work behind it is continuous. Our PCI compliance checklist gives you a working list to adapt.
Can you do it yourself?
Often, yes. Small merchants can validate through a Self-Assessment Questionnaire, and the questionnaire is the tool the Council and acquirers provide for exactly that. If you have a clean setup, such as an encrypted terminal, a hosted checkout and a segmented network, a careful owner can handle it.
Where DIY goes wrong:
- The questions are technical. Plenty of capable owners hit terms like segmentation, authenticated scanning or key management and guess. Guessing on an attestation is a bad habit.
- The environment is messier than you think. The office has a shared printer, an old file server and three remote workers on home routers. Now “scope” isn’t one terminal.
- Nobody owns it next year. The person who did it leaves and the process leaves with them.
If you are comfortable with the answers, do it yourself. If not, get help before you sign, not after.
What we think
We built ArchiTECH around security first, and PCI is a good example of why. Most of the PCI trouble we see isn’t about card data at all. It’s ordinary IT hygiene that slipped: unpatched machines, shared logins, a flat network, no tested backups, nobody who knows what’s connected to what.
Here is our frank advice.
Scope before tools. Don’t buy software to protect card data you shouldn’t be holding. Remove the data from your systems first. It’s cheaper and safer.
Treat the SAQ as a snapshot of your security, not a hurdle. The questions are a reasonable list of what a small business should be doing anyway. If you can’t truthfully answer yes, that’s a to-do list, not a reason to fudge.
Be suspicious of anything that sells you a “compliance certificate” in a day. Validation is about your actual environment and your acquirer’s rules. A pretty badge doesn’t change either.
Pick an IT partner who can show you their own homework. Ask for their documentation, ask how they handle monitoring and incident response, and ask what happens at 2 a.m. when something looks wrong. Our approach follows a six-step security framework, and we’d welcome that kind of scrutiny. Our guide on how to choose a managed IT provider in Massachusetts lists what we’d check if we were buying.
PCI is also one piece of a bigger picture. If you’re a healthcare practice taking card payments, you may have HIPAA obligations on the same network. If you’re a defense supplier, CMMC may be in play. Working these out together is much cheaper than treating each as a separate fire drill.
— Tyson
Where an MSP fits
You don’t need a managed provider to file a questionnaire. You may want one if the questionnaire keeps pointing at IT work that nobody in your office has time or training to do: network segmentation, patching, multi-factor authentication, endpoint protection, monitoring, backups and a tested response plan.
That’s the work we do for small and mid-sized organizations in Rhode Island and Massachusetts, including compliance support for HIPAA, PCI and CMMC and our cybersecurity services. If you’d like to know where you stand before committing to anything, start with our free cybersecurity assessment. It gives you a clear picture of your gaps without the pressure of a sales pitch. If you’re near Providence, our Providence team can meet you there, and our New Bedford office serves the South Coast.
We don’t publish prices, because they depend on your size and setup. Ask us and we’ll give you a straight number.
Common mistakes we’d steer you away from
- Assuming the processor handled it. See above. Your network is still yours.
- Storing card numbers “just in case.” The safest card number is the one you never kept.
- Using one flat network. Terminals, staff PCs, cameras and guest WiFi on the same segment make everything in scope.
- Answering the SAQ from memory. Verify, don’t recall. Check the firewall, the patch status, the accounts.
- Filing the wrong SAQ. Confirm with your bank.
- Forgetting the calendar. Validation recurs yearly, and so do scans if they apply to you.
- Ignoring your vendors. If a provider can’t produce an AOC for the service you use, treat that as a finding.
FAQ
Does a small business need to be PCI compliant?
Yes. The standard applies to every business that accepts card payments, from a single-terminal shop to a national chain. How much work it takes depends on how you process payments and how much of your environment touches card data.
Can I do PCI compliance myself?
Often you can, using the SAQ your acquiring bank assigns you. It gets harder if your network is complicated, you take cards in several ways, or you can’t confidently answer the technical questions. In those cases, bring in an IT provider before you attest.
Do I need to be PCI compliant if I use Square?
Yes. Using a processor like Square or Stripe reduces your scope and often your paperwork, but you still validate and still secure your own network and devices. Check with your acquirer or processor about which questionnaire applies.
What happens if I’m not compliant?
The consequences come through your bank and the card brands: fines, liability for fraudulent transactions, or loss of the ability to accept cards. A breach adds forensic costs, customer notification and possible regulatory attention. Talk to your acquirer and, if you’ve had an incident, to an incident response professional right away.
Sources
- PCI Security Standards Council: Merchants
- Bank of America Merchant Help: PCI Compliance
- Bank of America: Protect your business from card fraud
- FTC: Protecting Personal Information
- PCI SSC bulletin: SAQs for PCI DSS v4.0.1
- Sprinto: PCI compliance for small businesses
- PCI SSC: Payment Facilitators and PCI DSS Compliance
- PCI SSC: Questions to Ask Your Vendors