Skip to content
Sovereign SecureSovereign Secure

Free tool · PCI DSS v4.0.1

Free PCI Compliance Test: Check Your Readiness in 5 Minutes

Answer 22 quick questions about your payment set-up, your scope and the 12 PCI DSS requirements. In about five minutes you get a readiness score, your likely SAQ, the gaps an assessor would find and the fix for each. Your answers stay in your browser and are not sent unless you choose to send them.

Start the checkRead the full checklist
  • 22 questions, about 5 minutes
  • Built by a PCI SSC-approved QSA company
  • No sign-up, not sent unless you choose

The short answer

A PCI compliance test, or readiness check, shows how close you are to meeting PCI DSS v4.0.1 before you sign a Self-Assessment Questionnaire (SAQ) or face a QSA. Answer 22 questions on your scope, your SAQ and the 12 requirements to get a readiness score, your critical gaps and the fix for each.

Built by Sovereign Secure, a PCI SSC-approved Qualified Security Assessor (QSA) company, from PCI DSS v4.0.1, including the future-dated requirements that became mandatory on 31 March 2025, and the current SAQs.

Check your PCI DSS readiness

Answer for everything in scope: every channel, location, system and provider that handles card data. If you don't know an answer, choose Unsure.

00

Your payment set-up (optional)

Used only to suggest your likely SAQ in your results. It doesn't affect your score.

Your business
How you take card payments (tick all that apply)

Online

In person

Phone and mail order

01

Scope and SAQ fit

Validation, 12.5 and 12.8

Which validation applies to you and what is in scope. Every other answer depends on getting this right.

1. Do you know which Self-Assessment Questionnaire (SAQ), or whether a Report on Compliance (ROC), applies to each way you take card payments, and have you checked that you meet every eligibility criterion in it?

PCI DSS Validation

Each SAQ starts with eligibility criteria, and you must meet all of them for every transaction in that channel.

Why it matters and how to fix it
List every way you take card payments (website, card terminals, phone, mail and payment links) and match each one to its SAQ. Then read the eligibility criteria at the start of that SAQ and confirm you meet every one. Several channels can mean several SAQs, or a single SAQ D if your acquirer prefers. Level 1 merchants and service providers usually validate with a ROC instead, and your acquirer has the final say.
Which PCI SAQ do I need? →
2. Have you documented and confirmed your PCI DSS scope in the last 12 months: every location and flow of card data, and every system that stores, processes or transmits it or could affect its security?

PCI DSS Req. 12.5.2

Service providers must confirm their scope at least once every six months.

Why it matters and how to fix it
Map where card data enters, moves through and leaves your business in a data-flow diagram, and list every system, person and third party involved, including systems that connect to or could affect those handling card data. Requirement 12.5.2 asks you to confirm this scope at least once every 12 months and after significant changes (every six months for service providers, under 12.5.2.1). Reducing what card data touches, for example with a hosted payment page or tokenisation, is the most effective way to shrink the work.
PCI DSS scoping guide →
3. Have you checked that full card numbers are not held electronically anywhere except where you deliberately store them, including email, spreadsheets, shared drives, chat, CRM notes and call or screen recordings?

PCI DSS Req. 3.2.1 and SAQ eligibility

Tokens issued by your payment provider are not card numbers.

Why it matters and how to fix it
Search your systems for card numbers (a data discovery tool helps), securely delete what you do not need and change the process that put them there, for example by asking customers not to email card details. Any electronic storage of card numbers rules out every SAQ except SAQ D. Where you must keep them, the storage rules in Requirement 3 apply in full.
Requirement 3: protecting stored card data →
4. Do you keep a list of every third-party service provider that handles card data for you or could affect its security, with a written agreement for each and their PCI DSS compliance status checked at least once every 12 months?

PCI DSS Req. 12.8

Payment gateways, hosting and cloud providers, managed IT providers, outsourced contact centres and web agencies all count.

Why it matters and how to fix it
List each provider and the service it gives you, put a written agreement in place in which it acknowledges responsibility for the card data it handles, and check its PCI DSS compliance status at least once every 12 months, usually by asking for its current Attestation of Compliance. Record which requirements each provider manages, which you manage and which are shared (Requirements 12.8.1 to 12.8.5). A compliant provider shrinks your scope, but it does not make you compliant on its own.
Requirement 12 in our PCI DSS checklist →
02

Secure network and systems

Requirements 1 and 2

Network security controls around card data, and secure, hardened configurations.

5. Are firewalls or other network security controls in place between the systems that handle card data and untrusted networks, including the internet, with every allowed connection justified and the rules reviewed at least every six months?

PCI DSS Req. 1.2 to 1.4

Choose Not applicable only if your SAQ does not include Requirement 1, for example because card data never passes through a network you manage.

Why it matters and how to fix it
Put network security controls between the systems that handle card data and everything else, allow only the traffic you need and record the business reason for every allowed service, protocol and port (1.2.5). Keep network and data-flow diagrams current (1.2.3 and 1.2.4) and review rule sets at least once every six months (1.2.7). Segmenting the card data environment from the rest of your network keeps other systems out of scope, but the segmentation must then be tested.
Requirements 1 and 2 in our PCI DSS checklist →
6. Have vendor default passwords been changed, or unused default accounts removed or disabled, on every in-scope system, and is each type of system built to a documented secure configuration standard?

PCI DSS Req. 2.2 and 2.3

Include tills and payment software, routers, wireless access points, servers, databases and admin consoles.

Choose Not applicable only if your SAQ does not include Requirement 2.

Why it matters and how to fix it
Change every vendor default password, or remove or disable the default account if you do not use it (2.2.2), and change wireless vendor defaults too (2.3.1). Write configuration standards for each type of system, based on industry hardening guidance or vendor recommendations, and apply them to new and existing systems (2.2.1). Remove services, functions and software you do not need.
Requirements 1 and 2 in our PCI DSS checklist →
03

Protect account data

Requirements 3 and 4

What you may keep, how stored card numbers are protected and how card data travels.

7. Are you certain that sensitive authentication data is never kept after a payment is authorised: the card security code, full magnetic stripe or chip data, and PINs or PIN blocks, including in call recordings, notes, emails and logs?

PCI DSS Req. 3.3.1

This applies even if the data is encrypted. Answer Yes if you never record it at all.

Critical: fix first if not met

Why it matters and how to fix it
Keeping sensitive authentication data after authorisation is prohibited for merchants, even if it is encrypted. The usual culprits are card security codes written on order forms or in notes, captured in call or screen recordings, or left in application logs and debug files. Find and securely delete them, then change the process: pause or mask recordings while card details are given, or move phone payments to DTMF masking so the data never reaches your staff or systems.
Requirement 3: protecting stored card data →
8. If you store full card numbers electronically, are they kept only as long as a written retention policy allows, made unreadable wherever they are stored, and masked when displayed?

PCI DSS Req. 3.2.1, 3.4.1 and 3.5.1

Choose Not applicable only if you do not store full card numbers electronically anywhere.

Why it matters and how to fix it
Set a retention period with a business reason, delete card numbers when it passes and check at least every three months for data held past its date (3.2.1). Make stored card numbers unreadable with strong cryptography and proper key management, tokenisation, truncation or keyed cryptographic hashing (3.5.1 and 3.5.1.1). Disk-level encryption on its own is no longer enough for non-removable media (3.5.1.2). Mask card numbers on screens and reports so that only people with a business need see more than the BIN and last four digits (3.4.1). Better still, ask whether you need to store them at all.
Requirement 3: protecting stored card data →
9. Is card data always protected with strong cryptography when it is sent over the internet, wireless or other public networks, and are card numbers never sent unprotected by email, chat or text message?

PCI DSS Req. 4.2

Choose Not applicable only if your SAQ does not include Requirement 4, for example because your payment provider captures card data directly.

Why it matters and how to fix it
Use strong cryptography, such as a current version of TLS with trusted, valid certificates, wherever card data crosses a public network (4.2.1), and keep an inventory of the keys and certificates you rely on (4.2.1.1). Never send or accept card numbers through email, chat or text unless they are protected with strong cryptography (4.2.2). If customers email card details anyway, securely delete the message and tell them how to pay safely.
Requirements 3 and 4 in our PCI DSS checklist →
04

Vulnerability management

Requirements 5 and 6

Malware protection, patching and secure software, including the payment page.

10. Is anti-malware software running and kept up to date on every in-scope system at risk from malware, with technical controls in place to detect and protect staff against phishing emails?

PCI DSS Req. 5.2, 5.3 and 5.4.1

Choose Not applicable only if your SAQ does not include Requirement 5.

Why it matters and how to fix it
Deploy anti-malware on all in-scope systems, keep it updated automatically and stop users switching it off (5.2 and 5.3). For any system you judge not at risk from malware, record that judgement and re-evaluate it periodically (5.2.3). Since 31 March 2025, Requirement 5.4.1 also needs processes and automated mechanisms to detect and protect personnel against phishing, such as email filtering and anti-spoofing controls (SPF, DKIM and DMARC).
Requirements 5 and 6 in our PCI DSS checklist →
11. Do you track security vulnerabilities in the systems and software you use, and install patches for critical vulnerabilities within one month of release?

PCI DSS Req. 6.3

Choose Not applicable only if your SAQ does not include Requirement 6.3.

Why it matters and how to fix it
Monitor vendor and industry sources for new vulnerabilities, rank them by risk (6.3.1) and install patches for critical vulnerabilities within one month of release, with other patches installed within a time frame you have set (6.3.3). Keep an inventory of your bespoke and custom software and the third-party components in it, so you know what to patch (6.3.2). Replace anything its vendor no longer supports.
Requirements 5 and 6 in our PCI DSS checklist →
12. Are your in-scope public-facing web applications protected by an automated technical solution, such as a web application firewall, that continually detects and prevents web-based attacks?

PCI DSS Req. 6.4.1 and 6.4.2

Choose Not applicable only if you have no public-facing web applications in scope, or your SAQ does not include Requirement 6.4.2.

Why it matters and how to fix it
Since 31 March 2025, Requirement 6.4.2 needs an automated technical solution, such as a web application firewall, in front of public-facing web applications, kept up to date and set to block web-based attacks or raise an alert that is investigated straight away. Periodic vulnerability reviews under 6.4.1 are no longer an alternative. Develop bespoke software securely, with developer training and code reviewed before release (6.2).
Requirements 5 and 6 in our PCI DSS checklist →
13. If you take card payments online, are the scripts on your payment page under control: an inventory with a reason for each one, a check that each is authorised and unaltered, and alerts for unauthorised changes to the page and its security headers?

PCI DSS Req. 6.4.3 and 11.6.1

Using SAQ A with the provider's embedded payment form (iframe)? Answer Yes only if you have confirmed your site is not susceptible to attacks from scripts that could affect your e-commerce systems, which is now an SAQ A eligibility criterion. If you redirect customers to the provider's own payment page, this criterion does not apply.

Critical: fix first if not met

Choose Not applicable only if you do not take card payments online, or you redirect customers to your payment provider's own payment page.

Why it matters and how to fix it
Requirements 6.4.3 and 11.6.1 became mandatory on 31 March 2025 for e-commerce merchants validating with SAQ A-EP, SAQ D or a ROC. Keep an inventory of every script loaded on the payment page with a written business or technical reason, a method to confirm each one is authorised and a method to assure its integrity (6.4.3). Deploy a change- and tamper-detection mechanism that alerts you to unauthorised changes to the page's scripts and security-impacting HTTP headers as the customer's browser receives them, at least weekly or at a frequency set by a targeted risk analysis (11.6.1). SAQ A merchants that embed the provider's payment form (iframe) instead confirm their site is not susceptible to script attacks, for example with protections like these or written confirmation from their payment provider; a full redirect to the provider's payment page does not need this.
SAQ A, SAQ A-EP and payment page scripts →
05

Access control

Requirements 7, 8 and 9

Need-to-know access, strong authentication and physical protection.

14. Does everyone with access to card data or in-scope systems have their own user ID with only the access their job needs, with leavers removed immediately and all accounts reviewed at least every six months?

PCI DSS Req. 7.2 and 8.2

Choose Not applicable only if your SAQ does not include Requirements 7 and 8.2.

Why it matters and how to fix it
Give each person their own account, with no shared or generic logins except where strictly controlled (8.2.1 and 8.2.2). Grant access by job role on a need-to-know basis (7.2.1 and 7.2.2), remove leavers immediately (8.2.5) and remove or disable accounts unused for 90 days (8.2.6). Review all user accounts and their access at least once every six months, and record that you did (7.2.4).
Requirement 8: identify users and authenticate access →
15. Is multi-factor authentication (MFA) required for all access into your card data environment and for all remote access that could reach it, and are passwords at least 12 characters long?

PCI DSS Req. 8.3.6 and 8.4

Where a system cannot support 12 characters, at least 8 are required.

Choose Not applicable only if your SAQ does not include Requirements 8.3 and 8.4.

Why it matters and how to fix it
Since 31 March 2025, MFA is required for all non-console access into the cardholder data environment, not only for administrators (8.4.2), as well as for all remote access from outside your network that could reach or affect it (8.4.3). Passwords must be at least 12 characters, or 8 where a system cannot support 12, and contain both letters and numbers (8.3.6). Check supplier and vendor remote access too.
Requirement 8: identify users and authenticate access →
16. Are your card terminals listed and inspected regularly for tampering or substitution, are staff trained to spot it, and is any paper holding card data locked away and shredded when no longer needed?

PCI DSS Req. 9.4 and 9.5

Choose Not applicable only if you have no card terminals and never hold card data on paper or other media.

Why it matters and how to fix it
Keep an up-to-date list of every card terminal with its make, model, location and serial number (9.5.1.1), inspect terminals for tampering and substitution at a frequency set by a targeted risk analysis (9.5.1.2 and 9.5.1.2.1), and train staff to spot suspicious behaviour, such as people posing as repair engineers (9.5.1.3). Lock away paper records containing card data and destroy them by cross-cut shredding, incineration or pulping once they are no longer needed (9.4.1 and 9.4.6).
Requirements 7 to 9 in our PCI DSS checklist →
06

Monitoring and testing

Requirements 10 and 11

Logging, quarterly scans and penetration testing.

17. Are audit logs switched on for all in-scope systems, reviewed at least daily with the help of automated tools, and kept for at least 12 months with the latest three months immediately available?

PCI DSS Req. 10.2, 10.4 and 10.5

Choose Not applicable only if your SAQ does not include Requirement 10.

Why it matters and how to fix it
Enable audit logging on every in-scope system, recording access to card data, administrator actions, failed logins and changes to security settings (10.2). Review security events at least once daily (10.4.1) and, since 31 March 2025, use automated mechanisms such as a SIEM to do it (10.4.1.1). Keep at least 12 months of log history, with the most recent three months immediately available for analysis (10.5.1), and make sure failures of critical security controls are detected and dealt with promptly (10.7.2).
Requirement 10: log and monitor all access →
18. Do you have a passing external vulnerability scan from a PCI SSC Approved Scanning Vendor (ASV) for every three-month period, with rescans after fixes until each one passes?

PCI DSS Req. 11.3.2

SAQs that cover internet-facing systems, including SAQ A, A-EP, C and D, require these scans.

Critical: fix first if not met

Choose Not applicable only if your SAQ does not include Requirement 11.3.2.

Why it matters and how to fix it
Have every internet-facing system in scope scanned by an ASV at least once every three months and after significant changes (11.3.2 and 11.3.2.1), fix anything that fails and rescan until you have a passing result for each quarter. For a first validation, one recent passing scan with a documented quarterly scanning process and evidence of rescans can be accepted in place of four. If your SAQ or ROC includes internal scanning, run internal scans every three months too, using authenticated scanning since 31 March 2025 (11.3.1 and 11.3.1.2).
PCI vulnerability scanning explained →
19. Are internal and external penetration tests carried out at least once every 12 months and after significant changes, with segmentation controls tested as well if you use segmentation to reduce scope?

PCI DSS Req. 11.4

Penetration testing under Requirement 11.4 is part of SAQ D, SAQ A-EP (external testing) and a ROC; SAQ B-IP and C include segmentation testing (11.4.5) if you use segmentation. Check your SAQ if you use another one.

Choose Not applicable only if your SAQ does not include Requirement 11.4.

Why it matters and how to fix it
Have a qualified internal resource or third party test your card data environment and its perimeter from inside and outside at least once every 12 months and after any significant infrastructure or application change, following a documented methodology (11.4.1 to 11.4.3). Fix exploitable vulnerabilities and retest to confirm. If segmentation keeps other networks out of scope, test it at least once every 12 months, or every six months for service providers (11.4.5 and 11.4.6). An ASV scan is not a penetration test.
PCI DSS penetration testing →
07

Security policy and response

Requirement 12

Policies, people and being ready for an incident.

20. Do you have an information security policy, reviewed at least once every 12 months, with documented roles and responsibilities for PCI DSS and a targeted risk analysis wherever you set your own frequency for a control?

PCI DSS Req. 12.1 and 12.3.1

Choose Not applicable only if your SAQ does not include Requirement 12.1.

Why it matters and how to fix it
Publish an information security policy, share it with everyone it affects and review it at least once every 12 months (12.1.1 and 12.1.2). Assign responsibility for each requirement that applies to you and make sure staff know their roles. Where the standard lets you choose how often to perform a control, such as inspecting card terminals, document a targeted risk analysis to justify the frequency (12.3.1).
PCI DSS policies and documentation →
21. Do all staff get security awareness training when they join and at least once every 12 months, covering phishing and social engineering?

PCI DSS Req. 12.6

Choose Not applicable only if your SAQ does not include Requirement 12.6.

Why it matters and how to fix it
Run a formal security awareness programme (12.6.1) with training on joining and at least once every 12 months, and have staff acknowledge at least once every 12 months that they have read and understood your security policy (12.6.3). Since 31 March 2025 the training must cover threats such as phishing and social engineering (12.6.3.1). Keep attendance records as evidence.
PCI DSS training requirements →
22. Do you have a written incident response plan for a suspected card data breach, including who tells your acquirer and the card brands, and is it tested at least once every 12 months?

PCI DSS Req. 12.10

Why it matters and how to fix it
Write a plan that can be put into action immediately, covering roles, contacts and communication (including notifying your acquirer and the card brands), containment steps, business recovery and your legal reporting duties (12.10.1). Test it at least once every 12 months, for example with a tabletop exercise, and update it after tests and real incidents (12.10.2 and 12.10.6). If personal data is involved, UK GDPR may also require you to report the breach to the ICO within 72 hours of becoming aware of it.
Requirement 12 in our PCI DSS checklist →

How do I know if I'm PCI compliant?

Start with your acquirer. Many show your validation status in their PCI compliance portal, and a monthly non-compliance fee on your statement usually means they hold no current SAQ or Attestation of Compliance for you. Worldpay merchants, for example, validate through its SaferPayments portal, as our guide to Worldpay PCI compliance explains. Then check the substance: work out which SAQ or Report on Compliance applies to you and confirm that every requirement in it is in place, with evidence.

The PCI compliance checker above does the second part in about five minutes. For the detail behind each answer, our PCI DSS compliance checklist covers all 12 requirements with the evidence a QSA will ask for.

Is PCI compliance a legal requirement in the UK? No. It is a contractual requirement that your acquirer sets in your merchant agreement, and our guide to PCI compliance in the UK explains what that means for you.

What is a PCI compliance test?

PCI compliance testing can mean a readiness check like this one, a quarterly external scan by an Approved Scanning Vendor (ASV) or a penetration test. There is no single official PCI compliance test, and none of the three makes you compliant on its own.

What "PCI compliance test" can meanWhat it checksWho carries it outDoes it confirm compliance?
Readiness self-check (this page)Your answers against the core of each of the 12 requirements, and your likely SAQYou, in about five minutesNo, it shows your gaps
ASV scanInternet-facing systems for known vulnerabilities, every quarter (Requirement 11.3.2)A PCI SSC Approved Scanning Vendor; ours are delivered through our PCI SSC Approved Scanning Vendor partnerNo, it meets one requirement
PCI penetration testWhether weaknesses can be exploited, and whether segmentation works (Requirement 11.4)A qualified, organisationally independent internal resource or third partyNo, it meets one requirement

Compliance itself is confirmed only by validating against the whole standard: a Self-Assessment Questionnaire with an Attestation of Compliance for organisations allowed to self-assess, or a Report on Compliance, usually from a QSA. Use the check to find your gaps, the scans and tests to meet Requirements 11.3 and 11.4, and the SAQ or ROC to prove the rest.

Is a PCI scan the same as PCI compliance?

No. A passing quarterly ASV scan satisfies Requirement 11.3.2 and nothing else, so you still need every other requirement in your SAQ or ROC. Our PCI ASV scanning is delivered through our PCI SSC Approved Scanning Vendor partner, and you can check any scanning company against the PCI SSC's official list of Approved Scanning Vendors.

How is the readiness score worked out?

PCI DSS has no pass mark: every requirement that applies to you must be in place. The score shows how close you are. Critical gaps count three times, high-impact gaps twice and the rest once. "No" and "Unsure" both score zero, because an assessor can only accept what you can evidence, and "Not applicable" answers are left out.

Your resultWhat it meansSuggested next step
100%No gaps found in the core requirementsComplete your SAQ, or book a QSA assessment if you need a Report on Compliance
80% to 99% with no critical gapsClose to readyFix the remaining items and gather evidence, then validate
50% to 79%, or any critical gapSignificant gapsA gap analysis and a prioritised remediation plan
Below 50%Not ready yetConfirm your scope and SAQ first, then a gap analysis with our PCI DSS consultancy team

What should you do after the check?

  1. Fix critical gaps first: sensitive authentication data, quarterly ASV scans and payment page scripts.
  2. Confirm your SAQ with our guide to which PCI SAQ you need, reading the eligibility criteria in the SAQ itself.
  3. Work through your fix list and collect evidence for each requirement as you go.
  4. Book scans and testing early, because a failed scan or test needs fixing and retesting before you can validate.
  5. Validate: sign your SAQ and Attestation of Compliance, or book a QSA assessment if your acquirer or customers require one.

Do you need PCI compliance software?

Not always. PCI compliance software helps you organise the work, and for a business with several payment channels or a long SAQ it can save time, but it does not make you compliant and it cannot do the parts of PCI DSS that need an independent assessor or tester. A small merchant on a short SAQ can often manage with the acquirer's portal, the free SAQ and a free way to check PCI compliance readiness, such as the tool on this page.

What PCI compliance software doesWhat it cannot do
Policy templates you adapt to your businessChoose the right SAQ for you: it can only apply the answers you give it, and a wrong answer about how payments flow puts you on the wrong SAQ
Evidence collection, with owners and reminders when evidence goes out of dateSign a Report on Compliance, which only a QSA (or an ISA where the card brand allows it) can do
Scan scheduling and tracking of ASV resultsReplace the QSA that Level 1 merchants and Level 1 service providers need for their annual ROC
SAQ workflow: questions, responsibilities and sign-offTest segmentation, which Requirement 11.4.5 gives to a qualified, organisationally independent tester

Before you buy, check which SAQs and requirements the product covers, and whether it runs external scans or only schedules them: the quarterly scans must still come from a PCI SSC Approved Scanning Vendor. Our guide to PCI compliance cost shows where software and tooling sit among your other costs.

Can I do PCI compliance myself? Usually yes, and our guide to PCI compliance in the UK explains when you can and when you cannot. If you would rather have a person than a platform, our PCI DSS consultancy team confirms your scope and SAQ and builds the remediation plan with you.

Why Sovereign Secure?

Sovereign Secure Ltd is a PCI SSC-approved Qualified Security Assessor (QSA) company, Qualified PIN Assessor (QPA), Card Production Security Assessor (CPSA), P2PE Assessor and 3DS Assessor, and a member of the PCI SSC Global Executive Assessor Roundtable (GEAR) for 2026 to 2028. We are also ISO 27001 certified.

Where we both advise and assess the same organisation, the advisory and assessment work are kept separate, as the PCI SSC expects of a QSA company. Consultancy helps you prepare; it never changes the standard your assessment is held to. Found gaps you want help with? Call +44 161 523 5276 or contact us for a fixed quote.

Last updated October 2026, against PCI DSS v4.0.1 and the current SAQs.

Trusted by banks, payment providers and global brands

  • Accor
  • Fiserv
  • JCPenney
  • Ticketmaster
  • Nitecrest
  • Cashplus
  • Ahli United Bank
  • Kuwait Finance House
  • AYA Bank
  • Bank of Palestine
  • Liquid Pay
  • DataFlow Group
  • Wilmington
  • The Growth Company
  • Wahyukart

FAQ

Frequently asked questions

Can't find your answer? Call us on +44 161 523 5276 or send us a message.

Is the PCI compliance check free?

Yes. It is free, needs no sign-up and runs entirely in your browser. Your answers are not stored and are not sent to Sovereign Secure unless you choose to copy them into the enquiry form and send it: close or refresh the page and they are gone. Our privacy policy explains how we handle anything you do send.

Does a 100% score mean I am PCI compliant?

No. Compliance is confirmed only by validation: a Self-Assessment Questionnaire with an Attestation of Compliance, or a Report on Compliance from a QSA, accepted by your acquirer. This check covers the core of each of the 12 requirements, while your SAQ or the full standard has many more sub-requirements to evidence.

Is this an official PCI SSC tool?

No. Sovereign Secure, a PCI SSC-approved Qualified Security Assessor (QSA) company, built it from PCI DSS v4.0.1 and the current SAQs. The standard and every SAQ are free to download from the PCI SSC document library.

Is a PCI scan the same as PCI compliance?

No. A passing scan from an Approved Scanning Vendor meets Requirement 11.3.2, which is one requirement among many. You still need every other requirement in your SAQ or ROC in place; see PCI ASV scanning for how quarterly scans work.

When should I answer Not applicable?

Only when the note under the question describes your situation, usually because your SAQ does not include that requirement. Not applicable answers are left out of your score, and you should keep a short note of why each one is out of scope, because an assessor or your acquirer may ask.

Which SAQ do I need?

It depends on how you take card payments and whether card data touches your systems. Fully outsourced online payments usually mean SAQ A, while storing card numbers electronically means SAQ D. Our guide to which PCI SAQ you need compares every type.

Can I get PCI compliance for free?

Partly. PCI DSS, every SAQ and this check are free, and a small merchant eligible for a short SAQ can often complete and sign it without paying an assessor. The costs come from ASV scans, penetration tests, fixing gaps and any QSA work your validation route requires; our guide to PCI compliance cost explains each one. Small merchants can follow our guide to PCI compliance for small businesses.

How much does PCI compliance cost?

It depends on your validation route, your scope and how many gaps need fixing, so we quote each piece of work after a short scoping call. Our guide to PCI compliance cost explains the cost drivers and includes a free estimator.

How often should I check my PCI compliance?

You validate once a year, but check again whenever you change how you take payments, your payment provider or the systems that handle card data. PCI DSS also asks you to confirm your scope at least once every 12 months, or every six months for service providers.

Free consultation

Found gaps? Get a fixed quote

Send your results and your deadline, and we will come back within one working day with a clear scope and a fixed quote. The quote button under your results copies them into this form for you.

  • PCI SSC-approved QSA, QPA, CPSA, P2PE and 3DS assessors
  • IASME-licensed Cyber Essentials certification body
  • Clients across the UK, US, Europe, Middle East and Asia since 2012

“We would happily recommend them to any company in need of the services mentioned.”

Emir Handan, Executive Director, Bamcard. Read the full testimonial

Call +44 161 523 5276

Email [email protected]

By sending this form you agree to us contacting you about your enquiry. See our privacy policy.

We aim to reply within one working day. The first consultation is free.