12.9 TPSP support for customer compliance: evidence

What PCI DSS 12.9 asks service providers to do for their customers

Requirement 12.9 asks a service provider to acknowledge in writing that it is responsible for the security of its customers' account data, and to give those customers the compliance status and responsibility information they need when they ask for it. The first duty, 12.9.1, is a written acknowledgment. The second, 12.9.2, supports the due diligence and monitoring that customers must perform under 12.8.4 and 12.8.5. Requirement 12.9 applies only to service providers, so it is the counterpart of the customer's obligations in 12.8. A hosting company, managed service provider or SaaS platform in a payment flow that touches a customer's cardholder data environment (CDE) is expected to meet it. Customers cannot manage third-party risk without evidence. A merchant or acquirer that outsources part of its payment environment must decide whether the provider's controls are adequate, record that decision and check it each year. If the provider only offers reassurance in a sales call, the customer cannot complete its own assessment or explain the arrangement to its assessor. The work is mostly contractual and documentary: the acknowledgment sits in the agreement, the compliance status sits in an Attestation of Compliance (AOC) or in a Report on Compliance (ROC) section, and the responsibility split sits in a matrix. When product, legal and security teams each keep their own version, the answers to a customer's questions will conflict. Confirm that one owner maintains the matrix and that the contract language, the AOC scope and the matrix describe the same services.

Before the next customer request arrives, check three things. First, confirm that every customer contract contains the written acknowledgment and that the wording names the services in scope rather than the provider in general. Second, confirm the current AOC or the relevant ROC sections can be produced quickly, and that the assessor's scope matches the services you sell. PCI SSC FAQ 1576 notes that a provider with an AOC is expected to give it to customers on request, and that customers may also ask for relevant sections of the ROC or the SAQ D for Service Providers, so decide in advance which of those you will share and under what confidentiality terms. Third, review whether any OEM or reseller in your supply chain actually runs or maintains the service, because PCI SSC FAQ 1427 treats those that provide ongoing services as third-party service providers. A practical test is to pick one customer and ask for its 12.9 package from scratch: the signed acknowledgment, the current AOC, the responsibility matrix and the date of the last compliance review. Time how long assembly takes and note which documents need a person to find or update them. Gaps found this way are cheaper to fix in the contract template and the matrix than in an assessor's findings. Ask any consultant or implementation partner to help with the matrix and document set, but keep in mind that the organization owns the acknowledgment and the attestation remains the work of an independent assessor.

Which service providers and customer relationships 12.9 covers

Requirement 12.9 applies only to service providers, so the first question is whether your organization is one for this purpose. The cards below cover the decisions that determine which customer relationships need written acknowledgment and evidence, and which services bring your systems into a customer's cardholder data environment.

Confirm you are a service provider

Requirement 12.9 is written for service providers, not merchants. A merchant that outsources payment processing to a third party is not a service provider under this requirement, even though the merchant's own 12.8 duties apply. Check whether your organization stores, processes or transmits account data for others, or manages system components on their behalf. If you only handle your own card data, 12.9 does not apply to you, and the work sits under the merchant's own requirements.

Services that touch customer CDEs

The work grows with each service that reaches a customer's cardholder data environment. Hosting, managed firewall administration, remote support with privileged access, log management and payment gateway operation all create a relationship in which you can affect account data security. Map every service against the customer's data flows and list which ones could read, store, transmit or alter account data, or could affect its security. Services with no path into the customer environment usually fall outside the 12.9 acknowledgment.

OEMs and resellers under FAQ 1427

Equipment suppliers and resellers are not automatically service providers. Under FAQ 1427, an OEM or reseller that only supplies equipment and is not involved in its operation or maintenance is not a TPSP for Requirements 12.8 and 12.9. The position changes once that vendor provides ongoing services, such as remote maintenance, configuration or monitoring. Document each vendor relationship with the service it delivers, so the scoping decision can be defended to your assessor.

Contracts that need the acknowledgment

Each customer agreement that covers account data or the systems that handle it should contain a written acknowledgment that your organization is responsible for the security of that data. Review the master services agreement, data processing terms, statements of work and order forms, not only the security schedule. Confirm that the wording applies to every customer that falls under the service provider scope, including customers onboarded through older contract templates or acquired through mergers.

Ongoing support for customer reviews

Requirement 12.9.2 applies when customers ask for compliance status or responsibility information. Identify the people who handle these requests, the current Attestation of Compliance, and the sections of the Report on Compliance or the SAQ D for Service Providers that customers may request. Confirm with your assessor which items can be shared and under what confidentiality terms, and record each request and response so the trail is available at assessment.

Keep the scope current

The list of customer relationships changes as products, contracts and infrastructure change. Assign an owner to review the service provider population after new contracts, new services, acquisitions and changes in hosting. A customer that was once outside scope can move into it when you begin managing its environment. Record the scoping decision and its date for each relationship, so you can show that the acknowledgment and support processes cover the current customer base.

How an assessor tests 12.9.1 and 12.9.2

This table maps each part of Requirement 12.9 to how a QSA typically tests it, the evidence requested and the findings that come up most often. Read it as a checklist for what your customer-facing documents and request process must show before an assessment, and note that the assessor, not DeployOpen, decides whether the evidence is sufficient.

Element	What the assessor tests	Evidence requested	Common findings
12.9.1 Written acknowledgment	That the TPSP acknowledges in writing to each customer that it is responsible for the security of the account data it stores, processes or transmits on that customer's behalf	Signed customer agreements, or master terms and order forms containing the acknowledgment language, with a sample of executed copies	Acknowledgment missing from standard terms or onboarding templates; older customer contracts never amended
12.9.1 Scope of responsibility	That the acknowledgment covers the services in scope and matches the responsibility matrix provided to customers	Responsibility matrix, service descriptions and the contract clauses that reference them	Contract wording broader or narrower than the services actually delivered; matrix not linked to the agreement
12.9.2 Request handling	That a documented process exists for customers asking for compliance status, and that it is followed in practice	Written procedure, request log with dates and outcomes, and examples of responses sent	No owner named for requests; requests answered informally by sales or support with no record
12.9.2 Current compliance status	That the TPSP can provide its current PCI DSS Attestation of Compliance or SAQ D for Service Providers on request	Current AOC or SAQ D for Service Providers, with the validation date and scope statement	Expired AOC provided to customers; scope on the attestation does not cover the service being sold
12.9.2 Responsibility information	That responsibility information is current and supports customers meeting their 12.8.4 and 12.8.5 duties	Dated responsibility matrix, change history and the version sent to each customer	Matrix out of date after a platform change; no record of which version each customer received
Customer ROC or SAQ sections	That relevant sections of a ROC or SAQ D can be supplied to a customer who asks, within agreed confidentiality terms	Non-disclosure terms, the approved extract list and a record of past releases	Full reports shared without controls; no defined extract, so responses are inconsistent
Consistency across customers	That the same acknowledgment and status information is given to every customer in scope	Template library, version control records and a sample comparison across customer files	Different account managers using outdated wording or attachments in parallel
Ongoing currency	That documents are reviewed when services, scope or the PCI DSS version change	Review records, change tickets linked to document updates and the next review date	Documents not revised after the move to PCI DSS v4.0.1, or after a new service was added to the payment flow

How to implement 12.9 in sequence

This sequence turns 12.9 from a policy statement into a working service provider practice: a known customer base, written acknowledgments that match the responsibility matrix, a documented way to answer compliance requests, and a clear decision on what evidence leaves the organization. Each step names its output so the work can be checked.

Inventory customers and the services they rely on
Start by listing every customer that receives a service from your organization and the service each one uses, such as hosting, payment processing, managed security, or access to a customer cardholder data environment. Include customers reached through resellers or platforms. The owner is usually the account management lead working with the compliance lead, and the output is a customer register that records the service, the data or environment involved, and the contract that governs it. Confirm the register against your 12.8 TPSP list, because the two should describe the same relationships. Note that 12.9 applies only to service providers, so confirm your organization's role for each service before you assign obligations.
Draft the written acknowledgment and align the matrix
Prepare a written statement that acknowledges your responsibility for the security of the customer's account data that you store, process or transmit, or that could affect the security of the customer's cardholder data environment. Have legal review the wording and attach it to the customer agreement or a standard addendum. Compare the statement with your responsibility matrix so that every duty you acknowledge appears there with a named owner, and every matrix entry you cannot support is corrected before signature. The output is a signed or accepted acknowledgment for each customer, plus a matrix version that matches it.
Set up a request process for compliance status
Define how a customer asks for your compliance status and responsibility information, who receives the request, which channel it uses, and how it is logged. Name a single intake point, such as a shared mailbox or ticket queue, so requests do not stall in an account manager's inbox. Keep a record of each request, the response sent, and the date of the response. The output is a documented procedure and a request log that an assessor can sample to confirm that requests are received and answered. Ask your QSA or assessor to confirm the expected evidence format for this log.
Decide what evidence you share
Decide in advance which documents a customer may receive. PCI SSC FAQ 1576 says a TPSP with a PCI DSS Attestation of Compliance is expected to provide it on request, and customers may also ask for relevant sections of the Report on Compliance or the SAQ D for Service Providers. Define which sections are relevant to the service the customer buys, how you remove content that is not, and who approves the release. Confirm current validation status and scope with your assessor before each release, since an outdated attestation can mislead a customer. The output is a disclosure standard that lists each document, the redaction rules, and the approver.
Assign owners and test the response path
Give each part of the process a named owner: the customer register, the acknowledgment, the request intake, the evidence release, and the approval of disclosures. Run a tabletop exercise in which a sample customer asks for your attestation and responsibility information, and time each handoff against your own procedure. Record gaps and fix them, then repeat the test after any change in staffing or in the customer base. The output is an ownership table and a dated test record that shows the path works end to end. Ask your assessor how often they expect this test to be repeated.

Which evidence passes a 12.9 assessment

A 12.9 assessment looks for proof that a service provider has committed in writing to customer account data security and can produce current compliance and responsibility information on request. The cards below cover the artifacts that carry that proof and the routine that keeps them accurate between assessments.

Signed customer acknowledgments

These are the written statements in which the provider accepts responsibility for the security of account data it stores, processes or transmits for each customer. Assessors look for one acknowledgment per customer, signed by an authorized representative, with a version date and a link to the agreement that contains it. Check that the wording matches the services actually delivered, and that a customer added last month has an acknowledgment on file before go-live. Where terms change, keep the earlier version so the history of commitments can be shown.

Current Attestation of Compliance

The Attestation of Compliance is the signed summary that states a provider's validated PCI DSS status and the date of its assessment. Customers may ask for it, so it must be the current one, not a copy from the prior cycle. Confirm the assessment scope on the attestation covers the services the customer buys, and record the date you sent it. A certificate or a marketing statement cannot substitute for this document.

ROC or SAQ D sections for customers

Customers may ask for relevant sections of the Report on Compliance or the SAQ D for Service Providers rather than the full document. Prepare a sanitized extract for each common request, covering the requirements that concern the customer's service, and confirm it does not disclose confidential detail outside what the customer needs. Assessors check that the extract matches the validated report and carries no statement the report does not support.

Shared responsibility matrix

The responsibility matrix divides each PCI DSS requirement between the provider and the customer for every service in the customer's environment. Assessors compare it with the provider's own controls and with the customer's acknowledgment, looking for gaps where neither party is named for a requirement. Review the matrix whenever a service changes, and confirm that each row names an owner and the evidence the owner produces.

Dated request log with responses

A request log records each customer inquiry about compliance status, the artifact sent in reply, the date sent and the person who approved it. Assessors use it to test that requests are answered on time and that the provider produced what the customer was actually entitled to receive. Keep entries for declined or partial requests with the reason. Without this log, the provider cannot show it met its obligation when asked.

Review cadence between assessments

Assessors expect evidence to be current, not only correct on the day of the assessment. Set a recurring review that checks acknowledgments, the attestation date, customer extracts and the responsibility matrix against the current service inventory, and record each review with its owner and outcome. Ask the assessor how they expect changes between cycles to be handled, and confirm the cadence with your own compliance program and the customer contracts that require notice.

How the request-and-response cycle keeps evidence current

A customer request under Requirement 12.9 should move through a fixed path: intake, a named owner, a response built from an approved document set, and a dated record of what was sent. The point of the cycle is that the answer a customer receives matches what the service provider actually does today. Each request needs a single accountable owner, usually someone in compliance or security who can pull the current Attestation of Compliance, the responsibility matrix and the relevant sections of the ROC or SAQ D for Service Providers. Confirm internally who that owner is, who approves a response, and how long a request may wait before it escalates.

The approved document set is the part most likely to drift. The written acknowledgment required by 12.9.1 and the responsibility information provided under 12.9.2 both go stale when a service changes, a subservice provider is replaced or the Attestation of Compliance expires. Version control on those documents matters because an assessor will ask which version a customer received and whether it matched the controls in force on that date. Tools such as XWiki keep page history with what changed, when and by whom, and let users compare versions and roll back. BookStack assigns abilities through roles and can override permissions at the shelf, book, chapter or page level, which helps limit who can edit the responsibility matrix. Your organization must confirm whether either tool fits its governance, retention and audit needs before relying on it.

What meeting 12.9 costs in money and effort

This table breaks down who is paid for each part of meeting 12.9 and whether the cost is one-time or recurring. Use it to build a quote request, since most of the spend comes from the written acknowledgment, the response process and the assessor's review of evidence rather than from any single fee. No prices or durations are stated because none were supplied; ask vendors and assessors for their own written figures.

Cost component	Who is paid	One-time or recurring	What drives it up or down
Legal review of customer acknowledgment language	Internal counsel or outside law firm	One-time, revisited when the contract template changes	Number of customer contract templates, and whether each customer negotiates its own wording
Responsibility matrix and compliance status packet	Internal compliance team, security engineers, or implementation partner	One-time build, then recurring updates	Number of services offered, shared responsibilities, and how often the platform changes
Customer request handling process	Internal compliance and account teams	One-time design, recurring staff time	Volume of customer requests and how much evidence is pre-packaged
Evidence upkeep for the AOC or relevant ROC sections	Internal staff or implementation partner	Recurring, usually tied to each assessment cycle	Level of automation in evidence collection and the currency of the scope documentation
QSA assessment producing the AOC or ROC	Qualified Security Assessor firm	Recurring, at each validation cycle	Scope size, number of services assessed, and how complete the evidence is at the start
External review of the process or evidence	Independent consultant or second assessor	Optional, periodic or one-time	Whether the reviewer is independent of the team that built the process and the depth of testing requested
Customer-facing support on assessment questions	Internal account or security staff	Recurring, driven by customer demand	Number of customers with audit obligations and clarity of published responsibility information

Who owns 12.9 and what can be outsourced

Your organization owns requirement 12.9 in full. The service provider is the party that must acknowledge responsibility in writing and must answer customer requests for compliance status and responsibility information. No partner or assessor can accept that accountability on your behalf, so legal, compliance and product owners need named roles before a customer asks.

Legal drafts and maintains the written acknowledgment of responsibility for account data security and checks that it matches customer contracts and the terms that describe each party's responsibilities.
Compliance owns the current Attestation of Compliance or SAQ D for Service Providers, tracks its expiry, and decides what can be shared with which customer under confidentiality terms.
Product owners own the responsibility matrix for each service, state which requirements the customer must meet, and confirm that the matrix reflects how the service actually runs.
The request process needs a single intake point, a response deadline, and a record of what was sent to whom and when.
Change control should trigger a matrix review whenever a service, hosting location or subprocessor changes.

Confirm that each role has a named person and a backup, and that the matrix and acknowledgment are reviewed on a schedule your compliance team can evidence.

Where service providers usually fall short on 12.9

Most 12.9 failures are not missing policies. They are gaps between what the contract says, what the responsibility matrix says, and what a customer receives when it asks. The cards below cover the places where those documents drift apart and the evidence trail goes quiet.

Acknowledgment missing from older contracts

Agreements signed before the service provider adopted PCI DSS v4.x often say nothing about responsibility for customers' account data. Under 12.9.1, the written acknowledgment must cover that responsibility, so an older template may leave a gap that only surfaces when a customer's assessor asks. Pull every active customer agreement, sort them by template version, and confirm each one contains the acknowledgment wording before the next customer request arrives.

Responsibility matrix that disagrees with the contract

The responsibility matrix is often built by engineering, while the contract is drafted by legal, and the two drift apart after each product change. When a customer asks who patches the platform or manages log review, a contradiction between the two documents undermines the acknowledgment itself. Reconcile the matrix against each signed agreement and assign one owner to approve changes to either document.

Stale attestation shared with customers

Sending a customer last year's Attestation of Compliance is a common shortcut, and it fails the purpose of 12.9.2 when the reporting period has ended or the scope has changed. FAQ 1576 expects a service provider with an AOC to provide it on request, and customers may also ask for relevant sections of the ROC or SAQ D for Service Providers. Confirm the current AOC's validity dates and scope before each release, and record which version went to which customer.

No logged response trail

Support requests for compliance documents often run through email or chat, leaving no record of what was requested, what was sent and what was withheld. Without that trail, the provider cannot show it supported customers' 12.8.4 and 12.8.5 monitoring activities. Route every request through a ticket with a named owner, store the version sent, and keep the correspondence with the customer's account record.

OEM and reseller confusion under FAQ 1427

Hardware vendors and resellers that only supply equipment are not TPSPs for 12.8 and 12.9, but FAQ 1427 notes they can become TPSPs if they provide ongoing services. Teams often assume a reseller relationship exempts them, even when the same company runs managed monitoring or remote maintenance for the customer. Document each customer relationship with a service classification, and reassess any reseller arrangement that adds ongoing operational work.

Version control on compliance documents

Customer-facing responsibility statements change over time, and an old version may still circulate in proposals or shared drives. If the provider cannot show which wording a customer received on a given date, it cannot prove its acknowledgment was current. Keep each responsibility statement under version control with dates, authors and approvals, and retire superseded copies from shared locations.

Questions service providers ask about 12.9

How much effort does requirement 12.9 take for a service provider?

The effort is modest to write down but continuous to keep current. The one-time work is drafting the written acknowledgment for customers, agreeing the responsibility wording and assembling a pack of compliance status material. The recurring work is answering customer requests, keeping your Attestation of Compliance current and updating responsibility information whenever a service changes. The main drivers are how many customers ask, how many of your services sit inside the customer's cardholder data environment, and whether your documents already exist in a current form. PCI SSC publishes no hours or price for this work, so ask your QSA or consultant for a scoped estimate built from your customer count and service list.

Can our team meet 12.9 without outside help?

Yes, your team can carry out most of the 12.9 work itself, because it consists of written acknowledgments and document delivery that the service provider owns. Your team must write the acknowledgments, keep responsibility information accurate and manage customer requests. Outside help is usually most useful for a gap review, drafting support or a check that your documents match what your controls actually do. Only an independent QSA can issue the Report on Compliance and Attestation of Compliance. DeployOpen prepares systems, controls and evidence for assessments, but it does not issue reports or certifications. Confirm the division of work in writing before any engagement starts.

What does requirement 12.9 need from legal and product teams?

Legal owns the wording of the written acknowledgment under 12.9.1, which should state your responsibility for account data security and agree where your responsibility ends and the customer's begins. Legal also decides how that language sits alongside confidentiality clauses and how copies of your AOC are shared under non-disclosure terms. Product owns the technical side of the same boundary: which features run inside the cardholder data environment, which controls the platform enforces and which settings customers must configure themselves. Product should also tell legal and customers when a change alters responsibilities, so the responsibility information stays accurate. Keep both teams working from one shared responsibility document so that contracts and service descriptions match.

Does a PCI DSS certificate satisfy requirement 12.9?

No, a certificate does not satisfy 12.9. PCI SSC FAQ 1220 on compliance certificates states that certificates are not recognized as validation. Validation uses official PCI SSC documents: a Report on Compliance completed by a Qualified Security Assessor, or a Self-Assessment Questionnaire, each supported by an Attestation of Compliance. For a service provider, the material customers can request is the AOC and, under PCI SSC FAQ 1576, relevant sections of the ROC or the SAQ D for Service Providers. Build your 12.9.2 response from these documents together with your responsibility information, so customers receive the assessment record itself.

Who must receive our PCI DSS Attestation of Compliance?

Any customer that asks for it should receive your Attestation of Compliance. PCI SSC FAQ 1576 says a third-party service provider holding a PCI DSS AOC is expected to give it to customers on request, and customers may also ask for the relevant sections of the ROC or the SAQ D for Service Providers. The standard does not list which customers must ask. The payment brands decide which entities must validate and run any enforcement programs, and PCI SSC does not enforce compliance, so the request often comes from a customer's acquirer or contract. Keep a current copy of the AOC, its validation date and a log of each request and what you sent, so you can answer the next request quickly.

How does requirement 12.9 link to 12.8 monitoring?

Requirement 12.8 covers the customer's management of its providers, and 12.9 covers what the provider gives back. Under 12.8, the customer keeps a list of its third-party service providers, holds written agreements, performs due diligence and monitors each provider's compliance status yearly. Requirement 12.9 supplies what those checks need: written acknowledgment of responsibility for account data, and compliance status and responsibility information when a customer asks. Your 12.9.2 response therefore supports the customer's 12.8.4 and 12.8.5 work. Keep the material current so that each yearly check reflects your records, and ask customers which evidence they plan to collect so you send the documents they will actually use.

Are equipment suppliers and resellers third-party service providers under 12.9?

Equipment suppliers are generally outside 12.9 when they only supply equipment and take no part in its operation or maintenance. PCI SSC FAQ 1427 on OEMs and resellers says OEMs and resellers in that position are not TPSPs for Requirements 12.8 and 12.9. A supplier that delivers ongoing services, such as remote monitoring, maintenance or managed operation of a payment system, may fall within scope. Check each relationship against the service actually delivered. Record the classification and your reasoning so an assessor can see how you treated each supplier, and confirm the final scoping decision with your QSA.

What evidence should engineers keep ready for 12.9 requests?

A 12.9 evidence pack has three parts: a dated written acknowledgment for each customer, a current AOC with the relevant ROC or SAQ D sections, and responsibility information for each service. Keep the pack under version control so you can show what changed, when and by whom. CISO Assistant ships PCI DSS among its more than 200 frameworks and runs assessments against them, which can help track evidence by requirement. XWiki keeps every page change under version control and lets you compare and roll back versions, while BookStack assigns abilities by role and lets you override permissions at shelf, book, chapter or page level. Test each tool against your own evidence workflow before adopting it.

How DeployOpen prepares 12.9 evidence

DeployOpen works on 12.9 as a service provider implementation partner: we help prepare the written acknowledgments, status information and responsibility material that customers request under the requirement. The organization owns its obligations and decides what it tells customers, and only an independent QSA issues a Report on Compliance or Attestation of Compliance.

How we scope

Written scope agreed before work starts, listing which customer-facing services and environments fall under 12.9.
Inventory of the customer agreements, templates and status requests the provider expects to receive and answer.
Clear split of which 12.9 items the provider owns, which DeployOpen prepares, and which the independent assessor reviews.

How we build

Drafting support for the written acknowledgment of responsibility for customer account data, reviewed by the provider's legal and security leads.
Assembly of a compliance status and responsibility information pack that maps each customer-facing statement to a supporting record.
Configuration of version-controlled documentation so each published statement can be traced to its owner, date and approver.

How we hand over

Named deliverables: acknowledgment templates, responsibility matrix sections, request-handling procedure and evidence index.
Walkthrough with the team that answers customer requests, so the process runs without DeployOpen involved.
Documented steps for sharing an Attestation of Compliance or relevant report sections, and what to confirm with the assessor first.

How we support

Ongoing support, upgrades and documentation updates are available as a retainer after the fixed-scope work closes.
Periodic review of customer responses and templates when services, hosting or responsibilities change.
Ask any implementation partner to confirm in writing which 12.9 items remain with your team and your assessor.