Greg Muiter's OrganizationVisit Website →
← Back to blog

PCI Compliance Requirements for US SMBs: Annual Scope and 90 Day Plan

October 4, 2026
PCI Compliance Requirements for US SMBs: Annual Scope and 90 Day Plan

PCI compliance requirements are the security rules every business that accepts credit or debit cards must follow to protect cardholder data. The first thing to do is identify your Cardholder Data Environment (CDE), the systems that store, process, or transmit card data, and then either implement the 12 PCI DSS requirement groups yourself or confirm your third-party processor already has. Under PCI DSS v4.x, you also need to reconfirm that scope every year under Requirement 12.5.2.

TL;DR:

  • Scope verification must be confirmed annually, including testing the effectiveness of segmentation controls through penetration testing.
  • Merchants processing less than a certain volume may qualify for simplified self-assessment questionnaires, but larger entities often need a qualified security assessor.
  • Implementing controls like multi-factor authentication, encryption, and regular vulnerability scans addresses multiple PCI requirements and supports cyber insurance needs.
  • Failure points include unverified system connections, storing prohibited data, and inadequate vetting of third-party service providers.
  • Ongoing program management is essential, with routine scope updates, policy reviews, and regular testing to maintain compliance over time.
Ventis Consulting Group
Strengthen Your PCI Security
Ventis provides personalized IT support and cybersecurity solutions for businesses working to protect systems, data, and payment environments.
Visit Ventis Consulting Group

Table of Contents

The 12 PCI DSS requirement groups explained

The PCI Security Standards Council (PCI SSC) organizes PCI DSS into 12 requirement groups built around six broader goals: secure networks, protected cardholder data, vulnerability management, strong access control, ongoing monitoring, and a formal security policy. Each group has an owner inside your business, even if that owner is an outsourced IT provider.

Here is what each group actually asks you to do:

  • Requirement 1 and 2 cover network security and system hardening: install firewalls between your network and the internet, and change every default password on routers, point of sale terminals, and servers before they go live.
  • Requirement 3 and 4 protect stored and transmitted cardholder data: encrypt card numbers at rest and use TLS for any card data moving across a network.
  • Requirement 5 and 6 address malware and secure development: run anti-malware on all systems that touch card data and patch known vulnerabilities on a defined schedule.
  • Requirement 7 and 8 control access: restrict card data access to employees who need it for their job, and require unique logins with multi-factor authentication for anyone reaching the CDE remotely or with administrative rights.
  • Requirement 9 covers physical security: lock server rooms and keep a visitor log for anyone who enters areas with card data systems.
  • Requirement 10 requires logging and monitoring: track every access to cardholder data and keep those logs for at least a year.
  • Requirement 11 mandates testing: run vulnerability scans and penetration tests on a schedule tied to your environment's risk.
  • Requirement 12 ties it together with policy: maintain a written information security policy and confirm your scope at least once a year.

PCI DSS v4.x raised the bar on several of these groups. Password requirements are stricter, multi-factor authentication now applies more broadly across the CDE, and Requirement 12.5.2 turns scope confirmation into a mandatory annual exercise rather than a one-time project. Many of these changes became effective on March 31, 2025, after being published as future-dated requirements, giving organizations time to prepare before enforcement began, according to PCI SSC guidance on the v4.x timeline.

Why scope and segmentation decide how hard compliance gets

Your Cardholder Data Environment includes every system that stores, processes, or transmits card data, plus any system connected to it or capable of affecting its security. That second category catches people off guard: a help desk ticketing tool, a backup server, or a VoIP system can pull itself into scope just by sitting on the same network segment as your point of sale terminals.

Getting scope right starts with a data flow diagram. Here is the basic process:

  1. Map every place card data enters your business, whether through a terminal, a website form, or a phone order.
  2. Trace where that data travels and where it is stored, including backups and log files.
  3. Identify every system connected to those paths, even indirectly.
  4. Document segmentation controls that isolate the CDE from the rest of your network.
  5. Confirm the whole map is still accurate at least once a year, as Requirement 12.5.2 requires.

Segmentation itself has to be verified, not assumed. A VLAN that separates your point of sale network from your office network only counts if you can show it works. Host-based firewalls, intrusion detection or prevention systems, and multi-factor authentication on any jump point into the CDE all give an assessor something concrete to test. PCI SSC scoping guidance notes that segmentation must be verified annually, including through penetration testing, and that it does not create out-of-scope status on its own unless controls give reasonable assurance that out-of-scope systems cannot reach the CDE.

Pro Tip: Keep your data flow diagram as a living document tied to your change control process, and update it the moment you add a new payment integration or point of sale system, not at audit time.

Who actually has to comply with PCI DSS

Any business that stores, processes, or transmits cardholder data has to comply with PCI DSS, and so does any service provider whose systems could affect the security of that data. That includes small retailers using a single card reader and large service providers hosting payment infrastructure for other merchants.

Your card brand and acquiring bank determine your merchant level based on transaction volume, and that level drives how you validate compliance:

  • SAQ A applies to merchants who fully outsource card processing and have no electronic storage of card data on their own systems.
  • SAQ A-EP fits e-commerce merchants who outsource payment processing but whose website still influences the security of the payment page.
  • SAQ C-VT applies to merchants using a virtual payment terminal with no electronic card data storage.
  • SAQ D is the most extensive questionnaire and the only option for most service providers, covering the full set of 12 requirement groups.

The official SAQ A documentation spells out eligibility criteria in detail, and it is worth reading closely before you assume you qualify for the simpler option. Our guide to cutting PCI scope for small businesses walks through how outsourcing choices affect which SAQ applies to you.

How validation and reporting actually work

Validation falls into two tracks depending on your size and risk profile. Smaller merchants typically complete a Self-Assessment Questionnaire, a set of yes-or-no questions matched to their SAQ type. Larger merchants and most service providers need a Report on Compliance (ROC), a detailed assessment usually performed by a Qualified Security Assessor (QSA), with the results summarized in an Attestation of Compliance (AOC) that gets submitted to your acquirer or card brand.

A few things to keep straight:

  • SAQ versus ROC comes down to transaction volume and your acquirer's requirements; ask your acquiring bank directly if you are unsure which applies.
  • ASV scans must be run by an Approved Scanning Vendor at least quarterly for merchants with internet-facing systems in scope, including SAQ A e-commerce merchants with outsourced processing, according to PCI SSC's v4.x guidance.
  • Penetration testing under Requirement 11 needs to cover both the network perimeter and internal segmentation controls, on a schedule tied to your environment.
  • QSA versus internal self-assessment depends on your merchant level: many smaller merchants can self-assess, while larger merchants and service providers often need a QSA-led ROC.

Our penetration testing guide for IT managers covers how to plan a test that satisfies Requirement 11 without disrupting production systems.

Mapping real controls to PCI requirements

Translating PCI DSS into actual IT projects is where most businesses get stuck. Here is how the controls line up:

  • Multi-factor authentication and identity management satisfy Requirements 7 and 8 by restricting and verifying who can reach the CDE.
  • Encryption and tokenization satisfy Requirements 3 and 4 by making stored and transmitted card data unreadable without the right keys.
  • Vulnerability scanning, endpoint detection and response (EDR), and patch management satisfy Requirements 5, 6, and 11 by keeping malware out and known flaws closed.
  • Security information and event management (SIEM) tools and log retention policies satisfy Requirement 10 by giving you a record of who touched what and when.
  • Encrypted, tested backups and documented data disposal procedures support Requirement 3's data retention limits and give you a path back after an incident.

Each of these is also exactly the kind of control that shows up on a cyber insurance questionnaire. Insurers increasingly expect MFA, EDR, immutable backups, and a documented incident response plan before they will underwrite a policy, which means PCI work and cyber liability insurance requirements overlap more than most businesses realize.

Pro Tip: Build your remediation roadmap around controls that satisfy both PCI DSS and your cyber insurance questionnaire. Implementing MFA and EDR once covers two compliance conversations instead of one.

Shared security controls mapped to requirements

What auditors and assessors expect to see

Whether you are completing a SAQ or going through a QSA-led assessment, the evidence request looks similar. Gather these before your assessment window opens:

  1. A current data flow diagram and documented evidence of your annual scope confirmation under Requirement 12.5.2.
  2. Written information security policies and procedures covering each of the 12 requirement groups.
  3. ASV scan reports from the past 12 months, plus your most recent penetration test report and remediation evidence for anything flagged.
  4. Your completed SAQ or ROC, along with your AOC.
  5. AOCs from any third-party service provider (TPSP) whose systems touch your card data.
  6. Staff training records showing security awareness training has been completed.

Our retail customer data protection guide covers how to build the data flow documentation auditors ask for first. If outsourcing is part of your setup, confirm your TPSP's AOC actually covers the services you use. Middlebury's summary of PCI DSS v4.0.1 notes that merchants remain responsible for verifying a TPSP's compliance scope rather than assuming outsourcing covers everything.

Timeline, pitfalls, and a checklist to start today

A realistic SMB remediation plan runs in three stages. In the first 30 days, map your CDE and identify gaps against the 12 requirement groups. By 90 days, close the highest-risk gaps: MFA, encryption, and firewall rules. By 180 days, complete your ASV scans, penetration test, and SAQ or ROC submission.

Watch for these common failure points:

  1. Scope creep from systems like help desk tools or backup servers that quietly connect to the CDE.
  2. Embedded JavaScript or iFrames on payment pages that pull content from the merchant's own domain, which can pull the merchant back into full CDE scope even when processing is outsourced, according to PCI SSC's v4.0.1 guidance.
  3. Storing sensitive authentication data like full magnetic stripe content or CVV numbers after authorization, which PCI DSS prohibits outright.
  4. Insufficient TPSP vetting, meaning no one ever asked the processor for its AOC or confirmed it covers the services actually in use.

A fast checklist: confirm your CDE, request your TPSP's AOC, schedule your ASV scan, and assign an owner to Requirement 12.5.2 before the year ends.

How Ventis Consulting Group supports PCI readiness

Some IT consulting firms work with small and mid-sized businesses in various regions on IT and cybersecurity work related to PCI compliance. The relevant pieces of that work include:

  • Free Cyber Security Assessments that identify where your current environment falls short of PCI DSS requirement groups.
  • Managed Detection & Response, which builds the logging and monitoring evidence Requirement 10 calls for.
  • Penetration Testing that satisfies Requirement 11 and gives you a report ready for your assessor.
  • Cybersecurity & Compliance support for building the policies and documentation auditors expect to see.

A typical engagement starts with scoping your CDE, moves into a gap assessment against the 12 requirement groups, and produces a remediation roadmap with clear ownership for each gap before your assessment window opens.

Why compliance has to be a program, not a project

Most businesses treat PCI compliance as something to finish and file away. That mindset is exactly why scope creep keeps happening: a new VoIP system or SaaS integration gets added, nobody updates the data flow diagram, and the next assessment starts from a worse position than the last one.

Treat compliance as an operating rhythm instead. Put scope confirmation on the calendar, run a short tabletop exercise with your team once a year, and loop your cyber insurance renewal into the same review. Insurers are asking harder questions about MFA, backups, and incident response, and a business that already tracks this for PCI has the answers ready.

— Greg

Get help closing your PCI compliance gaps

Figuring out your CDE, your SAQ type, and your remediation priorities takes real IT hours most business owners do not have lying around. Some IT consulting providers offer local teams to assist businesses with PCI compliance work, emphasizing consultative approaches rather than generic national service desks, and may offer competitive technology pricing.

Ventis Consulting Group

Services relevant to PCI readiness include:

  • Free Cyber Security Assessments to find your current gaps against the 12 requirement groups.
  • Managed Detection & Response for the logging and monitoring evidence Requirement 10 requires.
  • Penetration Testing to satisfy Requirement 11 with a report your assessor can use.
  • Cybersecurity & Compliance services to build out policies, documentation, and scope confirmation on an ongoing basis.

Visit our end-to-end IT solutions page to see the full range of services, or reach out to schedule a free cyber security assessment and get a clear view of where your PCI gaps stand.

FAQ

Is PCI compliance legally required?

PCI compliance is not a federal law, but it is a contractual requirement enforced by card brands and acquiring banks through merchant agreements. Failing to comply can lead to fines, higher transaction fees, or loss of your ability to accept card payments.

What are the PCI compliance requirements for 2026?

The current standard is PCI DSS v4.x, which replaced v3.2.1 and introduced a set of future-dated requirements that became effective on March 31, 2025, including the annual scope confirmation mandated by Requirement 12.5.2.

What are the 12 requirements for PCI compliance?

The 12 PCI DSS requirement groups cover network security, protecting stored and transmitted cardholder data, vulnerability management, strong access control, physical security, logging and monitoring, regular testing, and a written information security policy. Each group maps to specific controls like firewalls, encryption, multi-factor authentication, and vulnerability scanning.

Who is required to be compliant with PCI?

Any business or service provider that stores, processes, or transmits cardholder data must comply with PCI DSS, along with any entity whose systems could affect the security of that data. Your merchant level, set by your card brand and acquirer based on transaction volume, determines which validation route and SAQ type applies to you.

Sources