PCI DSS by industry
PCI DSS for SaaS, hosting and managed security providers: service provider scope, your AOC and the responsibility matrix
What changes when the entity is a SaaS platform, hosting or cloud provider, or managed security provider: why customers ask, what belongs in scope, where assessors sample, and how your AOC and responsibility matrix serve customers.
Key points
- A SaaS platform, hosting or cloud provider, or managed security provider that handles card data for customers, or can affect its security, is assessed as a PCI DSS service provider, not a merchant.
- Customers need two things from you: a current Attestation of Compliance naming the services they use, and a responsibility matrix showing which requirements you meet, which they meet and which are shared.
- Assessors sample the software lifecycle, the separation between tenants and the cardholder data environment, and your engineers' privileged access more heavily than in a typical merchant assessment.
- A platform that never touches card data can still be in scope through the payment page it serves.
Why SaaS, hosting and managed security providers are asked for PCI DSS
The request usually comes from a customer. A merchant, bank or payment facilitator running its checkout, billing or card operations on your platform must manage its service providers under Requirement 12, and its assessor will ask for your Attestation of Compliance (AOC) and a statement of who does what.
Without one, each customer's assessor must test your controls inside their own assessment, which many enterprise buyers refuse. Card brand programmes set service provider levels: a Report on Compliance (ROC) from a Qualified Security Assessor (QSA) at the top level, a self-assessment questionnaire below it where the brands permit. The general route is explained in PCI DSS validation step by step: ROC, SAQ and AOC.
What sits inside the scope for a software or hosting provider
For a SaaS platform, scope follows the payment flow: the application tier that receives or tokenises card data, the databases and key management behind it, the APIs customers call, and the pipeline that can change any of them. For a hosting or cloud provider, it is the infrastructure you operate: hypervisors, network controls, storage, backup and the management plane. For a managed security provider, it is the tooling and access your analysts use inside customers' cardholder data environments (CDEs).
Three scope mistakes recur: treating a hosted payment form or iframe as out of scope when the page that loads it can still be tampered with; leaving out the CI/CD pipeline, repositories and support tooling that can reach production; and describing a shared platform without showing how tenants are separated from each other and from the CDE. Drawing the boundary is covered in PCI DSS scoping and segmentation: shrinking the CDE.
Where the requirements bite for software and hosting providers
| Requirement area | What it means for a SaaS or hosting provider | Evidence the assessor samples |
|---|---|---|
| 12 Organisational policies and programmes: service provider responsibilities | Stating, service by service, which requirements you, your customers or both manage | The responsibility matrix, matching contract clauses, the AOC service list, reviews that staff follow procedures |
| 6 Secure systems and software | Code review, vulnerability management, controlled releases and the integrity of any payment page you serve | Secure coding training, code review and pipeline approvals, patch reports, a payment page script inventory with integrity checks |
| 1 and 11 Network security controls and testing | Separating tenants from each other and the CDE from the rest of the platform, and proving it holds | Data-flow and network diagrams, security group and firewall rules with justification, segmentation test reports, penetration test results with fixes |
| 7 and 8 Access and authentication | Engineers, support staff and analysts with administrative access to production and customer environments | Role-based access model, approved privileged access, multi-factor authentication on all non-console access into the CDE, six-monthly access reviews, leaver removal |
| 10 Logging and monitoring | Logs showing who touched which environment, reviewed with automated tools | Centralised logging, alert and review records, synchronised time, handling of failed critical controls |
All twelve are explained in PCI DSS requirements explained, requirement by requirement.
The AOC and responsibility matrix your customers ask for
The service provider AOC lists the services assessed and the services not assessed. Customers read that section first: a product outside it gives them no assurance. Keep service names identical to your contracts and validate every service a payment customer can use.
The AOC is intended to be shared with customers who request it; the ROC behind it normally stays with you. The responsibility matrix does the other half: it tells each customer which controls they evidence themselves, such as their own users, payment page content or console configuration. Write it per service and per requirement; customers' assessors test against it line by line. How customers check your documents is set out in How to verify a PCI DSS AOC and check a provider's compliance.
The operations manager writes that the team's attention to detail, collaborative approach and commitment to quality set a standard well beyond what the company expected.
Working alongside ISO/IEC 27001, SOC 2 and ISO/IEC 27017
ISO/IEC 27001 provides the management system the payment controls sit inside; a SOC 2 report answers customers who want an examination of the whole service; ISO/IEC 27017 and ISO/IEC 27018 add cloud security and cloud privacy controls. One responsibility matrix, change process and evidence calendar can serve them all; see PCI DSS vs ISO/IEC 27001 and SOC 2.
Duration depends on the services and environments in scope, how much of the platform card data can be kept off, and when the anchor customer needs the AOC. Engineering, operations, security and contract owners must be involved. With Design™, Sterling guides your teams to own the controls; with Drive™, Sterling carries more of the documentation, evidence and readiness testing.
How Sterling works with software and hosting providers
An AOC your customers and their assessors can rely on.
Our expert and experienced consultants trace card data through your platform, reduce the scope first, write the responsibility matrix with your product and legal teams, test lifecycle, segmentation and access controls the way the QSA will, and keep the evidence in Effivity, included with the engagement. Sterling does not validate compliance; the QSA assesses and attests. We ensure successful validation for our clients.
Book a free discovery callPCI DSS for SaaS and hosting providers: questions buyers ask
Does a SaaS platform need PCI DSS if a payment gateway handles the card data?
Often yes, with a smaller scope. If your platform serves the page that loads the gateway's form, or can otherwise affect the security of card data, those parts are in scope.
Is a hosting provider a PCI DSS service provider?
Yes, when it hosts systems that store, process or transmit card data for customers, or can affect their security. It is assessed on the infrastructure and services it operates; customers remain responsible for what they run on it.
What extra PCI DSS requirements apply to service providers?
Several. Service providers test segmentation every six months rather than yearly, review at least every three months that staff follow security procedures, and use SAQ D for Service Providers when self-assessment is allowed.
Can our customers rely on our AOC for their own PCI DSS assessment?
Yes, for the services and requirements it covers. They still evidence their own share of the responsibility matrix and check each year that your AOC is current.
PCI DSS by industry
Every guide in the PCI DSS series is written for one question and links back to the hub for the whole picture.
- PCI DSS for banking and financial services
- PCI DSS for BPO and contact centres
- PCI DSS for e-commerce and retail
- PCI DSS for fintech and payment facilitators
- PCI DSS for healthcare providers and insurers
- PCI DSS for hospitality and travel
- PCI DSS scoping and segmentation
- PCI DSS in Singapore and South East Asia
- PCI DSS for small merchants and start-ups
- PCI DSS for software and hosting providers
- The PCI DSS assessment
- PCI DSS in the Philippines
- PCI DSS in the UK
Keep exploring
Explore more about PCI DSS
Watch a video on how to implement PCI DSS here.
Watch a video on PCI DSS requirements here.
PCI DSS resources
Services for PCI DSS
Talk to a consultant
Plan a PCI DSS validation your customers and their assessors will accept.
Tell us your goals, locations and target date. We’ll help you define the scope, timeline and next steps.
hello@sterling-grc.com+1 201 263 4443 (global headquarters) · your nearest office and its number are at the top of this page
What would you like to achieve?
Choose a starting point. The enquiry form takes about a minute.
Book my free discovery callContinue to the enquiry form to share your details. Please do not include passwords, sensitive personal information or confidential files. A Sterling consultant replies within one working day. Privacy notice