Does outsourcing payments to a PCI DSS compliant provider remove your PCI DSS obligations?
Outsourcing all card processing usually shrinks the PCI DSS requirements that apply to you, but it does not remove your own validation. A merchant that never stores, processes or transmits cardholder data still has to validate compliance, typically with a Self-Assessment Questionnaire such as SAQ A, as explained in PCI SSC FAQ 1092. The SAQ D note to requirement 12.8.1 makes the same point from the other side: using a PCI DSS compliant provider does not make an entity compliant or remove its responsibility for its own compliance. Read the outsourced arrangement as a reduction in scope, not an exemption.
Which duties remain depends on your payment channel, on whether your payment pages redirect customers to the provider or embed its iframe, and on what your acquirer or payment brand requires. A redirect or iframe page is still part of your environment, so SAQ A calls for quarterly external vulnerability scans by an Approved Scanning Vendor under requirements 11.3.2 and 11.3.2.1, as set out in PCI SSC FAQ 1604. Confirm with your acquirer which SAQ type you must complete, whether your pages qualify for it, and whether any script or page content you host is in scope before you choose a questionnaire.
The provider does not validate you, and you cannot borrow its status. The merchant completes the SAQ, signs the Attestation of Compliance and owns it, while the provider's AOC supports your monitoring under requirement 12.8.4. Keep a current list of providers, signed written agreements, due diligence records, and a responsibility matrix showing which requirements the provider manages, which you manage and which are shared. Ask each provider for its current AOC, and check the date against your acquirer's requirements, since questions about an aging AOC go to the acquirer and payment brand, as noted in PCI SSC FAQ 1601.
What requirement 12.8 asks merchants to keep on file
Requirement 12.8 is a set of records and checks that stay with the merchant even when a provider handles all card processing. Each card below covers one sub-requirement, the document it produces, and the person inside your organization who should own it.
List of third-party service providers
Keep a current inventory of every third-party service provider (TPSP) that stores, processes or transmits account data for you, or that could affect the security of your payment environment. This includes the payment gateway, hosted payment page vendors and any script providers loaded on checkout pages. Store the list with the provider name, the services supplied and the date each relationship started. Procurement or the payments owner usually maintains it, and an assessor will compare it against your network diagram and your payment flows. Confirm that the list also covers providers you reach through a contract signed by someone else in the company.
Written agreements with security acknowledgments
Each TPSP needs a written contract that states the provider is responsible for the security of the cardholder data it handles or can affect, with an explicit acknowledgment of that responsibility. Ask legal and procurement to confirm that the wording covers the services in your list, including subcontractors and data retained after termination. Renewals and amendments are where these clauses most often drop out, so the contract owner should check them each time the agreement changes. Legal or the contract owner keeps the signed copies.
Due diligence before engagement
Before you sign, assess whether the provider's security is adequate for the service you are buying. Collect its current Attestation of Compliance (AOC), check the scope it covers and the date it was issued, and ask whether the services you need sit inside that scope. Record the questions you asked, the documents you received and the decision you made. The security or risk function owns this file, and the signed decision should be approved before any card data flows to the provider.
Compliance status monitoring at least every 12 months
Check each TPSP's PCI DSS status at least once every 12 months. A check means confirming that a current AOC exists, that its scope still matches what you use, and that the provider has not reported a lapse. Keep dated evidence of each check, such as the AOC copy, the date you reviewed it and the reviewer's name. Because the AOC date affects whether a document is still current, record the expiry date in your compliance calendar. The compliance lead usually owns this recurring task.
Responsibility matrix for each requirement
Maintain a record that states, for each PCI DSS requirement, whether the provider manages it, your organization manages it, or both share it. This matrix is what keeps the boundary between you and the provider visible during an assessment. Review it when services change, such as when you add a payment method or move a checkout page. Your compliance lead should own the matrix, and the provider should confirm its entries in writing. Ask any entry you cannot verify against the provider's AOC or responsibility documents.
How the remaining work changes by payment channel
With a full redirect, the customer leaves the merchant's site and completes payment on a page hosted by the provider. The merchant's systems never receive the primary account number, so the merchant's remaining work centers on the checkout pages that send the customer away, the integration that receives the result, and the written agreement that describes who manages what. Eligibility for the shortest self-assessment depends on the merchant meeting the criteria in PCI SSC FAQ 1588 for script-based and redirect payment pages, so the merchant should test that claim against its actual design rather than assume it.
- Eligibility check: Confirm that no card data fields, scripts or payment elements are served from the merchant's own pages beyond the redirect.
- Validation form: Expect to validate on SAQ A if the criteria are met, and confirm the choice with the acquirer or payment brand.
- Quarterly ASV scans: Requirements 11.3.2 and 11.3.2.1 apply where the merchant's webpage redirects to the provider (FAQ 1604).
- Provider evidence: Hold the provider's current AOC and the responsibility matrix that the provider's services cover.
- Redirect logic: Review how the merchant builds the redirect and how it handles the return page, since changes here can alter eligibility.
Before relying on this channel, check that the redirect and return pages are documented in the scope record and that someone owns re-checking eligibility after each change to the checkout.
An embedded iframe shows the provider's payment fields inside the merchant's own page. The customer sees the merchant's brand, but the card fields come from the provider's origin. This channel carries more risk than a redirect because the merchant's page is still the container that the customer uses, so anything that alters that page, including a third-party script, can affect the payment fields. The merchant therefore needs to manage both the iframe integration and the scripts that load on the same page.
- Page controls: Treat the payment page as in scope for script and change management, even though the card fields are hosted by the provider.
- Quarterly ASV scans: The same quarterly external scanning under 11.3.2 and 11.3.2.1 applies to pages that embed the provider's iframe (FAQ 1604).
- Script inventory: List every script that loads on the checkout page, its source and its owner.
- E-skimming guidance: Apply the controls described in the PCI SSC information supplement on payment page security and preventing e-skimming.
- Third-party scripts: Use the guidance in FAQ 1592 to decide how analytics, tag and widget providers are governed.
Before relying on this channel, confirm with the provider which page elements it controls and which ones the merchant must still monitor.
In API-based processing, the merchant's server sends a request to the provider and receives a token or a result. Card data is entered on a provider-controlled surface or captured through a provider-supplied component, and the merchant's systems handle tokens rather than card numbers. This model keeps card data away from the merchant's environment only if the design is correct, so the merchant still needs to show how its servers, logs and databases avoid receiving card data by accident.
- Data path mapping: Document every system that handles the request, the response and any error messages, and confirm none of them stores or logs card data.
- Validation path: Confirm with the acquirer whether the integration fits a shorter questionnaire or requires a broader one, since the answer depends on the design, not the label.
- Token handling: Record how tokens are stored, who can use them and what happens if a token is exposed.
- Provider AOC dates: Check the provider's most recent AOC and the date it covers, and monitor its status at least every 12 months under 12.8.4.
- Accidental capture: Include logs, support tickets and backups in the periodic check for stray card data.
Before relying on this channel, ask the provider to confirm in writing which components handle card data and which the merchant's code can reach.
Many merchants run more than one channel at once, such as a hosted checkout for web orders and a telephone or point-of-sale flow handled by a different tool. Each channel can point to a different validation form and a different set of scans, and the merchant's annual confirmation has to cover all of them. The risk here is that a channel added later, or a channel run by a team outside payments, falls outside the records that the merchant maintains.
- Channel inventory: Keep one list of every way the merchant takes card payments, including those added through marketing or partner tools.
- Per-channel validation: Record which form and scans apply to each channel, and note where the answer may change.
- Shared responsibility records: Update the matrix for each channel so that no channel lacks a named owner.
- Change triggers: Re-check the channel map whenever a new checkout, script or payment tool is introduced.
- Acquirer confirmation: Confirm the mixed-channel validation approach with the acquirer or payment brand, since they manage the compliance program.
Before relying on this structure, verify that the channel inventory matches what is live on the website and in the point-of-sale estate, not only what the project plan describes.
How to validate after you outsource: from SAQ selection to AOC
This sequence shows how a merchant that outsources payment processing confirms its provider's status, establishes which SAQ applies, documents its own validation, and keeps the provider check current each year. Each step ends with a record the merchant holds.
Collect the provider's AOC and service scope
Ask the payment provider for its current Attestation of Compliance and a written description of which payment services it covers, such as hosted payment pages, redirects or iframes. Your team, usually the compliance or finance lead, requests the document; the provider issues it through its own assessor. Check the AOC date, the assessment type and that the listed services match what you use. The output you keep is a dated copy of the AOC and a note of the services in scope. Note that a certificate or logo is not accepted as validation under FAQ 1220.
Map responsibilities for each requirement
Record which PCI DSS requirements the provider manages, which you manage and which are shared, based on the provider's responsibility matrix and your own payment flow. Confirm the matrix covers your integration method, because a redirect and an embedded iframe leave different pages in your hands. Your team completes the mapping and the provider confirms it in writing. The output is a signed responsibility record that you will reuse at the annual review.
Confirm SAQ eligibility with your acquirer
Ask your acquirer or payment brand which Self-Assessment Questionnaire applies to a merchant that fully outsources payment processing. FAQ 1092 notes that such merchants typically validate with a questionnaire such as SAQ A, and that the acquirer is the right party to confirm obligations. Ask whether the validation level and any reporting deadlines are set by your acquirer. The output is a written confirmation of the SAQ type and validation route that you keep with your compliance file.
Complete the SAQ and sign the AOC
Your team completes the chosen SAQ on the official PCI SSC template, answering each eligibility and requirement question for your own environment, including the systems and staff you still control. A merchant signs the Attestation of Compliance on the PCI SSC template, and that AOC is the merchant's own statement, not one issued by an assessor or by DeployOpen. Have an accountable officer review and sign it. The output is the completed SAQ and the signed AOC, which you submit to your acquirer when required.
Run ASV scans where the channel requires them
If your payment pages redirect customers to the provider or embed its iframe, the SAQ A requirements for quarterly external vulnerability scans by an Approved Scanning Vendor apply to those pages, as set out in Requirements 11.3.2 and 11.3.2.1 and FAQ 1604. Engage an ASV, run the scans on the schedule the requirements set, and address any failing findings before you submit. The output is a set of passing ASV scan reports tied to your public-facing payment pages. Confirm with your acquirer which scan reports it accepts.
Store and reconcile the evidence file
Gather the provider AOC, the responsibility record, the acquirer confirmation, the signed SAQ and AOC, and any ASV reports into one dated evidence file. Check that the AOC dates and the scope named in your SAQ still match your current integration. If an AOC is nearly a year old, FAQ 1601 directs questions about accepting it to your acquirer and payment brands. The output is a single, current compliance file that an acquirer or assessor can review without further requests.
Repeat the provider status check each year
Under Requirement 12.8.4, monitor the provider's compliance status at least every 12 months, and review the responsibility record whenever the provider or your payment flow changes. Request the new AOC, compare its scope with your records and update the matrix where needed. Your team owns this check even though the provider performs its own assessment. The output is a dated annual review note and a refreshed AOC on file, which feeds the next SAQ cycle.
Checking a provider's AOC date before you rely on it
A service provider that holds an Attestation of Compliance is expected to hand it to you on request, and you can also ask for the relevant sections of its Report on Compliance or SAQ D. Ask for these before you sign, and again at each annual review under requirement 12.8.4. The AOC tells you which services were assessed, on what date, and whether the result was compliant. Your own validation depends on that scope matching what the provider actually runs for you, so read the services list line by line rather than the headline result.
The date needs careful handling. PCI SSC FAQ 1601 says evidence an assessor reviewed and judged valid stays valid for that assessment. It does not say that an AOC dated close to a year earlier is automatically acceptable to you. Questions about accepting such an AOC belong to your acquirer and the payment brands that run the compliance programs. Confirm their rule in writing, including how old an AOC may be and what they expect when a newer one has not yet been issued. Do not assume the rule from another merchant or from a provider's sales material.
For each provider, record the AOC date, the assessment type, the services and payment functions covered, any exceptions or compensating controls noted, and the date you next expect a new AOC. Keep a gap list for anything the AOC does not cover, such as an integration or hosting component you use but the assessed scope omits, and raise it with the provider and your acquirer. Store the record with your 12.8 provider inventory so that a reviewer can see when each reliance decision was made and on what evidence.
Who owns each part of the outsourced payment work
This table compares the three parties in an outsourced payment setup: the merchant, the payment provider and the QSA or ASV assessing them. Read each row to see what the party produces and what it cannot do on the merchant's behalf. The main takeaway is that a compliant provider narrows your obligations but does not transfer your validation or your 12.8 duties.
| Owner | What they produce | What they cannot do for the merchant |
|---|---|---|
| Merchant | Validation on the SAQ that fits its payment channel, its signed AOC, a list of TPSPs, written agreements, due diligence records and a responsibility matrix | Cannot rely on the provider's AOC alone to prove its own compliance or remove its responsibility for its own environment |
| Merchant (own systems) | Compliance evidence for any webpage, redirect, iframe or internal system that still touches payment flows, including ASV scan results where SAQ A requires them | Cannot hand off payment page security to the provider when the merchant controls the checkout page code or scripts |
| Payment provider | Its own PCI DSS assessment for the services it delivers, and an AOC it can give customers on request | Cannot validate the merchant's SAQ, set the merchant's responsibility split for it, or cover services it does not deliver |
| QSA | A Report on Compliance and AOC for the entity it assesses, based on evidence it reviews and judges valid | Cannot write the merchant's policies or perform the merchant's monitoring, and cannot be the same firm that designed the controls it tests |
| ASV | Quarterly external vulnerability scan results and an attestation for in-scope external addresses | Cannot confirm the merchant's overall validation, fix vulnerabilities on its behalf or cover internal systems |
| DeployOpen (implementation partner) | Prepared documentation, configured systems and organized evidence that the merchant or its assessor can review | Cannot issue ROCs, AOCs, scan results or certificates, and cannot replace the merchant's own sign-off or assessor's judgment |
| Acquirer or payment brand | Program rules, validation deadlines and answers on which SAQ applies and how old provider AOCs are treated | Cannot waive the merchant's obligation to validate, and cannot accept evidence that the merchant has not collected |
Where outsourced merchants usually fall short
Outsourcing payments does not outsource the obligation to validate. The gaps below recur across merchants that hand card capture to a provider, and each one shows up in the same place: the evidence an assessor asks to see during validation.
No annual provider status check
Requirement 12.8.4 expects you to monitor each third-party service provider's PCI DSS compliance status at least every 12 months. Many merchants collect the provider's AOC once at onboarding and never look again. Set a recurring calendar task, record the date you checked, and file the AOC or the relevant sections of the provider's ROC or SAQ D. An assessor will ask for the most recent check, not the first one.
Unsigned or outdated written agreements
Requirement 12.8.2 calls for written agreements that acknowledge the provider's responsibility for the cardholder data it handles or can affect. Check that the signed contract names the payment services in use, carries a security acknowledgment, and still matches the current integration. A contract that predates a change in payment flow, such as moving from redirect to iframe, is a common finding. Ask the provider for the signed copy, not the template.
Responsibility matrix that ignores the integration
Requirement 12.8.5 requires a record of which PCI DSS requirements the provider manages, which you manage, and which are shared. Matrices copied from a provider's generic template often assume a different integration than the one live on your site. Walk through the actual payment flow, including the scripts and tags on checkout pages, and assign each requirement to the party that operates it. Review the matrix whenever the integration changes.
Redirect and iframe pages without ASV scans
A merchant that sends customers to a provider's hosted page or embeds its iframe may still validate with SAQ A, and that route carries quarterly external vulnerability scans by an Approved Scanning Vendor under Requirements 11.3.2 and 11.3.2.1. Merchants often assume the provider's scans cover their own pages. Confirm which URLs are in scope, schedule the ASV scans for them, and keep the passing scan reports with your SAQ A.
Stray card data in email and logs
Outsourcing does not stop customers from sending card numbers through support email, chat transcripts or form fields that write to application logs. Any stored PAN brings those locations back into scope and can invalidate the SAQ you selected. Search mailboxes, ticketing systems and log stores, document the search, and set a procedure for removing unexpected PAN and reporting it. Assessors often ask for the search results and the incident record together.
Where an implementation partner helps and where it cannot
An implementation partner can take a defined, fixed-scope share of the work that sits around a merchant's outsourced payment model. DeployOpen, for example, can document the integration and data flows between the merchant's website or order systems and the provider, build the responsibility records that show which PCI DSS requirements the provider manages, which the merchant manages and which are shared, and maintain a provider register with the dates each provider's status was last checked. It can also assemble evidence packs (provider AOCs, written agreements, monitoring notes, ASV scan reports where they apply) and configure the self-hosted systems the merchant keeps, such as web servers, logging, access controls and patch records. Scope, deliverables and timelines are agreed in writing before work starts, so the merchant knows exactly what has been built and what it still has to run itself.
The merchant keeps ownership of its controls, its SAQ and its Attestation of Compliance. A partner can help the merchant understand the requirements and prepare material, but the merchant's own officers must decide which controls apply, sign the attestation and answer for the results. Acceptance is decided by others: the acquirer and payment brands set the validation expectations for the merchant, and an independent assessor, where one is required, judges the evidence. A partner that prepares documents does not issue validation, and an SAQ completed with outside help is still the merchant's declaration. Ask any partner to confirm this split in the statement of work before signing.
No engagement guarantees a passing result, a particular SAQ type or acceptance by an acquirer. Confirm with your acquirer which SAQ and evidence they expect, and check that any provider's AOC is current before you rely on it, since an assessor or acquirer, not the implementation partner, decides whether older evidence is still acceptable. Plan for the recurring work after go-live as well: the 12.8 monitoring cycle, evidence refreshes and changes to the integration will still need an owner inside the merchant's team, whether that owner is an employee or a retained support arrangement.
Questions merchants ask before outsourcing payments
Does outsourcing payment processing remove PCI DSS from our business?
No. Outsourcing reduces what you store, process and transmit, but it does not remove your own PCI DSS obligations. Using a PCI DSS compliant provider does not make you compliant or remove your responsibility for your own compliance, as the SAQ D note to Requirement 12.8.1 makes clear. You still validate, and you still own the controls for any systems that touch the payment flow, such as your website, your staff access and your network. The first step is to confirm with your acquirer or payment brand what applies to your setup, since they manage the compliance programs.
Which SAQ applies after we fully outsource payment processing?
Merchants that fully outsource payment processing typically validate with a Self-Assessment Questionnaire such as SAQ A, according to PCI SSC FAQ 1092. Which SAQ fits depends on how your payment page is built and whether any cardholder data reaches your environment, so the answer is not automatic. Eligibility questions should go to your acquirer or payment brand, who decide which validation type they accept. Ask them to confirm the SAQ in writing before you prepare the questionnaire, and keep that confirmation with your evidence. The completed questionnaire is documented with an Attestation of Compliance.
Do we need quarterly ASV scans if our checkout is a redirect or iframe?
Possibly. For SAQ A under PCI DSS v4.x, merchant webpages that redirect customers to a payment provider or embed its iframe fall under quarterly external vulnerability scans by an Approved Scanning Vendor, referenced as Requirements 11.3.2 and 11.3.2.1 (PCI SSC FAQ 1604). The scan covers the public-facing pages you control, so check whether your checkout, landing pages and third-party scripts are in the validated flow. Confirm the exact scope with your acquirer, and use an ASV from the PCI SSC list rather than assuming any scanner will do.
What should we ask a payment provider to show us before we sign?
Ask for the provider's current Attestation of Compliance and the relevant sections of its Report on Compliance or SAQ D, which PCI SSC FAQ 1576 says customers may request. Also ask for:
- The list of services covered by the AOC, so you can confirm they match what you buy
- The date of the AOC and whether it was reviewed for the current assessment period
- A responsibility matrix showing which requirements the provider manages, which you manage and which are shared
- A written agreement that includes security acknowledgments, as Requirement 12.8.2 expects
If the AOC is close to a year old, ask how the provider handles its renewal, since questions on older AOCs go to the acquirer and payment brands (PCI SSC FAQ 1601).
How often do we need to check the provider's PCI DSS status?
At least every 12 months, under Requirement 12.8.4. A one-time check at onboarding is not enough. Build an annual monitoring step that confirms the provider's compliance status is current, records the date you checked, and stores the AOC you reviewed. Trigger an earlier check when the provider changes services, is acquired, reports an incident or changes its hosting. Record the outcome in your third-party register so an assessor can trace each review to a dated source. Your acquirer can confirm the monitoring expectations for your validation level.
Can our internal team handle this without an outside partner?
Often yes, for the parts that are your responsibility. Your team can maintain the TPSP list, collect AOCs, record the responsibility matrix, run the annual review and complete the SAQ. Outside help is usually needed where the work requires independent judgment, such as a QSA assessment for a Report on Compliance or an ASV scan. Implementation partners such as DeployOpen can prepare systems, controls and evidence for your assessment, but only an independent assessor or the ASV issues validation. Decide which tasks your team owns, which go to a provider and which go to an assessor, and put that split in writing.
How DeployOpen prepares your payment environment evidence
DeployOpen works on the parts of an outsourced payment setup that stay with the merchant: the written provider inventory, responsibility records, provider evidence and the scan and validation records behind the questionnaire. We prepare these systems and records for your assessment, and the independent assessor or acquirer decides what is accepted.
How we scope
- We agree in writing which payment pages, redirects, iframes and internal systems fall inside your environment and which sit with the provider.
- The written scope lists the provider services, the requirements you still own and the questionnaire you expect to complete.
- Engagements are fixed-scope, so deliverables and timelines are agreed before any work begins.
How we build
- We prepare your provider inventory and responsibility matrix, recording which requirements the provider manages, which you manage and which are shared.
- We help set up the monitoring routine for provider AOC dates, status checks and contract acknowledgments, documented in a repeatable calendar.
- Where your pages redirect to or embed a provider, we prepare the page inventory and coordinate external scanning with an ASV you engage.
How we hand over
- You receive the written responsibility records, provider evidence index and monitoring records, organized for your assessor or acquirer to review.
- Each document states its date and owner, so you can show which provider AOC was current when your questionnaire was completed.
- We walk your team through the handover so the records can be maintained after the engagement ends.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers, covering changes to providers or payment pages.
- We can refresh the provider inventory and monitoring records when a provider changes services or its AOC is renewed.
- Questions about whether a provider AOC is acceptable are routed to your acquirer or payment brand, and we confirm that answer before you rely on it.
