If you are a business that collects credit card payments, you must support your business model with a foundation of effective payment security. Achieving PCI DSS compliance is essential in achieving the desired level of security and governance to protect your customers’ information.
We now live in a world where increasing amounts of your confidential business information reside in the cloud, which presents its own challenges when it comes to achieving PCI DSS compliance. Here are some key PCI DSS considerations that Australian businesses can’t afford to lose sight of while they protect their clients’ data in the cloud.
The burden of maintaining payment card data security in the cloud doesn’t fall on just one party. In most deployments, it’s shared between the client organisation and their cloud service provider, or CSP, of choice.
PCI DSS requirements apply to the software and hardware architectures that you use to store and utilise a cardholder’s data. They also govern the validation of your CSP’s infrastructure and the way you use the environments and tools it provides. For maximum efficacy, your PCI DSS controls must reflect the specifics of the cloud implementations that you apply them to.
The service-level agreement, or SLA, between you and your CSP will outline the specifics of what you can do with their cloud services. Its particulars must also guide your PCI DSS decision-making process.
Your SLA-specified deployment model impacts how much agency you have over PCI DSS and other security controls. NIST’s definition of cloud computing (Special Publication 800-145) describes four deployment models:
Your SLA also defines how you receive the software that you license. In most cases, your agreement will draw from the following commonplace service types:
Each cloud model inherently dictates who can institute specific security controls. Your responsibilities and those of your CSP will evolve and change with your deployment. The PCI Security Standards Council’s Cloud Computing Guidelines advise that security responsibilities are acknowledged in writing in your contractual agreements, and suggest a responsibility matrix to make clear who manages each requirement.
For instance, if you operate a private cloud deployment in your own facility, then you’re going to be the only entity that can reliably provide for the security of that physical facility. If you decide to go the hybrid route by storing some data on your private cloud with the rest in a public cloud infrastructure, like Amazon Web Services or Google Cloud, you’ll have to leave hardware access controls and other physical security measures up to these vendors. Depending on the third-party service that you use, your CSP may also have to assume responsibility for maintaining a secure OS on the servers that host your applications.
Functional business systems incorporate many discrete layers. Cloud deployments commonly rely on third-party tools and software APIs in addition to distinct networking, storage and processing hardware. No matter what kinds of service options your CSP offers to help you stay compliant, your company’s future depends on your ability to implement exhaustive governance policies.
The Australian Signals Directorate’s cloud shared responsibility guidance makes the same point for Australian organisations: as the customer, you always keep some security responsibilities, and you can’t outsource the risk to your data to a CSP.
How can you create an effective, comprehensive PCI DSS governance strategy? Although your specific obligations will vary to match your SLA, service type and deployment model, you should also think about factors like:
The way you use card data will impact your responsibilities. If you only pass card data through to complete a transaction and never store it, for example, your obligations are narrower than if you keep it. Sensitive authentication data, such as the card verification code, must never be stored after authorisation, even if it is encrypted.
Providing extra features might massively expand your obligations. Suppose that you also let your consumers save payment data for subsequent purchases. The PCI Security Standards Council notes that the most effective way to reduce your cloud scope is not to store, process or transmit card data in the cloud at all, so if you do keep card data there, you’ll need to make stored card numbers unreadable, for example through tokenisation or strong cryptography, and secure every system that can reach them.
You’re not your CSP’s only client. Your providers must enforce separation between your data and other users’ information by employing some form of segmentation, such as isolated operating systems, servers or virtual machines. Under Appendix A1 of PCI DSS v4.0.1, multi-tenant service providers must keep each customer’s environment logically separated and confirm that separation with penetration testing at least once every six months.
Steps like configuring network security controls such as firewalls, continuously logging traffic, using multi-factor authentication and segmenting data stores as well as processing resources commonly fall within the scope of CSP obligations for the infrastructure they manage. Nonetheless, you can still benefit from having an awareness of the steps that your CSP takes and using the knowledge to guide your own controls.
Validation and PCI DSS compliance go hand-in-hand. Before signing an SLA with any CSP, you need to ensure that the provider can show current PCI DSS validation, such as an Attestation of Compliance (AOC) signed off by a Qualified Security Assessor, that covers the services and locations you plan to use. An AOC reflects a single point in time, so PCI DSS v4.0.1 also requires you to monitor the compliance status of your third-party service providers at least once every 12 months.
Effective governance is a massive undertaking. The subtleties of different service and deployment models make it ill-advised to take a CSP at its word. It’s also impractical to manually verify that your provider’s security techniques are vulnerability-free.
Every merchant deployment is unique. Regardless of whether you’re hosting everything in-house, using shopping cart software or just relying on a content management system to serve your product images more rapidly, it’s up to you to identify and eliminate security gaps.
If your business is looking to get PCI DSS compliant, StickmanCyber's PCI DSS compliance service deploys a 5-step methodology to help you build trust with your customers and secure your card transactions. Book a free consultation today.
Yes. PCI DSS doesn’t ban the cloud, but any cloud environment that stores, processes or transmits card data is in scope. The PCI Security Standards Council’s cloud guidelines say the most effective way to reduce that scope is to keep card data out of the cloud altogether, for example by using a validated point-to-point encryption (P2PE) solution or third-party tokenisation, or by performing all encryption and key management outside the cloud.
Ask the provider for its Attestation of Compliance (AOC) and check that it lists the specific services and locations you use, and when the assessment took place. An AOC reflects a single point in time, so confirm the provider’s status again at least once every 12 months. Visa also publishes a Global Registry of Service Providers that lists providers which have validated their compliance with Visa.
A responsibility matrix lists each applicable PCI DSS requirement and shows whether you, your service provider or both of you are responsible for it. PCI DSS v4.0.1 requires you to keep this information for every third-party service provider (Requirement 12.8.5), and service providers must give it to customers on request (Requirement 12.9.2). The PCI SSC cloud guidelines include a sample matrix.
Appendix A1 of PCI DSS v4.0.1 adds requirements for service providers that share resources between customers, such as shared hosting, cloud and SaaS platforms. They must logically separate customer environments, enable audit logging for each customer and support prompt forensic investigations. The requirement to penetration test that separation at least once every six months was new in v4.0 and has been mandatory since 31 March 2025.
It can reduce scope, but it doesn’t remove your responsibility. A third-party cloud tokenisation service can limit where clear-text card numbers exist in your environment. If you run tokenisation yourself, you remain responsible for protecting the card data it stores. PCI DSS v4.0.1 recognises index tokens as one way to make stored card numbers unreadable.