Skip to main content
  • For Support:

    815-308-2095

  • New Client
    815-788-6041

Free PCI Compliance Checklist: See If Your Business Handles Cards Safely

PCI DSS Risk Check

  • 9 quick questions
  • Takes about 2 minutes
  • No sign-up to see your result

Your top next moves

    Nothing critical flagged. Keep everything current and re-check yearly.

    Book a call

    Answer 9 quick questions grounded in PCI DSS v4.0.1 and get your risk level in about 2 minutes, the specific gaps to fix and a checklist you can hand to your team or IT provider.

    No sign-up to see your result.

    “Not sure” counts, because if you can’t confirm it, neither can your card processor.

    What PCI Compliance Actually Is (The Short Version)

    PCI DSS (the Payment Card Industry Data Security Standard) is the rulebook every business that accepts, processes, stores, or transmits credit-card data has to follow. It isn’t a law, but your bank and card brands (Visa, Mastercard, Amex, Discover) enforce it through your merchant agreement, so in practice it’s not optional. The current version is PCI DSS v4.0.1, built around 12 requirements grouped into six control areas:


        • Build and maintain a secure network

        • Protect stored cardholder data

        • Run a vulnerability-management program

        • Enforce strong access control

        • Maintain a security policy

        • Monitor and test networks

    Most small and mid-sized businesses demonstrate compliance by completing a yearly Self-Assessment Questionnaire (SAQ), the right one for how you take cards, and, if you accept cards online, an Approved Scanning Vendor (ASV) scan every quarter.

     

    The checklist below is organized around the 12 requirements and matches the 8 questions in the tool above, so a “no” or “not sure” up top maps straight to a section here:

    The PCI Compliance Checklist (PCI DSS v4.0.1)

    Work through each area. Anything you can’t confirm is a gap, if you can’t prove it, your processor or a QSA can’t either.

    • 1. Don’t Store Card Data You Don’t Need, and Encrypt What You Do (Req. 3)

      You never store the full card number (PAN) anywhere you don’t absolutely need it, check spreadsheets, email, notes, CRM fields, and paper too.

      You never store sensitive authentication data (the CVV/security code, full magnetic-stripe, or PIN) after a transaction is authorized, this is prohibited outright.

      Any cardholder data you do retain is rendered unreadable (strong encryption, truncation, or tokenization), with documented key management.

    • 2. Encrypt card data in transit (Req. 4):

      Card data only ever crosses the internet over a strong, current encrypted connection (HTTPS/TLS 1.2+)

      Card numbers are never sent by plain email, text, chat, or an unencrypted web form, that’s a violation on its own.

      Your payment page and any form that touches card data are served over HTTPS with a valid certificate

    • 3. Require Multi-Factor Authentication into the Card Environment (Req. 8):

      Multi-factor authentication (MFA) is enforced for all access into the cardholder data environment, v4.0.1 expanded this beyond just remote/admin access.

      Every user has a unique ID; no shared or generic logins on systems that touch card data.

      Passwords meet the standard’s length and strength rules and are changed on any suspicion of compromise.

    • 4. Complete your SAQ and Required Scans (Req. 11 + validation):

      You’ve confirmed which SAQ applies to you (see the SAQ FAQ below) and complete it every year, your bank or processor tells you which one.

      If you accept cards online, you run quarterly ASV scans by an Approved Scanning Vendor and remediate anything that fails.

      Internal and external vulnerability scans are run on schedule and after significant network changes; penetration testing is done where your SAQ/level requires it.

    • 5. Firewall and Segment the Card Environment (Req. 1):

      A properly configured firewall sits in front of the systems that touch card data, with documented rules reviewed regularly

      The cardholder data environment is segmented away from guest WiFi, the front desk, and everyday office PCs, segmentation shrinks what has to be secured and what’s in scope for your SAQ

      Inbound and outbound traffic is restricted to only what the business needs

    • 6. Change Default Passwords and Harden Systems (Req. 2):

      Vendor-default passwords and settings have been changed on every router, switch, card terminal, POS device, and application, shipped defaults are public knowledge.

      Unnecessary services, accounts, and features are disabled; systems are configured to a documented hardening standard.

      An up-to-date inventory of in-scope hardware and software is maintained.

    • 7. Patch and Protect Against Malware (Req. 5 + 6):

      Anti-malware protection is installed, active, and current on all systems commonly affected by malware

      Security patches are applied on a defined schedule, with critical patches prioritized

      Web-facing applications are protected (secure development practices and/or a web application firewall) and reviewed for common vulnerabilities

    • 8. Least-Privilege Access and Logging (Req. 7 + 10):

      Access to cardholder data and systems is restricted to a need-to-know / least-privilege basis by role.

      Every individual has their own account, no shared credentials, so actions are traceable to a person. 

      Access to card systems and cardholder data is logged, logs are protected from tampering, and someone actually reviews them for unusual or failed access.

    • 9. Maintain the Policy and Program Wrapper (Req. 9 + 12):

      Physical access to systems and media that hold cardholder data is controlled (locked areas, visitor handling, secure disposal/wiping of devices and media)

      A written information-security policy is in place, reviewed at least annually, and the team is trained on it

      You have a documented, tested incident-response plan, and a current inventory of third parties (payment processors, gateways, IT provider) with their PCI responsibilities defined in writing

    How to read your gaps?

    Most of the technical items above (MFA, encryption, audit logging, tested backups) live in your IT setup, not a policy binder, which is the half of HIPAA a managed IT partner operates for you.

    • 0 – 2 “No/Not sure” Answers

      Strong Shape, keep your SAQ and scans current and re-check yearly.

    • 3 – 6 “No/Not sure” Answers

      Real, findable gaps that would show up if your processor or a QSA looked closely.

    • 7+ “No/Not sure” Answers

      Seven or more means you’d likely fail validation today and are carrying real breach and card-fraud risk right now.

    Most of the technical items above:  MFA, encryption, firewalling and segmentation, patching, logging, live in your IT setup, not a policy binder, which is the half of PCI a managed IT partner operates for you.

    PCI Compliance Checklist FAQ

    What’s on a PCI compliance checklist?

    A complete PCI checklist maps to the 12 requirements of PCI DSS v4.0.1: don’t store card data you don’t need and encrypt what you do, encrypt card data in transit, require MFA and unique logins into the card environment, complete your annual SAQ and quarterly ASV scans, firewall and segment the cardholder data environment, change vendor-default passwords and harden systems, patch and run anti-malware, restrict access on a least-privilege basis and log it, control physical access, and maintain a written security policy and tested incident-response plan. The nine areas above group those 12 requirements to match the tool at the top of this page.

    What is an SAQ, and which SAQ do I need?

    An SAQ (Self-Assessment Questionnaire) is how most merchants validate PCI compliance without a full on-site audit, you attest that you meet the requirements that apply to how you take cards. The right SAQ depends on your acceptance method: for example, SAQ A is for e-commerce merchants who fully outsource card handling to a compliant third party; SAQ A-EP for e-commerce sites that affect the payment page but don’t touch card data directly; SAQ B for imprint or standalone dial-out terminals; SAQ B-IP for standalone IP-connected terminals; SAQ C-VT for virtual terminals; SAQ C for payment applications connected to the internet; SAQ P2PE for validated point-to-point-encryption terminals; and SAQ D for everyone else, including service providers. Your acquiring bank or payment processor tells you which SAQ (and validation level) you’re required to complete, start there.

    Do small businesses need PCI compliance?

    Yes. PCI DSS applies to any business that accepts card payments, regardless of size or transaction volume, a small shop just has fewer systems and vendors to cover and usually a simpler SAQ. The gaps that trip up small businesses most are storing card numbers they shouldn’t, unchanged default passwords on terminals and routers, missing MFA, and never completing the SAQ their processor expects. Smaller merchants generally self-assess rather than face a full audit, but the obligation itself is the same.

    What are the PCI DSS 12 requirements?

    PCI DSS v4.0.1 is built on twelve requirements. In order, they are: install and maintain network security controls (firewalls); apply secure configurations and change vendor defaults; protect stored cardholder data; protect cardholder data with strong cryptography during transmission; protect systems from malware; develop and maintain secure systems and software (patching); restrict access to cardholder data by business need-to-know; identify users and authenticate access with unique IDs plus MFA; restrict physical access to cardholder data; log and monitor all access to system components and cardholder data; test the security of systems and networks regularly through scans and penetration tests; and support information security across the organization with policies and programs. The checklist above condenses these into nine workable areas.

    What happens if I’m not PCI compliant?

    If you’re not compliant and it comes to light, usually after a breach or a failed scan, the consequences are real: monthly non-compliance fees from your acquirer, fines that can run from thousands to tens of thousands of dollars, higher transaction rates, mandatory forensic investigation, and in serious cases the loss of your ability to accept cards at all. More costly than the fines is a breach itself: recovery costs, card-reissuance charges, and lost customer trust. Because you can’t predict the timing, the practical answer is to close your gaps now and stay validation-ready year-round.

    Do we need a Business Associate Agreement with our IT provider?
    Yes. If your IT provider or MSP can access, store, or transmit ePHI (most can), they’re a business associate and a signed BAA is required before that access. LeadingIT signs BAAs with practice clients as standard.

    Ready to Close your gaps?

    If your result flagged three or more gaps, most of them are technical work an IT partner handles day to day, MFA, encryption, firewalling and segmentation, patching, and logging. LeadingIT has helped Chicagoland businesses lock down their payment environments and stay audit-ready since 2010.

    We’re not a QSA or ASV and we don’t certify or issue PCI compliance, we operate the security controls, documentation, and ongoing monitoring that get you there and keep you there, and we coordinate with your assessor and processor.

    Email yourself the full result from the tool above, book a free 30-minute gap review. or see how we deliver PCI compliance as a managed service.