Australian organisations choose Stripe because it simplifies online payments and can reduce their direct PCI DSS
compliance obligations. That’s why, when working with Stripe customers, one of the most common
misconceptions we see is that because Stripe is PCI DSS compliant, using Stripe automatically makes
their customers compliant.
In reality, you remain responsible for protecting your customers’ payment data and meeting applicable PCI DSS requirements. Over the years, we’ve seen the same compliance issues arise repeatedly, particularly among organisations completing their first SAQ A.
Here are the seven most common mistakes we see, and how to avoid them.
1. Assuming Stripe makes you automatically PCI compliant
While Stripe can significantly reduce your PCI DSS scope, it doesn’t remove your compliance obligations. To qualify for SAQ A, merchants must ensure that all payment card data is handled entirely by Stripe-hosted payment pages or approved redirection mechanisms. Even if this is the case, your organisation will still need to complete an annual self-assessment and maintain security controls within your own environment.
What to do instead
- Confirm your payment flow meets SAQ A eligibility requirements.
- Review your website annually.
- Complete your SAQ every year.
- Maintain supporting evidence for compliance activities.
2. Using website plugins that break SAQ A eligibility
A seemingly harmless website update can change PCI obligations overnight. Many businesses start with a compliant Stripe implementation and later install:
- Shopping cart plugins
- Marketing widgets
- Custom checkout modifications
- Analytics scripts
Without realising it, these changes can bring payment pages back into PCI scope.
What to do instead
Before deploying any new updates, review:
- Payment page integrations
- New plugins
- Third-party scripts
- Website modifications
When in doubt, have your implementation reviewed by a PCI DSS specialist.
3. Forgetting about monthly vulnerability scanning requirements
A surprisingly common issue is: “We completed our SAQ but never performed an ASV scan.”
Many merchants are unaware that certain PCI DSS requirements include external vulnerability scanning obligations. We often see organisations only discovering the requirement applies to them when preparing for an annual compliance review.
What to do instead
To avoid these inconvenient surprises, maintain a compliance calendar that includes:
- Monthly vulnerability scans
- Remediation activities
- Annual SAQ completion
- Evidence collection
A calendar systemises the activities required to meet and maintain PCI DSS compliance.
Looking for a PCI DSS compliance calendar? We’ve made ours, the one our QSAs use themselves to manage our engagements, available for free. Contact us to request your copy.
4. Not maintaining evidence throughout the year
One of the most stressful periods for merchants is the weeks leading up to their annual SAQ submission. This is when PCI DSS becomes urgent, and organisations scramble to locate:
- Security policies
- Website reviews
- Scan reports
- Change management records
Often the evidence simply doesn’t exist.
What to do instead
Collecting evidence continuously throughout the year prevents this problem. The easiest way to do this is by implementing, and sticking to, a compliance tracker. A simple tracker can record:
- Monthly activities
- Quarterly reviews
- Annual assessments
- Security updates
Having this information on hand day-to-day means you can identify and resolve blockers before they become a serious problem at audit time, ultimately making your annual SAQ completion significantly easier.
5. Assuming third-party suppliers are managing everything
Your organisation relies on third parties such as web developers, managed service providers, hosting companies and marketing agencies to keep operations running smoothly.
That’s not a compliance headache on its own. It becomes one when you assume those suppliers are responsible for PCI compliance. We see this a lot. A vendor’s compliance is ticked off at onboarding, or worse, simply assumed, and then the consequences of a third-party breach fall on the organisation. PCI DSS accountability remains with the merchant.
What to do instead
Maintain documentation showing:
- Who manages your website
- Who has administrator access
- What security responsibilities belong to each provider (TPSP)
- Current contracts and agreements
Understanding your responsibilities is the only way to meaningfully avoid compliance gaps at your annual sign-off.
6. Not reviewing website changes
Websites constantly change. New pages, functionality, tracking tools, marketing codes and third-party integrations all increase PCI DSS scope. Even minor changes can affect compliance requirements.
What to do instead
Establish a simple review process that triggers whenever:
- Checkout functionality changes
- New plugins are installed
- Website redevelopment occurs
- Vendors make major modifications
That shouldn’t mean an arduous review every time you want to make a change. If you’re unsure what triggers a compliance review, consult with a QSA first. They’ll be able to tell you exactly what to monitor for, and where you can stay as agile as you are now.
7. Treating PCI compliance as a once-a-year activity
This is perhaps the most common mistake of all. Many merchants focus solely on:
- Completing the SAQ
- Obtaining an Attestation of Compliance
- Meeting a customer or bank deadline
Then they ignore PCI DSS until the following year. The result is usually:
- Missing evidence
- Failed scans
- Increased compliance effort
- Greater security risk
What to do instead
Adopt a year-round compliance cadence.
That means:
- Monthly vulnerability scanning
- Quarterly website review
- Annual security policy review
- Annual SAQ assessment
- Ongoing evidence collection
Maintaining compliance throughout the year is considerably easier than trying to recreate evidence later.
For Australian Stripe merchants, PCI DSS compliance doesn’t have to be complicated.
To achieve the best outcomes: make sure you understand your obligations, follow a structured compliance cadence, and review changes before they impact your PCI DSS scope.
By the time Stripe tells you you’re a Level 2 merchant, the decision’s been made for you. You’ll be signing an Attestation of Compliance either way. By then, you’ve lost control of what the AoC will say
If you’re unsure whether your Stripe implementation still qualifies for SAQ A, or if you’d like help developing a practical PCI compliance cadence, we can help. Stratica’s PCI Qualified Security Assessors can help you assess your current position and identify any gaps before they become compliance issues. Contact us to find out more or get started on the right track to continuous PCI DSS compliance.