PCI compliance requirements are the security controls a business must meet when it stores, processes, or transmits payment card data. For a small company, the useful version of that answer is a short list: know where card data enters, shrink that path, lock down the systems that remain, and keep records an acquirer can review. The current standard is PCI DSS v4.0.1. Your bank or payment brand, not the standards body, decides how you prove it.
Ask IGTech365 to review the systems that touch your card payments.
What the PCI compliance requirements actually ask you to do
If you only need the definition, what PCI compliance is is a separate page. This one is the working checklist.
The PCI Security Standards Council’s getting-started guide groups the standard into six goals and twelve requirements. The goals still frame the work even though the active text is now v4.0.1:
- Build and maintain a secure network and systems.
- Protect account data, in storage and while it moves.
- Maintain a vulnerability management program.
- Implement strong access control measures.
- Regularly monitor and test networks.
- Maintain an information security policy.
The same guide reduces compliance work to three repeating steps: assess, remediate, and report. Assess means listing the assets and processes that touch card data and finding the weak spots. Remediate means fixing them. Report means sending the records your acquirer asks for. A one-time project does not finish the job, because new systems, staff, and vendors keep changing the picture.
PCI DSS v4.0.1, published in June 2024, is a limited revision of v4.0. The Council said it added no new requirements and deleted none. It clarified stored-data rules, payment-page scripts, multi-factor authentication, and how customers relate to third-party service providers. PCI DSS v4.0 was retired on 31 December 2024, so v4.0.1 is the version to use now. The Council also said 51 requirements that were future-dated in v4.0 became effective on 31 March 2025.
How to scope card data before you pick controls
Scope decides which requirements apply. Start with every way a customer can pay you, then follow the card number until it leaves your control.
- List each payment channel: in-store terminal, hosted checkout, payment link, phone order, invoice, and recurring bill.
- Mark whether your staff, your website, or a vendor ever sees the full card number.
- Name the workstations, networks, apps, and people that can reach those systems.
- Note paper receipts, email, spreadsheets, and voicemail that might hold a card number.
- Write the path down and date it. Update it when you change a processor, a location, or a firewall.
A hosted checkout page can shrink the systems that store or transmit card data. It does not erase the website, the staff accounts, or the vendor relationship. If an employee can change the payment page, that employee and that website still matter.
Keep the diagram plain. Show the payment system, the boundary around it, the vendors, and which direction data moves. That drawing is the first piece of evidence most reviews ask for.
Count a system as in scope when it stores, processes, or transmits card data, and also when it can affect the security of a system that does. A jump box, a remote-support tool, and the firewall in front of the terminal all qualify. A PC that only opens a hosted checkout in a browser may still qualify if staff can edit that page or install software on it.
Write down what is out of scope too, and why. A useful note says the shop cameras never see a card number and sit on a separate network. “We think the cameras are fine” is not useful. The out-of-scope note keeps the next review from dragging those devices back in by accident.
Which controls to put in place first
Do not try to boil the whole standard on day one. Close the paths that actually hold card data, then build the records around them.
| Control area | What a small business should do | Evidence to keep |
|---|---|---|
| Network and system setup | Put a firewall in front of payment systems and change every default password. | Network diagram, firewall rules, and a record of the password change. |
| Stored card data | Stop storing card numbers. If you must keep them, protect them and set a deletion date. | Data inventory, retention rule, and deletion log. |
| Data in transit | Encrypt card data whenever it crosses a public network, including email and remote support. | Encryption settings and a list of allowed payment paths. |
| Vulnerabilities | Patch critical flaws quickly and keep anti-malware current on in-scope systems. | Patch dates, scan results, and malware-update logs. |
| Access | Give each person a unique login, limit access to the job, and use multi-factor authentication. | User list, access reviews, and MFA settings. |
| Physical access | Lock the room, closet, or drawer where terminals, servers, or paper receipts live. | Key or badge list and a visitor record. |
| Monitoring and tests | Log access to payment systems and test them on a schedule. | Log samples, scan reports, and the test calendar. |
| Policy | Write who may handle card data, how incidents are reported, and how vendors are reviewed. | Signed policy, incident steps, and vendor agreements. |
Two habits cause the most rework. The first is saving card numbers in a spreadsheet, a shared inbox, or a notes app “just for refunds.” The second is a shared register login. Unique IDs and a ban on stored card numbers remove more risk than a long policy no one follows.
Multi-factor authentication belongs on every account that can reach the cardholder data environment. The v4.0.1 clarification is narrow: it does not waive MFA for ordinary passwords. It only notes an exception for accounts that already use phishing-resistant authentication alone. For a typical small business, that exception will not apply. Turn MFA on.
IGTech365 sees the same pattern on managed IT reviews. The payment app is fine, and the leftover risk sits in old admin accounts, an open remote-access tool, or a PC that was never patched. Fix those before you buy another product.
How PCI DSS v4.0.1 changes the report you file
Most small merchants do not get an on-site assessment. They complete a Self-Assessment Questionnaire, and some must also run quarterly network scans by an Approved Scanning Vendor. Which form you use depends on how you take cards. Your acquirer, not a blog post, confirms the form.
In January 2025 the Council changed SAQ A, the short form for merchants that fully outsource card data and do not store, process, or transmit it electronically. The Council’s SAQ A update did three things:
- It removed Requirements 6.4.3 and 11.6.1, the payment-page script controls, from SAQ A.
- It removed the targeted risk analysis (Requirement 12.3.1) that supported 11.6.1.
- It added an eligibility check: you must confirm your site is not susceptible to script attacks that could affect the e-commerce system.
The January 2025 SAQ A took effect on 31 March 2025. The October 2024 version was retired the same day. The underlying PCI DSS requirements were not deleted. They still apply to merchants whose questionnaire includes them. If you are not eligible for SAQ A, do not assume those script controls dropped off your list.
Read the eligibility lines before you pick the short form. SAQ A is for card-not-present merchants, e-commerce or mail and telephone order, whose account-data work is done by PCI DSS validated third parties. If your staff keys cards into a virtual terminal, your site touches card data, or you keep electronic card numbers, you are on a different form.
Ask the vendor for its own compliance evidence and for a written description of which systems it secures. Put the scanning duty in the contract when the vendor runs your checkout. A logo on a proposal is not a report.
Keep a one-page vendor file for each provider that can affect a payment. Name the service, the date you last received its compliance report, the date that report expires, and who at your company owns the relationship. If a provider will not share a current report, treat that gap as a finding, not as a reason to skip the line on the questionnaire.
Service providers have their own PCI DSS duties, including written agreements about who is responsible for which requirements. Do not sign a contract that says “customer is fully responsible for PCI” while the vendor hosts the only system that sees the card. Split the duties in writing before the next renewal.
What evidence to keep between reviews
A questionnaire is easier when the proof already exists. Build a single folder and add to it through the year instead of reconstructing it in March.
Keep these items current:
- The data-flow diagram and a one-page list of in-scope systems.
- Firewall and router rules, plus the date of the last review.
- A user list that shows who can reach payment systems, and the date access was last checked.
- Patch and anti-malware records for those systems.
- Quarterly scan reports, if your acquirer requires an Approved Scanning Vendor.
- The security policy, incident steps, and proof that staff who handle payments have read them.
- Agreements and compliance reports from each payment vendor.
Review the folder when you add a location, replace a terminal, or hire someone who takes payments. A control you cannot show is a control you will be asked to rebuild under a deadline.
Testing belongs on the calendar, not in a panic. If your environment is in scope for external scans, schedule them quarterly and keep the passing report. A failed scan is useful only after you record the fix and the rescan. For a closer look at what a test engagement costs and covers, see penetration testing cost for a small business. Ongoing watch of the same systems is covered in what a security operations center does for a small business.
How a Florida small business should use this list
IGTech365 works with Tampa Bay companies that take cards in a shop, on the phone, and on a website, often all three. The requirements do not change by city. The messy part is local: a front desk that writes card numbers on paper, a shared QuickBooks login, and a processor contract nobody has opened since signup.
Healthcare and dental offices have a second duty. PCI covers the card payment. HIPAA covers patient information. A system that does both needs both programs. The practice guide on how a Florida healthcare practice prepares for a HIPAA security risk analysis is the patient-data companion to this payment checklist, not a substitute for it.
Use the list in this order. Confirm how you take cards. Delete stored card numbers you do not need. Turn on unique logins and MFA. Patch the in-scope PCs. Ask your acquirer which questionnaire and which scans apply. Then book a cybersecurity review if the diagram, the user list, or the vendor file is missing. That review is how you find out whether the checkout page is the only thing in scope.
Call IGTech365 at (866) 365-7798 to walk through your payment systems.
Frequently asked questions
Does a small business have to meet PCI compliance requirements?
Yes, if you accept payment cards or your systems store, process, or transmit cardholder data. Being small usually changes the questionnaire and the amount of evidence, not the duty to protect the data. Ask your acquiring bank which validation it expects.
Does a hosted payment page make us compliant?
No. A hosted page can keep card numbers off your server, and it may make you eligible for a shorter questionnaire. You still have to meet the requirements on that form, confirm the vendor is validated, and show that your site is not open to script attacks that could affect checkout.
Which PCI DSS version should we use in 2026?
Use PCI DSS v4.0.1. The Council retired v4.0 on 31 December 2024 and retired v3.2.1 on 31 March 2024. Requirements that were future-dated became effective on 31 March 2025. Your acquirer can still tell you which questionnaire version to file.
Can we store card numbers in a spreadsheet for refunds?
Do not. Storing card numbers outside a protected payment system pulls that spreadsheet, the PC, and the people who can open it into scope. Use your processor’s refund tools instead of a local copy.
Who decides if we are compliant?
The PCI Security Standards Council writes the standard and publishes the questionnaires. It does not certify your business. Your acquirer or payment brand sets the validation and decides whether your report is accepted.