PCI DSS Compliance and SSL: What Australian Online Businesses Must Know

This article provides general educational information about PCI DSS and SSL/TLS requirements. It is not legal or compliance advice. PCI DSS standards are updated regularly. For your specific compliance obligations, consult a qualified PCI QSA (Qualified Security Assessor) or your acquiring bank.

If your business accepts credit or debit card payments online — even through a payment gateway like Stripe or PayPal — you are subject to the Payment Card Industry Data Security Standard (PCI DSS). And PCI DSS has specific, non-negotiable requirements around SSL certificates and TLS configuration.

Non-compliance can result in fines, increased transaction fees, and — in a serious breach — loss of your ability to accept card payments altogether.

What Is PCI DSS?

PCI DSS is a set of security standards created by the major card networks (Visa, Mastercard, American Express, Discover, and JCB) through the PCI Security Standards Council. It applies to any organisation that stores, processes, or transmits cardholder data.

In Australia, PCI DSS is enforced by your acquiring bank (the bank that processes your card payments). Compliance requirements vary by transaction volume:

(Thresholds below are Visa/Mastercard definitions — American Express, Discover, and other networks define merchant levels differently. Confirm your level with your acquiring bank.)

Level 4 merchants (fewer than 20,000 Visa e-commerce transactions per year, fewer than 1 million total): Complete a Self-Assessment Questionnaire (SAQ) annually and submit quarterly vulnerability scans if required by your acquirer.

Level 3 merchants (20,000–1 million Visa e-commerce transactions): SAQ plus quarterly scans from an Approved Scanning Vendor (ASV).

Level 2 merchants (1–6 million transactions): SAQ or on-site assessment.

Level 1 merchants (over 6 million transactions): Annual on-site assessment by a Qualified Security Assessor (QSA).

Most small Australian e-commerce businesses are Level 4.

PCI DSS Requirements for SSL and TLS

Requirement 4.2: Protect cardholder data with strong cryptography

PCI DSS v4.0.1 (released June 2024 as a minor revision of v4.0) requires that cardholder data be protected with strong cryptography during transmission over open, public networks.

In practice this means:

• All pages in the cardholder data environment must be served over HTTPS
• This includes checkout pages, account pages, and any page where a customer enters or views card data
• The SSL/TLS certificate must be from a trusted Certificate Authority
• Self-signed certificates are not acceptable for production environments

Requirement 4.2.1: TLS version requirements

PCI DSS explicitly prohibits TLS 1.0 and TLS 1.1. These versions have known vulnerabilities (POODLE, BEAST) and have been prohibited since the PCI DSS 3.2 deadline of June 30, 2018.

Required: TLS 1.2 minimum. TLS 1.3 is recommended.

If your server still supports TLS 1.0 or 1.1 — even alongside TLS 1.2 — you are not PCI DSS compliant. This is one of the most common compliance failures found during security assessments.

How to check: Run your site through SSL Labs (ssllabs.com/ssltest). If TLS 1.0 or 1.1 is supported, the report will flag it and your overall grade will be reduced.

Certificate validity

There is no explicit PCI DSS requirement specifying certificate validity periods, but the standard's broader requirement to implement strong cryptography and maintain secure systems implies that expired certificates are a compliance failure.

An expired SSL certificate means:

• The HTTPS connection is rejected by browsers (visitors can't access the site at all)
• Any visitors who bypass the warning are connecting without verified encryption
• Your site is effectively down for PCI DSS-compliant users

For PCI DSS compliance, your certificate must be continuously valid. A lapse — even a brief one — is a control failure.

The SAQ A vs SAQ A-EP Distinction

This is important for Australian businesses using payment gateways.

SAQ A applies to merchants who have fully outsourced their card data processing. The customer enters card details on the payment provider's page (Stripe's hosted checkout, PayPal, etc.) — the merchant's website never touches card data.

If you use Stripe's hosted checkout (Checkout.stripe.com) or PayPal's standard checkout, you may qualify for SAQ A. This has significantly reduced SSL/TLS requirements — but you still need HTTPS on all pages of your site for the redirect to work properly.

SAQ A-EP applies to merchants whose website hosts the checkout page (even if data goes directly to the processor). This includes:

• Stripe Elements or Stripe.js embedded on your own checkout page
• WooCommerce with Stripe inline checkout
• Any custom checkout flow where the customer doesn't leave your site to pay

SAQ A-EP has full SSL/TLS requirements, including the TLS 1.0/1.1 prohibition and a requirement that your website be scanned by an Approved Scanning Vendor (ASV) quarterly.

If you're unsure which SAQ applies to your business, ask your acquiring bank or a PCI QSA.

Common SSL-Related PCI DSS Failures

The following are common SSL-related compliance gaps identified in PCI DSS assessments:

1. TLS 1.0 or 1.1 still enabled Many Australian shared hosting providers still enable TLS 1.0/1.1 by default for compatibility with older browsers. You may need to explicitly disable them.

2. Mixed content on checkout pages An image or script loading over HTTP on a checkout page is a compliance issue. Use your browser's developer tools to check every page in your checkout flow.

3. Expired certificate Even a brief expiry is a documented control failure. If your certificate expires during a compliance assessment period, you'll be required to explain the gap.

4. Self-signed certificate on staging A staging or test environment that's accessible from the internet with a self-signed certificate is technically out of scope only if completely isolated. Many businesses have staging environments that are more accessible than they realise.

5. Outdated cipher suites Your server may support TLS 1.2 but with weak cipher suites (RC4, 3DES, export-grade). These are prohibited. SSL Labs gives you a detailed breakdown.

Certificate Management as a Control

From a compliance perspective, SSL certificate management should be treated as a formal control with:

• Documented ownership (who is responsible for renewal)
• A defined process (how renewal happens, who verifies it)
• Monitoring and alerting (automated detection of upcoming expiry)
• Evidence of operation (logs showing the certificate has been valid continuously)

For Level 4 merchants completing an SAQ, having documented SSL monitoring — with alert logs — is evidence that you've implemented this control. CertGuard provides exportable logs of certificate status checks.

Practical Steps for Australian E-Commerce Businesses

1. Run SSL Labs on your site — identify any TLS 1.0/1.1 or weak cipher issues
2. Determine your SAQ type — SAQ A or SAQ A-EP changes your obligations significantly
3. Disable TLS 1.0 and 1.1 on your server or ask your hosting provider to do so
4. Fix any mixed content on checkout pages
5. Set up automated SSL certificate monitoring — a documented control, not just a precaution
6. Document your SSL renewal process — who is responsible, how they're notified, what the procedure is

CertGuard provides the monitoring and audit trail you need for this control. Plans start free for up to 3 domains.