Service and Scope Mapping
Define which products, platforms, environments and operational services are included in the PCI assessment.
Service providers sit inside other organisations' PCI compliance programmes. That means your own assessment has to do two jobs: validate your controls and give customers clear evidence about which PCI DSS requirements your service is meeting or affecting.
2-sec helps service providers define the service boundary, map customer and provider responsibilities, prepare assessment evidence and build a PCI validation package customers can actually use in their own compliance work.
A PCI DSS service provider may store, process or transmit account data on behalf of customers, manage systems within a customer's CDE, or provide services that can affect the security of customer account data. Those relationships create specific scope, evidence and responsibility questions.
PCI SSC expects TPSPs that meet PCI DSS requirements on behalf of customers to provide sufficient evidence showing that the relevant services and requirements were assessed. Customers, in turn, must understand shared responsibilities and monitor their TPSPs.
For service providers, the assessment boundary has to connect the technical service, the contractual service and the PCI evidence customers receive.
Define which products, platforms, environments and operational services are included in the PCI assessment.
Document which PCI DSS requirements are met by the provider, which remain with the customer and where responsibilities are shared.
Prepare the evidence and control environment for the validation route that applies to the service provider.
Map shared infrastructure, SaaS, PaaS, IaaS and administrative services that can affect customer CDEs.
Prepare current AOC, scope descriptions and supporting information customers need for third-party due diligence.
Assess how new services, platform changes and customer use cases affect PCI scope and previously documented responsibilities.
An AOC is important, but customers often need to understand what sits behind it.
Map the services, systems, locations and customer-facing functions included in PCI scope.
Separate provider, customer and shared PCI DSS obligations.
Review the service against applicable requirements and close readiness gaps.
Prepare for SAQ D for Service Providers or the required QSA-led assessment route.
Provide clear documentation showing assessed services and responsibility coverage.
Monitor compliance, service changes and evidence customers rely on throughout the year.
A service provider may store, process or transmit account data on behalf of another entity, manage systems in a customer's CDE, or provide services that can affect the security of account data.
PCI SSC says a TPSP is expected to provide evidence showing that the services relevant to the customer were in assessment scope and that applicable PCI DSS requirements were assessed and in place. A current AOC is commonly part of that evidence.
No. PCI SSC states that evidence limited to merchant SAQ requirements, such as SAQ A, is not sufficient evidence of PCI DSS compliance for a TPSP's merchant customers.
Yes. Customers retain responsibility for managing TPSP relationships, understanding shared requirements and monitoring provider compliance status.
They can, depending on the service. PCI SSC states that a vendor providing only a product may not be a TPSP, while ongoing operation, maintenance or access to the customer's CDE can make the relationship a TPSP service.