Your service providers, the devil's in the compliance detail
This post is part two of 2-part advisory, for any Australian business that accepts card payments through a website, booking system, or app that was set up and is managed by a third party. If that’s you, read on, because when it comes to your service providers, the devil’s in the compliance details.
In our previous post, we explained why your website provider saying “we handle the payments” might be a warning that you’re accepting an unknown risk.
It’s one of the most common things we hear from businesses: “Our provider takes care of everything: the website, the bookings, the payments. They said PCI DSS isn’t something we need to think about.” But often times, that advice is wrong. Not a little bit wrong. Quite wrong.
What PCI DSS requires
In our previous post, we explained why your website provider saying “we handle the payments” might be a warning that you’re accepting an unknown risk.
PCI DSS applies to two kinds of organisations: merchants (businesses that accept card payments) and service providers (organisations that store, process, or transmit cardholder data on behalf of merchants, or that could affect the security of that data). If you accept card payments, whether online, in-store, by phone, via a kiosk, through an app, or via mail orders, you are a merchant.
PCI DSS does allow you to reduce your compliance scope by outsourcing payment functions to PCI DSS compliant third parties. If you do this properly, you may be eligible to report under SAQ A, the leanest of the self-assessment questionnaires, with fewer than 30 controls. We’ve written about SAQ A in detail and it is genuinely the best outcome for merchants who want to minimise their reporting load.
But SAQ A eligibility has strict conditions. Per the PCI SSC’s own eligibility criteria (PCI DSS v4.0.1 SAQ A r1, January 2025), to qualify for SAQ A, merchants must confirm that, for the payment channel in question:
- They accept only card-not-present (e-commerce or mail/telephone-order) transactions.
- All processing of account data is entirely outsourced to a PCI DSS compliant TPSP/payment processor.
- The merchant does not electronically store, process, or transmit any account data on merchant systems or premises, but relies entirely on a TPSP(s) to handle all these functions.
- The merchant has confirmed that TPSP(s) are PCI DSS compliant for the services being used by the merchant.
- Any account data the merchant might retain is on paper (for example, printed reports or receipts), and these documents are not received electronically.
Additionally, for e-commerce channels:
- All elements of the payment page(s)/form(s) delivered to the customer’s browser originate only and directly from a PCI DSS compliant TPSP/payment processor.
- The merchant has confirmed that their site is not susceptible to attacks from scripts that could affect the merchant’s e-commerce system(s).
Notice what those criteria demand: the merchant must confirm that their service providers are PCI DSS compliant. Not assume. Not take their word for it. Confirm, with evidence, ideally an Attestation of Compliance (AOC).
And if your website provider is handling card data through your online booking or payment system, their only SAQ option is SAQ D for Service Providers. That’s not us being dramatic; it’s stated in black and white in the PCI SSC documentation: “This SAQ is the ONLY SAQ option for service providers.” SAQ D covers all 12 PCI DSS requirements and runs to several hundred controls.
So here’s the question: can your website provider produce a current AOC? If the answer is no, you have a service provider compliance gap, and your own SAQ eligibility depends on their compliance status. If your TPSP isn’t compliant, you cannot report under SAQ A. As we noted in our SAQ A post: if your third-party service provider cannot or will not produce evidence of their PCI DSS compliance, you need to seriously question whether they should remain your provider for services that could affect the security of cardholder data.
Know your service providers and manage them
PCI DSS Requirement 12.8 sets out specific obligations for managing TPSPs. It requires merchants to:
- Maintain a list of all TPSPs with whom account data is shared or that could affect the security of account data, including a description of the services provided (Requirement 12.8.1).
- Have written agreements with each TPSP that include an acknowledgement from the TPSP that it is responsible for the security of account data it possesses or otherwise stores, processes, or transmits on your behalf (Requirement 12.8.2).
- Have an established process for engaging TPSPs, including proper due diligence prior to engagement (Requirement 12.8.3).
- Implement a program to monitor each TPSP’s PCI DSS compliance status at least once every 12 months (Requirement 12.8.4).
- Maintain information about which PCI DSS requirements are managed by each TPSP, which are managed by you, and any that are shared between you and the TPSP (Requirement 12.8.5).
This is not optional. It is a requirement, and your acquirer may ask for it.
If a service provider handles cardholder data on your behalf and cannot produce evidence of PCI DSS compliance, you have a material risk. You can work with them to get compliant (some providers genuinely don’t realise they’re in scope, which is a solvable problem). But if they refuse to engage, or if they insist that the payment gateway’s compliance covers them, you need to seriously evaluate whether they should remain your provider. Your compliance, your liability, and your customers’ card data are on the line.
Why this matters now for Australian businesses
PCI DSS compliance is enforced contractually, through your merchant agreement with your acquirer and through the card brand operating regulations that govern the entire payment chain. In the event of non-compliance, your acquirer can impose escalating penalties, increased transaction fees, stricter audit requirements, or terminate your merchant relationship altogether. For many businesses, losing the ability to accept card payments is an existential problem.
But the contractual penalties from card brands are only part of the picture. The Australian regulatory environment around data protection and cyber security has shifted significantly.
We’ve written previously about ASIC’s lawsuit against FIIG Securities for what ASIC described as systemic and prolonged cyber security failures. The Federal Court ordered FIIG to pay $2.5 million in civil penalties, the first time penalties have been imposed under general AFS licence obligations for a cyber failure. The OAIC’s actions following the Medibank breach (which affected approximately 9.7 million individuals) and the MediSecure incident (which may have impacted approximately 12.9 million individuals) reinforce the trajectory: when customer data is compromised and an organisation cannot show that it took reasonable steps to protect that data, the consequences are severe.
Now bring that back to PCI DSS and your website provider. If your provider suffers a breach and cardholder data is exposed, the card brands will look at your acquirer, your acquirer will look at you, and the first question will be: were you PCI DSS compliant at the time of the breach? The second will be: did you verify that your service providers were compliant? If the answer to either is no, you are exposed to fines, forensic investigation costs, card monitoring and reissuing costs, potential legal action, and the reputational damage that follows.
Your customers trust you with their card details. The PCI DSS exists to make sure that trust is justified. Don’t let a reassuring line from your website provider become the reason it isn’t.
dotSec and PCI DSS compliance in Australia
dotSec is a PCI DSS-compliant service provider with a current Attestation of Compliance (AOC). Our professionals hold certifications including QSA, ISO 27001 Lead Auditor, CISA, and CISM. We bring governance, risk, and technical security expertise to PCI DSS compliance engagements, which means our recommendations are grounded in real-world implementation experience.
We’ve worked with Australian businesses that came to us after discovering exactly the kind of service provider gap described in these posts. We helped them map their cardholder data flows, assess their providers’ compliance status, determine the right SAQ, and get their compliance program on solid footing before an acquirer or a breach forced the issue.
Don’t wait for your acquirer to come knocking. Your obligation to maintain PCI DSS compliance is defined in your merchant agreement, not in a reminder email.
Premier australian cyber security specialists
