Who Owns What in PCI Compliance: A Responsibility Matrix Guide

PCI compliance becomes more complex when several providers share responsibility for the same environment. A hosting platform may secure the underlying infrastructure, a payment provider may handle card data, and your own team may still control the application, users, integrations, and deployment decisions.

That creates a documentation problem during assessment—every applicable PCI DSS requirement needs a clearly assigned owner, including controls that are split between your organization and a third-party service provider.

This guide explains how to map those responsibilities under PCI DSS 4.0.1, what Requirements 12.8.5 and 12.9.2 require, how to interpret shared controls, and what a managed hosting provider can and cannot take off your plate.

What is a PCI responsibility matrix?

A PCI responsibility matrix is a mapping document that shows which applicable PCI DSS requirements are handled by your organization, which are handled by each third-party service provider (TPSP), and which are shared between both.

The purpose is to prevent ownership gaps. If a hosting provider manages the infrastructure but your team manages the application running on it, the matrix makes that boundary explicit instead of leaving both sides to assume the other is covering a control.

Most matrices work at the requirement or sub-requirement level and use three responsibility categories:

• Customer-owned: Your organization implements the control and provides the evidence that it is operating effectively.
• Provider-owned: The TPSP implements the relevant control for the service covered by its PCI DSS assessment.
• Shared: Both parties have defined responsibilities for different parts of the same control.

“Shared” should never be treated as shorthand for “both.” A useful matrix explains exactly what each party is responsible for. For example, a hosting provider may patch the infrastructure it operates while the customer remains responsible for vulnerabilities in custom application code.

What do PCI DSS Requirements 12.8.5 and 12.9.2 require?

PCI DSS Requirements 12.8.5 and 12.9.2 create corresponding obligations for organizations that use third-party service providers and for the providers themselves:

• Requirement 12.8.5 applies to the organization being assessed: It requires the organization to maintain information showing which PCI DSS requirements are managed by each third-party service provider, which are managed internally, and which are shared between the two. In practice, this is the requirement that makes clear responsibility allocation necessary.
• Requirement 12.9.2 applies to service providers: When a customer asks, the provider must supply information about the PCI DSS compliance status of the services it performs and identify which requirements are the provider’s responsibility, which belong to the customer, and which are shared.

Requirement 12.9.2 supports both sides of the customer’s TPSP oversight: the provider supplies compliance-status information needed for Requirement 12.8.4 and responsibility information needed for Requirement 12.8.5.

These requirements sit within a broader third-party management process. Under Requirement 12.8, organizations must also:

• Maintain a list of TPSPs they use.
• Maintain written agreements that acknowledge applicable account-data security responsibilities.
• Perform appropriate due diligence before engaging a TPSP.
• Monitor each provider’s PCI DSS compliance status at least once every 12 months.
• Maintain the responsibility allocation required by 12.8.5.

Neither side should rely on assumptions about who covers a control. The customer needs documented responsibility information for every relevant provider, and the provider must be able to supply the information customers need to support their own PCI DSS assessment.

What should you put in a PCI responsibility matrix?

A useful PCI responsibility matrix should identify each applicable PCI DSS requirement, the party responsible for it, and the evidence that proves the responsibility is being met.

At minimum, include:

• PCI DSS requirement or sub-requirement: Map responsibilities at a detailed enough level to avoid assigning an entire requirement to one party when ownership actually varies within it.
• In-scope service or system: Identify the hosting platform, payment provider, CDN, security service, or other TPSP the row applies to.
• Customer responsibility: Describe exactly what your organization must implement, manage, or monitor.
• Provider responsibility: Record what the TPSP performs as part of the service covered by its PCI DSS compliance.
• Shared responsibility: Break down which portion belongs to each party rather than marking the row simply as “shared.”
• Evidence: Note what each side can provide, such as an Attestation of Compliance (explained below), configuration records, logs, policies, or testing results.
• Review information: Record when the allocation was last checked and which provider documentation supports it.

The most important part is specificity. A row that says “Requirement 6: shared” still leaves room for confusion. A stronger entry might state that the provider patches its managed infrastructure while the customer patches custom code and application dependencies.

The matrix should give an assessor enough detail to understand where each responsibility begins and ends without having to infer the split.

Which PCI controls are most commonly split between a host and customer?

Vulnerability scanning, audit-log retention, and security patching are three PCI DSS controls that commonly span both hosting infrastructure and customer-controlled applications:

• External vulnerability scanning: Requirement 11.3.2: Applicable external systems must receive passing vulnerability scans from a PCI SSC Approved Scanning Vendor at least once every three months. A provider may scan infrastructure within its own scope, while the customer remains responsible for externally accessible systems that fall within the customer’s assessment scope.
• Audit-log retention: Requirement 10.5.1: Applicable audit logs must be retained for at least 12 months, with the most recent three months immediately available for analysis. A host may retain logs for platform components it manages, while the customer may need to capture and retain application-level logs for systems it controls.
• Security patching: Requirement 6.3.3: Patches for critical vulnerabilities must be installed within one month of release. Other applicable patches must be installed within a defined time period per the organization's patch management policy. A managed host may patch its infrastructure and platform software while the customer remains responsible for custom code, plugins, modules, and other software it controls.

For each control, the PCI responsibility matrix should identify the exact layer each party manages and the evidence each side will provide.

What does an Attestation of Compliance (AoC) prove?

An Attestation of Compliance (AoC) is a standardized PCI SSC document that records the outcome and scope of a PCI DSS assessment. For a service provider, it helps customers verify that the provider has completed an applicable PCI DSS assessment for the services described in the attestation.

Review an AoC alongside the provider’s responsibility information. Check:

• Which legal entity was assessed.
• Which services and locations are included in scope.
• Which PCI DSS version and assessment method were used.
• When the assessment was completed—confirm the evidence is current enough for your assessment and annual TPSP monitoring process.
• Whether the service you actually use is covered.
• Whether any relevant responsibilities still fall to your organization.

An AoC does not automatically establish that every product a provider sells is covered or that the provider owns every PCI DSS control related to your use of the service.

PCI SSC also expects TPSPs to provide customers with information about their PCI DSS compliance status and the requirements for which the provider, customer, or both, are responsible. A responsibility matrix is one way to communicate that allocation.

For vendor and procurement reviews, assess the AoC and responsibility information together because they answer different questions: the AoC establishes the provider’s assessed compliance status and scope, while the responsibility information shows which applicable controls your organization can rely on that provider to perform.

How do you map managed hosting responsibilities into a PCI responsibility matrix?

For managed hosting, build the responsibility matrix from the provider’s documented scope rather than assigning entire PCI DSS requirements based on assumptions about what a host normally handles.

Start with the provider’s current compliance documentation and identify the specific services covered. Then work through the applicable PCI DSS requirements and record three things: what the provider performs, what your organization still performs, and what evidence supports each allocation.

A few representative rows might look like this:

The key is to avoid treating a provider-owned technology layer as proof that an entire PCI DSS requirement has transferred to the provider. Requirement 6.3.3 is a good example. PCI SSC requires applicable security patches and updates to be installed according to defined time frames, including critical vulnerability patches within one month of release. A managed host may perform that work for its platform while your team remains responsible for software it controls.

Pantheon provides a concrete example of this model. 

Pantheon states that it secures the underlying platform while customers are responsible for PCI validation of their individual applications, including required quarterly Approved Scanning Vendor (ASV) scans of their site URLs. Your matrix should translate that documented boundary into the applicable requirement-level responsibilities for your particular architecture.

What happens during a PCI assessment when the responsibility matrix is missing?

A missing or incomplete PCI responsibility matrix can prevent an organization from clearly demonstrating which PCI DSS controls it relies on third-party service providers to perform. During an assessment, those responsibilities still have to be supported with evidence.

The matrix itself does not determine PCI scope. Scope is based on the people, processes, technologies, and services that store, process or transmit account data, or could affect the security of the cardholder data environment. The assessment problem arises when a control within that scope has been assigned to a provider, but the organization cannot demonstrate that allocation.

For example, if a hosting provider is expected to perform a particular infrastructure control, the assessor needs evidence showing that the relevant service is covered and that the provider performs that control. An undocumented assumption that “the host handles it” is not enough.

This can lead to several practical issues:

• Additional evidence requests from the assessor.
• Uncertainty over whether a provider-owned control can be treated as in place.
• Shared controls being reassessed because neither party’s portion is clearly defined.
• Compliance gaps surfacing late in the assessment process.

The fix is to reconcile the responsibility matrix against each provider’s current compliance documentation before the assessment, then resolve any rows where ownership, service scope, or supporting evidence is unclear.

How often should you update a PCI responsibility matrix?

Review your PCI responsibility matrix at least as part of your annual third-party service provider review and update it whenever the relationship, service, or responsibility split changes.

PCI DSS Requirement 12.8.4 requires organizations to monitor each TPSP’s PCI DSS compliance status at least once every 12 months, while Requirement 12.8.5 requires responsibility information to be maintained for each provider. PCI DSS does not prescribe a separate annual refresh cycle specifically for a document called a responsibility matrix.

So, revisit the matrix when:

• You add, replace, or remove a TPSP.
• A provider changes the services your organization uses.
• Your payment flow or application architecture changes.
• Systems move into or out of PCI DSS scope.
• Responsibility for a control shifts between your team and a provider.
• A provider issues new compliance documentation with a different scope.
• Changes to PCI DSS affect how an applicable control is assigned.

The annual TPSP review is also a useful checkpoint for confirming that current compliance evidence still matches the services and responsibilities recorded in the matrix. Treating the matrix as living documentation keeps it aligned with the environment your assessment actually covers.

How does the PCI responsibility model work on Pantheon?

Pantheon is a PCI DSS 4.0.1 - Level 2 Service Provider that follows a shared responsibility model for PCI compliance—Pantheon secures the underlying platform, while customers remain responsible for validating the PCI compliance of the applications they deploy on it.

For a PCI responsibility matrix, that means Pantheon can provide part of the control environment rather than replacing the customer’s own PCI program. Relevant platform capabilities include:

• Container-based infrastructure and resource isolation to separate site workloads.
• Managed HTTPS with support for TLS 1.2 and 1.3.
• Role-based access controls for governing who can access and deploy to sites.
• Managed infrastructure security and monitoring.
• Governed deployment workflows that enforce code promotion through Dev, Test, and Live, with Git mode preventing direct edits to production.

Your organization still needs to document the controls that sit above that platform layer. These can include custom application code, WordPress plugins, or Drupal modules, application users, payment integrations, third-party services, and the way account data moves through the site.

Make every PCI responsibility explicit

A PCI responsibility matrix turns a shared compliance model into something your team can actually operate, review, and defend during an assessment. Every applicable control should have a clear owner, a defined boundary, and evidence that supports the allocation.

That matters even more when your environment spans hosting, payment services, CDNs, and other third parties, because gaps usually appear at the handoffs between providers.

Pantheon gives WordPress, Drupal, and Next.js teams a managed platform with built-in security controls, governed workflows, and a clearly documented shared responsibility model. That can make the infrastructure side of PCI easier to define while your team stays focused on the application and business controls it owns.

Start with Pantheon today and build on a platform designed to make responsibility clearer!