How to Build a Third-Party Vendor Responsibility Matrix

Every organization that works with outside vendors can eventually run into the same problem: something goes wrong, and nobody is quite sure whose job it was to catch it. A patch does not get applied. A backup fails silently. A compliance report goes out late. When you ask “who owns this?” you get pointing fingers instead of a clear answer.

A responsibility matrix solves that problem before it starts. It is a straightforward document that maps exactly which tasks, controls, and decisions belong to your organization versus your third-party service providers (TPSP). Done well, a responsibility matrix becomes the reference point everyone turns to during onboarding, assessments, incident response, and contract renewals.

This article walks through how to build one, what to watch for, and how to keep it useful.

What Is a Responsibility Matrix?

A responsibility matrix is a document that maps tasks, processes, controls, and decisions to the individuals or organizations responsible for completing or overseeing them. It provides a clear view of who owns each responsibility and helps prevent tasks from being overlooked or duplicated.

One of the most common approaches is a RACI responsibility matrix, which assigns four roles:

• Responsible: The person or team who performs the work.
• Accountable: The person who owns the outcome and has final authority.
• Consulted: Those who provide input before a decision or action.
• Informed: Those who need to be notified of the outcome.

For third-party relationships, a responsibility matrix can be used to define responsibilities between your organization and a vendor across areas such as cybersecurity, compliance, data protection, incident response, backups, and access management.

What Is a RACI Responsibility Matrix?

A RACI responsibility matrix provides a clear framework for documenting ownership between your organization and its third-party vendors. Rather than simply listing responsibilities, it shows who owns each task, decision, or control and where responsibilities may overlap.

For vendor relationships, a RACI matrix can help clarify areas such as patching, access management, data protection, incident response, backups, and compliance reporting. By documenting these responsibilities in one place, both parties have a shared understanding of who is expected to take action and who needs to be involved.

This makes the RACI matrix a practical tool for reducing gaps, resolving ambiguity, and strengthening accountability throughout the vendor relationship.

Why a Responsibility Matrix Matters, and Where It Comes From

For any organization subject to the Payment Card Industry Data Security Standard (PCI DSS), a responsibility matrix is not just good hygiene. It is a requirement.

PCI DSS Requirement 12.8.5 requires entities to maintain information identifying which PCI DSS requirements are managed by the service provider, which are managed by the customer, and which are shared between both parties.

Its companion, Requirement 12.9, obligates service providers to support their customers’ compliance efforts and to acknowledge responsibility for the security of any account data they store, process, transmit, or could affect.

Together, these two requirements are the basis for what most organizations call a PCI Responsibility Matrix, a Shared Responsibility Matrix, or a Customer Responsibility Matrix. The same discipline applies well beyond payments.

Any relationship in which a vendor handles sensitive data or operates a control on your behalf benefits from the same clarity, whether the driver is PCI DSS, the GLBA Safeguards Rule, or a NIST-based program.

The Model for the Matrix

The matrix typically records each requirement using a set of four designations. This is the model most mature service providers use, and it is the one to build toward, because it is unambiguous and easy to validate control by control:

• Service Provider: the requirement is fully implemented and maintained by the provider.
• Customer: the requirement is fully implemented and maintained by the customer.
• Shared: both parties have implementation responsibilities.
• N/A: the requirement does not apply to the service.

Define each of these values in plain language at the top of the document so that every reader interprets them the same way and apply them consistently throughout.

Using RACI to Understand the Context

A Responsible, Accountable, Consulted, and Informed (RACI) framework is a useful lens for working out where a responsibility actually lands before you commit it to the matrix. It prompts you to separate the party that performs the work (Responsible) from the party that answers for the outcome (Accountable), and to account for anyone who must be Consulted or kept Informed along the way.

That fuller picture is what helps you decide, for a control whose responsibilities are genuinely split, whether the honest designation is Shared, and what the accompanying note should say.

The distinction is worth holding onto: RACI is the reasoning tool that helps you understand a responsibility, and the four designations above are what the matrix records. Keeping those two roles separate prevents a document that reads like a half-finished RACI grid, which is harder to validate and easier to dispute.

Building the Matrix, Step by Step

1. Define the scope

Start by listing every requirement, control, or task that could apply to the service. For a PCI DSS matrix, that means working through the applicable requirements rather than a hand-picked subset. Where a requirement genuinely does not apply, mark it N/A and say why. An unexplained gap reads as an oversight, not a decision.

2. Assign ownership, one control at a time

For each item, ask a single question: who can implement this control?

• If only the provider implements it, the answer is Service Provider.
• If only the customer implements it, the answer is Customer.
• If the provider supplies the capability and the customer must configure, enable, review, act on, or maintain it, the answer is Shared.
• If the requirement does not apply to the service, the answer is N/A.

Resisting the urge to default everything to “Shared” is worth the effort. A matrix where half the rows are shared and none are explained tells the reader almost nothing.

3. Write clear notes, especially for shared controls

The notes column is where a matrix earns its keep. A shared designation with no explanation leaves both parties guessing about the split. A good note names who does what.

For example:
Requirement 8.5, Multi-Factor Authentication
Responsibility: Shared. The service provider supplies and maintains the multi-factor authentication (MFA) capability within the platform. The customer is responsible for enrolling users, enforcing MFA policies, and ensuring that all appropriate administrative and user accounts are covered.

That level of specificity is what makes a matrix hold up under scrutiny, and it is what prevents the finger-pointing described at the start of this article.

4. Point to the underlying documentation

Where a provider publishes an implementation guide, a customer responsibility document, or a written responsibility acknowledgement, reference it directly in the matrix. Those cross-references let a reader move from “who owns this” to “and here is how it is actually configured” without leaving the document behind.

5. Establish an update process

Services change. Providers add features, retire others, and shift the boundary of what they manage. A matrix that reflects last year’s service model is worse than no matrix because it creates false confidence. Decide up front who reviews the matrix, on what cadence, and what events trigger an off-cycle update, such as a new integration, a change of provider, or a change in how account data flows.

How to Use a Responsibility Matrix for Third-Party Vendors

A responsibility matrix can serve as a shared reference point throughout the third-party vendor relationship, from initial onboarding through ongoing operations and contract renewals. Rather than treating it as a one-time document, use it to establish clear ownership and maintain accountability as the relationship evolves.

Once completed, review the matrix with the vendor to confirm that responsibilities are clearly understood and align with the contract and service-level agreements. Keep the finalized matrix accessible to the teams responsible for vendor management, security, compliance, and operations.

Finally, review and update the matrix whenever the vendor’s services, systems, contractual obligations, or organizational responsibilities change. Regular reviews help ensure the matrix remains an accurate representation of who is responsible for what, and can prevent gaps from emerging over time.

What A Good Responsibility Matrix Looks Like

When CampusGuard reviews a service provider responsibility matrix during a PCI DSS assessment, we generally expect to see the same handful of things:

• Every applicable requirement listed, with nothing quietly omitted.
• A clear designation of Service Provider, Customer, Shared, or N/A for each.
• Notes that actually explain the shared responsibilities rather than restating the label.
• References to the provider’s customer documentation or implementation guides.
• Direct alignment with Requirements 12.8.5 and 12.9.
• A defined process for keeping the matrix current as services change.

A matrix built to that standard is the most defensible version of the document, and it aligns directly with what PCI DSS 12.8.5 asks for.

An Illustrative Structure

The most durable format is a control-by-control table that lists each applicable requirement, marks it against the four designations, and carries a notes column for explanation and evidence. A short excerpt, drawn from a hosted payment application scenario, shows the shape of it:

Common Pitfalls to Watch For

• Silent N/A calls: Marking a requirement as not applicable without a reason invites questions later. Document the rationale.
• Undefined “Shared” rows: A shared designation is only useful when the split is spelled out.
• No source references: A matrix that stands alone, with no link to the provider’s implementation or responsibility documentation, is harder to verify and easier to dispute.
• The one-and-done matrix: Treating the document as an onboarding formality, never revisited, guarantees it will be wrong within a service cycle or two.

Making Your Responsibility Matrix Work for Your Organization

A responsibility matrix is not a compliance checkbox. It is the document your team reaches for at the moments that matter most: onboarding a new vendor or customer, working through an assessment, coordinating an incident response, and renewing a contract.

Each of those moments turns on the same question the matrix was built to answer, which is who owns what. Kept current and kept specific, it answers that question the same way every time.

If you would like help building a PCI DSS v4.0.1 control-by-control matrix for one of your vendor/merchant relationships, or validating a matrix a provider has handed you, contact  CampusGuard to help you get started.

Frequently Asked Questions About Responsibility Matrices

What is the purpose of a responsibility matrix?

A responsibility matrix clarifies who is responsible, accountable, consulted, and informed for specific tasks and decisions, reducing confusion and gaps in ownership.

What is the difference between a RACI and a responsibility matrix?

A RACI matrix is one type of responsibility matrix that uses four roles: Responsible, Accountable, Consulted, and Informed to define ownership.

What should be included in a responsibility matrix?

A responsibility matrix should identify the tasks, controls, decisions, or processes being managed and clearly assign responsibility and accountability for each one.

How often should a responsibility matrix be updated?

Organizations should review responsibility matrices regularly and whenever there are significant changes to services, contracts, responsibilities, systems, or regulatory requirements.