Scrutineer · By framework

PCI SAQ software for PCI DSS self-assessment and SAQ D

A PCI SAQ is not a menu you pick from. Your payment architecture narrows the list to one questionnaire, and the acquirer or customer you submit it to confirms whether you may use an SAQ at all. Ten SAQs exist under PCI DSS v4.0.1, and a service provider may use exactly one of them.

Scrutineer holds the control evidence behind whichever SAQ applies and checks the Part 2 eligibility criteria before you answer anything. It is readiness work, not a QSA opinion, and it does not sign your Attestation of Compliance.

or try it below ↓

Control-mapped findings · linked evidence · you decide what to remediate

The Scrutiny Desk

Illustrative sample · not an audit attestation

SOC 2 ISO 27001 HIPAA GDPR PCI DSS

Controls in evidence-linked report out

AI scrutinizes you decide

Why it works

What you get with PCI SAQ

Eligibility settled before you answer anything

Most self-assessments go wrong in Part 2, not in the answers. Scrutineer holds each questionnaire’s eligibility criteria against how your payments are genuinely built, so you learn you are an SAQ A-EP shop before two hundred SAQ A answers have been written and an attestation has been signed against the wrong form.

One control library, every SAQ and every framework

The controls behind an SAQ are the same controls SOC 2, ISO 27001 and HIPAA already ask you to evidence. Scrutineer maps what you run once and answers each questionnaire from that map, so SAQ D does not become an annual rebuild of work three other audits already tested.

Evidence that is current in month eleven

An SAQ is an annual attestation, and most teams assemble it in the two weeks before it is due. Read-only connections to your cloud, identity and ticketing stack collect the artifacts behind each requirement continuously, so the evidence attached to a control is current when the acquirer, the customer or the QSA asks.

What it handles

Controls in, an evidence-linked report out

Point Scrutineer at a framework or a vendor and it maps every control, pulls the evidence it can find, flags the gaps and scores the risk, returning a report with linked evidence and a prioritized remediation list. Scrutineer is decision support for readiness, an accredited auditor still issues the attestation.

Checks the Part 2 eligibility criteria for each SAQ against your actual payment flow, before you commit to a questionnaire
Maps your existing controls to the requirements the chosen SAQ carries, so the work is closing genuine gaps rather than restating a program you already run
Tracks the January 2025 SAQ A change, which removed Requirements 6.4.3, 11.6.1 and the 12.3.1 targeted risk analysis and put a new eligibility criterion in their place
Holds the service provider material SAQ D adds, including the Section 2a documentation and the Describe Results entry the v4 questionnaires expect at each requirement
Keeps an open item list with named owners for everything answered No, so the remediation plan exists before the attestation date rather than after it
Reuses the same evidence for SOC 2, ISO 27001, HITRUST and HIPAA, because your acquirer and your enterprise customers are testing overlapping controls
Flags the requirements a self-assessment cannot close on its own, such as the ASV scan and the penetration test, so they are scheduled rather than discovered late
Keeps a dated record of who answered what, which is the part an acquirer or a QSA asks about when an attestation is challenged

PCI SAQ readiness_report

READINESS · 82%

ACCESS CONTROL 91

evidence · MFA enforced and access reviews evidenced.

CHANGE MGMT 78

evidence · Mostly covered; one approval log left untested.

VENDOR RISK 64

evidence · Two subprocessors missing a current review.

ENCRYPTION 86

evidence · Data encrypted in transit and at rest, evidenced.

Example report layout, not customer data

Why Scrutineer

One platform that maps controls and scores risk

Not a static questionnaire, not a pass-fail black box, and not a spreadsheet you maintain by hand. Live control mapping across SOC 2, ISO 27001, HIPAA, GDPR and PCI, automatic evidence and a prioritized gap list, returned as a report you can act on. The AI scrutinizes, you decide.

Mapped to real controls

Every framework is broken down into the controls it actually requires, each scored on a red to amber to green scale, so readiness stays transparent and consistent.

Evidence behind every finding

Each control links to the exact evidence that satisfies it, the policy, the config, the log line, so the finding is auditable and your readiness is defensible.

A prioritized gap list

Open gaps roll up into a ranked remediation list, so the highest-risk findings sit at the top and your team fixes what matters before the audit begins.

PCI SAQ eligibility reference

All ten PCI DSS v4.0.1 SAQs, what actually decides which one you may use, and where failing that test sends you

Guides to this topic present the SAQs as a menu and rank them by length. Length is not what decides anything. Every SAQ carries eligibility criteria in Part 2 that describe your payment architecture, and those criteria, not the questions, are where a self-assessment is won or lost. The column that matters most is the last one, because the cost of an eligibility mistake is not extra work, it is an attestation that does not validate the environment you actually run.

SAQ	Who may use it	What actually decides eligibility	What changed in v4.0.1 and 2025	Where failing eligibility sends you
SAQ A	Card-not-present merchants only	The payment page is fully outsourced, or is an embedded form served by a compliant third party	The January 2025 version removed Requirements 6.4.3, 11.6.1 and the 12.3.1 risk analysis, and added an eligibility criterion in their place. Effective 31 March 2025	SAQ A-EP or SAQ D, where the removed requirements still apply in full
SAQ A-EP	E-commerce merchants who do not fully outsource	Your website can affect the security of the transaction even though it never receives card data	Eligibility criteria clarified and completion guidance updated in the v4.0.1 release of 15 October 2024	SAQ D for Merchants
SAQ B	Merchants using imprint machines or standalone dial-out terminals	No electronic cardholder data storage, and no internet-connected payment device	Aligned to v4.0.1 wording with no eligibility change	SAQ B-IP or SAQ D
SAQ B-IP	Merchants with standalone IP-connected PTS-approved terminals	The terminal stands alone. v4.0.1 clarified it must not be connected to other device types in the same network zone	Eligibility clarified in v4.0.1	SAQ C or SAQ D
SAQ C	Merchants with a payment application system connected to the internet	No electronic cardholder data storage, and the payment application is not on a segmented, internet-facing shared system	A requirement was removed from SAQ C in the v4.0.1 release	SAQ D for Merchants
SAQ C-VT	Merchants keying transactions into a virtual terminal	One standalone computer, manual entry only. v4.0.1 removed segmentation from the criteria and confirmed the standalone limit	Eligibility criteria clarified in v4.0.1	SAQ C or SAQ D
SAQ P2PE	Merchants using a validated point-to-point encryption solution	The solution has to appear on the PCI SSC validated list. Buying encrypting hardware does not qualify you	Aligned to v4.0.1 wording	SAQ B-IP or SAQ D
SAQ SPoC	Merchants taking PIN entry on a phone or tablet through a validated SPoC solution	The same listing rule as P2PE. The solution, not the device, is what qualifies	Aligned to v4.0.1 wording	SAQ D for Merchants
SAQ D for Merchants	Every merchant not eligible for another SAQ	It is the default. Nothing about it is chosen	Aligned to v4.0.1 wording	Nowhere further. It already covers the full standard
SAQ D for Service Providers	Service providers, and nobody else	Nothing. The Council states that SAQ D for Service Providers is the only SAQ for SAQ-eligible service providers and that all other SAQs are for merchant use only	v4 added a Section 2a documentation list and a Describe Results entry at every requirement, both service provider only	A Report on Compliance, if your acquirer or a customer requires one instead

Facts on this page are taken from PCI Security Standards Council sources: the bulletin SAQs for PCI DSS v4.0.1 Now Available dated 15 October 2024, the Council announcement of the SAQ A updates published in January 2025, and FAQ 1588 effective 1 April 2025. Where published question counts disagree, the range is shown rather than a single invented figure. Standards and card brand rules change, so confirm your own eligibility with your acquirer or the entity receiving your attestation. Scrutineer prepares readiness evidence, is not a QSA or an ASV, and does not validate PCI DSS compliance.

Good questions

Questions about PCI SAQ

A PCI SAQ is the Self-Assessment Questionnaire a merchant or service provider completes to report the result of its own PCI DSS assessment, together with an Attestation of Compliance. The PCI Security Standards Council publishes the questionnaires as validation tools. It does not decide who may use one: the payment brands set validation levels, and the acquirer or customer you submit to confirms your eligibility.

Under PCI DSS v4.0.1 there are ten: SAQ A, SAQ A-EP, SAQ B, SAQ B-IP, SAQ C, SAQ C-VT, SAQ P2PE, SAQ SPoC, SAQ D for Merchants and SAQ D for Service Providers. Sources that list nine are usually leaving out SPoC, which covers PIN entry on a commercial phone or tablet through a validated solution.

You do not really choose it. How your business accepts and handles card data determines which eligibility criteria you can meet, and only one questionnaire usually fits. The Council advises confirming this first with whoever the SAQ will be submitted to. If you are a service provider the question is already answered, because only one SAQ applies to you.

SAQ D for Service Providers, and only that one. The Council states plainly that it is the only SAQ for SAQ-eligible service providers and that all other SAQs are for merchant use only. A SaaS company reading a nine-way comparison of SAQ types is reading a merchant document. The genuine question for a service provider is whether an SAQ is accepted at all, or whether a Report on Compliance is required.

SAQ D is the questionnaire that covers the full PCI DSS requirement set. It exists in two versions, one for merchants who are not eligible for any shorter SAQ and one for service providers. It is the longest of the ten by a wide margin, because unlike the others it removes almost nothing from the standard.

In January 2025 the Council removed Requirements 6.4.3 and 11.6.1 for payment page security and Requirement 12.3.1, the targeted risk analysis supporting 11.6.1. In their place it added an eligibility criterion: the merchant has confirmed that their site is not susceptible to attacks from scripts that could affect the merchant e-commerce systems. The October 2024 SAQ A was retired on 31 March 2025 and the January 2025 version took effect the same day.

It is shorter and less specific, which is not the same as easier. Two testable requirements with defined controls were replaced by one attestation about susceptibility, and there is no single test that closes it. The consequence of getting it wrong also grew, because a merchant who cannot meet the criterion moves to SAQ A-EP or SAQ D, where the removed requirements apply again alongside everything else.

FAQ 1588, effective 1 April 2025, narrows it. The criterion is aimed at e-commerce merchants using an embedded payment form, and it does not apply to merchants who redirect the customer away from their site or fully outsource payment processing. Much published commentary states it more broadly than the Council does, so read the FAQ rather than the summaries.

The Council describes two routes. You implement protective techniques yourself, such as those in Requirements 6.4.3 and 11.6.1, or you obtain written assurance from your compliant payment processor that the embedded payment solution includes protection against script attacks when it is deployed correctly. The second route is a document to request now, not at attestation time.

Published counts disagree, and it is worth knowing why before you quote one. Some sources count requirements, some count sub-requirements and some count testing procedures, so figures for SAQ A range roughly from the high teens to the high twenties and SAQ A-EP from around 130 to around 190. Take the count from the current questionnaire itself rather than from a comparison article.

The SAQ is the questionnaire you answer. The AOC, or Attestation of Compliance, is the signed declaration that goes with it and is usually the document your customer actually asks for. A ROC, or Report on Compliance, is produced by a QSA or an internal security assessor rather than self-completed, and it is what larger merchants and many service providers are required to provide instead of an SAQ.

Not by definition. A self-assessment is self-completed, which is the point of it. In practice acquirers and enterprise customers often require a QSA signature or a full Report on Compliance depending on your validation level and transaction volume, and some SAQ requirements still need outside parties, notably the quarterly ASV scan and the penetration test.

Annually, with the attestation submitted to whoever requires it, usually your acquiring bank or an enterprise customer. Compliance itself is continuous rather than annual, so the requirements are in force between attestations and the yearly document is a report on a state you were meant to be holding all along.

You hold an attestation that does not describe your environment, which is the worst of both outcomes: the work was done and it does not validate anything. Acquirers reject it, customers reject it during vendor review, and in a breach investigation the mismatch between your attested scope and your actual scope is one of the first things examined.

PCI DSS v4.0.1. The v4.0.1 questionnaires were published on 15 October 2024, and the v4.0 SAQs remained active only until PCI DSS v4.0 was retired on 31 December 2024. The 51 future-dated v4.x requirements became mandatory on 31 March 2025, so any SAQ answered against pre-2025 guidance is now answering an old question set.

The evidence behind it can, and that is where the time goes. Control mapping, artifact collection, gap tracking and the reuse of the same evidence across SOC 2, ISO 27001 and HIPAA are all automatable. The eligibility determination, the scoping decision and the signature are judgment calls that stay with you and, where required, with a QSA.

Read every compliance and risk question

Keep reading

Guides that go deeper on this framework

Best PCI compliance software for service providers

What the platforms actually do for an SAQ D service provider, and where each one stops.

Read the guide

PCI DSS compliance checklist

The twelve requirements in plain terms, and what evidence each one expects.

Read the guide

Compliance automation software pricing

What these platforms charge, what the unit of billing is, and which costs are never in the quote.

Read the guide

Explore more

More ways to scrutinize compliance and risk with Scrutineer

SOC 2 compliance

Map controls to the Trust Services Criteria, collect evidence, and close gaps before audit.

Learn more

SOC 2 compliance software

A platform that maps SOC 2 controls, automates evidence, and tracks readiness continuously.

Learn more

ISO 27001 compliance

Map your ISMS to Annex A, automate evidence, and stay certification-ready.

Learn more

See every use case See pricing Back to Scrutineer

Stop guessing about readiness. Scrutinize on real evidence.

Point Scrutineer at a framework or a vendor and it maps every control, gathers evidence and scores the risk, returning an evidence-linked report and a prioritized gap list. The AI scrutinizes, you decide.

See pricing

SOC 2, ISO 27001, HIPAA, GDPR & PCI · evidence-linked controls · readiness, not certification