Surprise PCI compliance request? An Australian SAQ guide

First, don’t worry. Receiving a validation and reporting request from your payment provider is not a sign that something has gone wrong; it is a routine part of operating a business that accepts card payments. And the reporting that’s been requested is almost certainly not going to be expensive or time consuming.

Over the past 18 months, an increasingly consistent pattern has been forming: Online merchants who have been accepting card payments for years are being asked, for the first time, to provide a PCI DSS compliance report to their payment provider. The letter often arrives with little notice and a tight deadline, and it raises four questions in quick succession:

Which PCI DSS Self-Assessment Questionnaire (SAQ) applies to us?
Does a Qualified Security Assessor (QSA) need to sign the SAQ?
How long will the work take?
And, what is it going to cost?

This is not a panic-button article and the answers to those questions are generally straight-forward. PCI DSS validation is a routine part of accepting card payments, and once the structure is understood, the work is straightforward.

We wrote this for finance leads, IT managers, and business owners in Australia who accept card payments and want to understand what their annual PCI DSS validation actually involves, what their SAQ options are, and when QSA validation is required.

The article is useful whether dotSec ends up helping with your PCI reporting, or not. But of course, if you would like a scoping conversation, our details are at the end!

Where do these requirements come from?

Every business that accepts payment cards is bound by the rules of the card schemes whose cards it accepts: Visa, Mastercard, American Express, Discover, and JCB. The five card schemes jointly maintain the PCI Data Security Standard, administered by the PCI Security Standards Council (PCI SSC). PCI DSS is the technical and operational baseline; the individual card schemes then run their own compliance programs that tell merchants and service providers exactly how to validate adherence to the standard.

For most Australian merchants, the two programs that matter in practice are:

Mastercard’s Site Data Protection (SDP) Program, which sets merchant levels by Mastercard and Maestro transaction volume and the validation requirements for each level. The current rules are documented in the Mastercard SDP Program FAQs (June 2024) and the Mastercard Security Rules and Procedures (Merchant Edition, February 2025).
Visa’s Account Information Security (AIS) Program, Visa’s equivalent program, with broadly similar validation requirements. Visa has recently consolidated its merchant tiers from four levels to three, so where Mastercard still distinguishes Level 3 and Level 4 by e-commerce volume, Visa now treats those merchants as a single Level 3.

PCI DSS merchant levels at a glance

Merchant levels under both schemes are set by annual transaction volume. The Mastercard definitions are:

Level

Mastercard/Maestro transactions per year

Validation requirements

More than 6 million

Annual Report on Compliance (ROC) by a QSA, plus quarterly ASV scans

1 million to 6 million

Annual SAQ; QSA or ISA must additionally be engaged when completing SAQ A, A-EP, or D

More than 20,000 e-commerce, fewer than 1 million

Annual SAQ

All others (fewer than 20,000 e-commerce, or up to 1 million face-to-face)

Compliance required; validation not mandated by Mastercard, but may be required by the payment provider

A merchant’s level is determined by transaction volume, counted separately against each card scheme. The schemes do not aggregate volumes across brands when assigning levels. Although it is usually the payment provider (typically the acquirer) that communicates the level and the validation requirements, the level definitions themselves come from each card scheme and are applied against that scheme’s transactions only.

For example, a business doing 4 million total card transactions split 80% Visa and 20% Mastercard is doing 800,000 Mastercard transactions per year, which puts it at Mastercard Level 3 even though its total volume sits in the Level 2 band. Its Visa level is assessed separately, against its 3.2 million Visa transactions.

Why are more Australian merchants hearing about this now?

Three things have converged over the past 12 to 18 months that explain why PCI DSS validation has moved up the agenda for many Australian merchants.

PCI DSS v4.0.1 is now the only active version of the standard. PCI DSS v4.0 was retired on 31 December 2024. The 51 requirements that were previously flagged as future-dated best practices became mandatory on 31 March 2025. Payment providers are updating their compliance programs to reflect the current standard, which in many cases means tightening their reporting expectations for merchants.
The Mastercard Level 2 QSA-validation requirement is being applied more consistently. Mastercard’s requirement for Level 2 merchants completing SAQ A, SAQ A-EP, or SAQ D to engage a QSA or ISA has been in force for some years. In dotSec’s experience, enforcement across Australian payment providers has been uneven historically. That appears to be changing: more providers are now actively requesting QSA-validated SAQs from merchants in this band.
Australian e-commerce has grown substantially. Online retail in Australia has grown materially since 2020, and more merchants are now transacting at volumes that place them in a higher merchant-level band than when they first signed their merchant agreements. Higher levels carry higher validation obligations.

None of these are cause for alarm. They are the normal evolution of a compliance framework that has been in place since 2004. They do, however, explain why a validation request that has been technically required for some time might feels new and surprising now.

Fine, but why did I receive that reporting request?

Card scheme rules apply to the merchant via the merchant’s contract with whoever processes their card payments. In this article we use “payment provider” to mean the organisation your business has a merchant agreement with, whether that is an acquiring bank such as NAB, a licensed acquirer such as Tyro, or a payment facilitator such as Stripe. In PCI DSS documentation these organisations are referred to as “acquirers”, but for this article we will just use the term “payment provider”.

Each payment provider publishes its own guidance on what merchants need to do. A few Australian examples:

NAB, as an acquiring bank, publishes a PCI DSS guide for its merchants that summarises the card scheme rules and explains the validation process.
Tyro Payments, an Australian-based EFTPOS provider, publishes its own PCI DSS requirements page setting out what its merchants need to do, with a table mapping merchant levels to validation activities. Tyro’s page notes that its requirements are based on the programs communicated by Mastercard and Visa.
Eway, an Australian payment gateway, publishes a detailed PCI DSS page walking through the SAQ types that apply depending on the API integration the merchant uses.
Stripe provides a PCI Dashboard in the merchant account that helps the merchant identify the correct SAQ for their integration. Stripe’s PCI compliance guide sets out the merchant-level definitions and notes the Mastercard Level 2 QSA requirement explicitly.

The point of mentioning these is not to single out any one provider; totally the opposite in fact, it’s to show that the pattern is consistent. Whether the merchant is processing card payments with a bank or a non-bank provider, the validation obligation is set out in the merchant agreement, and the payment provider documents what is expected.

The detail is easy to miss at onboarding, when there is a lot of other material to absorb at the same time, which is one reason an annual validation reminder can feel new or unexpected.

What "QSA-validated" actually means

A Qualified Security Assessor (QSA) Company is an organisation that has been assessed and approved by the PCI Security Standards Council to perform PCI DSS validation work. The current list of approved QSA Companies is maintained on the PCI SSC public listing. dotSec is a QSA Company on that list, and we provide PCI DSS compliance services to Australian organisations as ROC, SAQ, and gap engagements.

We are also a PCI DSS-compliant service provider ourselves, which means we understand the compliance process from both sides: as a QSA company that validates others, and as a service provider that maintains our own compliance.

QSA validation can come into a merchant’s annual PCI process in a few ways:

Level 1 merchants must have their annual Report on Compliance signed by a QSA (or an Internal Security Assessor, where the merchant has trained internal staff to that standard).
Level 2 merchants under Mastercard who are completing SAQ A, SAQ A-EP, or SAQ D must engage a QSA or ISA for compliance validation, even though they are using an SAQ rather than a full ROC. This is set out in the Mastercard SDP FAQs.
Payment providers can require a merchant to provide QSA validation at their discretion, and across any transaction level.
Service providers at Level 1 (more than 300,000 transactions per year) must validate with a QSA-led Report on Compliance.

For all other cases the merchant can report using the appropriate Self-Assessment Questionnaire (SAQ), and the SAQ can be signed by the merchant rather than by a QSA. (Note that the merchant is still attesting to compliance via the Attestation of Compliance; “self-assessment” refers to the questionnaire itself rather than the attestation.) There is nothing wrong with self-attestation when it applies; the work is just done in-house rather than externally. And there is nothing wrong with engaging a QSA company to provide validation services as a risk-management activity; for a SAQ, such work is quick and inexpensive.

PCI compliance and reporting FAQ

What is the difference between SAQ A and SAQ A-EP for e-commerce merchants?

SAQ A is for e-commerce merchants who have fully outsourced cardholder data handling to a PCI DSS-compliant third party. The merchant’s own systems do not store, process, or transmit cardholder data, and the merchant’s web pages either redirect to the third party or embed the third party’s payment form. SAQ A-EP applies where the merchant’s website has some control over the security of the payment page, for example where the merchant’s server delivers a page that includes third-party JavaScript for payment processing. SAQ A is leaner; SAQ A-EP includes additional controls around system hardening, vulnerability management, and ASV scanning. The right choice depends on the specifics of the payment implementation, and the eligibility criteria are stricter under PCI DSS v4.0.1 than under earlier versions.

When does PCI DSS validation and reporting require a QSA company rather than self-attestation?

QSA involvement is required in four main cases. Level 1 merchants need a QSA-signed Report on Compliance (or an ISA). Level 2 merchants under the Mastercard SDP Program who are completing SAQ A, SAQ A-EP, or SAQ D must engage a QSA or ISA. Level 1 service providers (more than 300,000 transactions per year) need a QSA-led ROC. And the merchant’s payment provider can require QSA validation at any level at its discretion, particularly after a security incident or as part of its own risk management. Outside these cases the merchant can self-attest using the appropriate SAQ.

What happens if our PCI DSS validation isn't completed on time?

Consequences vary depending on the merchant agreement and the card scheme rules. The most common direct consequences are non-compliance fees applied by the payment provider, increased transaction fees, and additional reporting obligations. In serious or sustained non-compliance cases, the payment provider can terminate the merchant agreement, which means the merchant loses the ability to accept card payments through that payment provider. There are also indirect consequences: in the event of a data breach involving cardholder data, a merchant who was not compliant at the time of the breach faces materially higher exposure to card scheme fines and remediation costs.

How long does a QSA-validated SAQ typically take?

For a well-scoped SAQ A or SAQ A-EP engagement with a merchant whose controls are reasonably mature, the validation work typically takes about a week of effort spread over two to four weeks of calendar time. Where remediation is needed before the SAQ can be completed, the timeline extends accordingly. We can estimate timing more precisely after an initial scoping conversation.

Can we reduce our PCI compliance scope before validation and reporting?

In many cases, yes. Scope-reduction options include moving from a direct payment integration to a hosted or iframe payment page (which can move a merchant from SAQ A-EP to SAQ A), implementing point-to-point encryption (P2PE) for card-present transactions, and segmenting the cardholder data environment from the rest of the network so that fewer systems are in scope.

A related option, particularly for SAQ A-EP and SAQ D merchants, is to shift responsibility for individual control areas to a PCI DSS-compliant service provider. Controls that a compliant third party performs on your behalf are inherited via the shared responsibility matrix in your AOC, which materially reduces what the merchant has to evidence directly. This does not change the SAQ type, and it is not generally useful for SAQ A merchants because the affected control areas are not carried under SAQ A in the first place.

The right option depends on the merchant’s existing payment architecture and operational constraints. Scope reduction is one of the first things we look at in a scoping engagement, because the savings compound year on year.

What does the PCI DSS SAQ reporting process look like?

Whether the engagement is QSA-led or self-driven and attested, the structure of the validation and reporting is similar as far as the merchant is concerned:

Scope confirmation. Identify every system, process, person, and third party involved in storing, processing, or transmitting cardholder data. Confirm what is in scope and what can be excluded. This is the single most important step in any PCI engagement because scope drives everything else: which SAQ applies, how many controls need to be evidenced (some may be out of scope, which is good because it means less work), how long the work will take, and what the effort will cost.
SAQ selection. PCI DSS v4.0.1 defines eight SAQ types for merchants, each designed for a specific payment environment. SAQ A is the leanest and applies to e-commerce merchants who have fully outsourced cardholder data handling to a PCI DSS-compliant third party, and whose own site delivers no script that executes in the payment-page context. SAQ A-EP applies to e-commerce merchants who partially outsource but whose website still has some control over the security of the payment page, for example by delivering scripts to the payment page from the merchant’s own server. The eligibility boundary between SAQ A and SAQ A-EP tightened with PCI DSS v4.0.1, so merchants who comfortably sat on SAQ A under v3.2.1 should re-check their eligibility before assuming SAQ A still applies. SAQ D applies where no other SAQ fits. Selecting the right SAQ is consequential: the wrong one creates either a false sense of compliance or unnecessary work, and either outcome is likely to result in extra cost.
Gap analysis. Compare the merchant’s current state against the controls in the chosen SAQ. Identify what is already in place, what is partially in place, and what is missing. Produce a gap report with prioritised remediation actions.
Remediation. Close the gaps. For most Australian mid-market merchants, this is a mix of policy and procedure documentation, technical configuration changes, and evidence-gathering for controls that are already operationally in place but undocumented.
Evidence collection and SAQ completion. Work through each control in the SAQ, gather the evidence, and complete the questionnaire.
Attestation of Compliance (AOC). A document signed by the merchant (and, where required, by the QSA) confirming that the validation has been completed and the merchant is compliant. The AOC is what the payment provider actually wants to see.

The goal for most mid-tier merchants is to report under something simple and easy to complete. SAQ A or SAQ A-EP are desirable since both have fewer applicable controls than (for example) SAQ D, and so both take less time and cost less. For a well-scoped SAQ A or SAQ A-EP engagement, with a merchant whose controls are reasonably mature, the validation and reporting work typically takes about a week of effort spread over two to four weeks of calendar time.

A QSA-led validation under the Mastercard Level 2 requirement adds the QSA review and AOC sign-off but does not fundamentally change the steps; it adds a layer of independent evidence review and formal attestation, but little extra cost.

(Aside: A full QSA-led Report on Compliance for a Level 1 merchant or Level 1 service provider is a different shape of engagement: longer, more evidence-intensive, and not something that can be reliably scoped without a conversation about the merchant’s environment.)

So what should you do now?

First, don’t worry. Receiving a validation and reporting request from your payment provider is not a sign that something has gone wrong; it is a routine part of operating a business that accepts card payments. The requirements have been in place since you signed your merchant agreement and are simply coming to light now, for the reasons outlined above. And the reporting is almost certainly not going to be expensive or time consuming.

If you have read this far, you now understand the structure: where the requirements come from, why they are in front of you now, and what the validation and reporting process involves.

For most mid-market Australian merchants, annual PCI DSS validation is a bounded, well-defined piece of work. If your payment architecture is well-scoped and you are reporting under something like SAQ A or SAQ A-EP, the effort is typically about a week, spread over two to four weeks of calendar time. It is not a multi-month project and it should not dominate your quarter.

The first year takes a bit more effort because you are building the evidence base from scratch: documenting policies, confirming technical configurations, and gathering evidence for controls that are probably already in place but have not been formally recorded. After that, subsequent years are lighter. The controls, policies, and documentation are already there and just need reviewing and updating. The annual cycle gets easier, not harder.

You've read this far! How can dotSec help?

dotSec is an Australian QSA Company. We have been working with Australian organisations on PCI DSS compliance for 25+ years. Our work covers full QSA-led ROCs for Level 1 merchants and service providers, QSA-validated SAQs for Level 2 merchants under the Mastercard SDP requirement, gap assessments and remediation advisory leading into self-attested SAQs, and scoping engagements for merchants who want to reduce their compliance footprint before they validate.

Our pricing approach is fixed-price where the scope can be defined up front, and capped time-and-materials where it cannot. We do not bill open-ended consulting on PCI work; the merchant should know what the engagement will cost before it starts.

The two things we look for at the start of every engagement are scope-reduction opportunities and the right SAQ. Both have a substantial effect on how much work the validation involves and how much it costs. A merchant who can move from SAQ A-EP to SAQ A by changing how their payment page is implemented requires materially less evidence each and every year going forward. A merchant who has selected SAQ D when SAQ A-EP would have applied is doing more work, and spending more money, than they need to.

What next?

If your annual PCI DSS validation is coming up and you would like a 30-minute scoping conversation, contact dotSec. We can talk through your payment environment, identify which SAQ applies, and give you a clear view of what the validation work involves before you start.

dotSec is also a PCI DSS-compliant managed SIEM provider, so we can act as a compliant service provider for clients who want to shift parts of their compliance burden as well as having us validate the result.

For the full menu of our PCI work (ROC, SAQ, gap, and scope-reduction engagements), see our PCI DSS compliance services page.