What to outsource for PCI DSS and what to keep in-house

You can outsource tasks and technical work for PCI DSS, but you cannot outsource responsibility for compliance. The SAQ D note to requirement 12.8.1 states that using a PCI DSS compliant third-party service provider does not make an entity compliant or remove its responsibility for its own compliance, and the PCI SSC's position is that payment data security cannot be outsourced. Picture a merchant whose acquirer asks for an Attestation of Compliance: the provider may run the firewalls, the scanning or the logging, but the merchant still has to show that each requirement applies to its environment is met and who meets it. The split therefore depends on three questions: whether you outsource all payment processing, what each provider can touch in your cardholder data environment, and whether you run any systems of your own in that environment.

Start by building a responsibility matrix for every requirement, with one named owner per row. Mark which party performs the task, which party keeps the evidence and which party your assessor will ask. Under the topic's guidance, merchants that outsource all payment processing still must confirm the provider's compliance for its services, keep written agreements (12.8.2), check the provider's status at least annually (12.8.4) and define shared responsibilities. Ask each provider for its current Attestation of Compliance and the scope it covers, then check whether its services sit inside that scope. Ask your cloud or hosting provider for the same matrix, because the PCI SSC notes that written agreements and responsibility matrices should set out which party meets which requirement. Gaps found in this review are usually owned by you, not the provider.

How the work splits between your team, providers and assessors

Your team owns the compliance outcome. It decides which requirements apply to your environment, approves the policies and risk decisions, runs the daily and recurring operational tasks, and keeps the evidence that an assessor will sample. Outsourcing a function does not transfer this ownership, because the PCI SSC states that responsibility for payment data security cannot be outsourced.

Ownership of the outcome: Your team signs off on scope, the defined or customized approach used for each requirement, and any residual risk.
Recurring operations: Log reviews, access reviews, change approvals and alert response stay with your staff or a contracted operator you supervise.
Internal scanning and testing: Qualified internal staff may run internal vulnerability scans and penetration tests if they are organizationally independent from the systems they test. An ASV is not required for internal scans.
Evidence: Your team maintains inventories, diagrams, policies and records, even when a provider generates parts of them.
Provider oversight: Your team holds the written agreements, reviews the provider's compliance status and defines shared responsibilities.

Confirm internally who is accountable for each requirement before any provider is engaged, and check that the people reviewing a control are not the people operating it.

Can your team run internal vulnerability scans without an ASV?

Internal vulnerability scanning under PCI DSS can be run by your own qualified staff, provided the testers are independent of the systems they scan. An ASV is needed only for external scans, so the cards below separate what your team can own from what must go to an outside scanning vendor.

Internal scan scope and frequency

Requirement 11.3.1 expects internal vulnerability scans at least once every three months across the systems in the cardholder data environment and the network segments that connect to it. Your scan inventory should match the system inventory and network diagrams you maintain, so that any system added to the environment is picked up by the next cycle. Confirm that the scan covers every in-scope segment, including systems reachable only from internal networks.

Qualified internal testers

Testers may be qualified internal staff or a qualified external third party, and they do not need to be a QSA or ASV. What matters is that the people running and interpreting scans understand the tool, the scan policy and how to judge findings against the environment. Record each tester's qualifications and training so an assessor can see why they are competent to run the work.

Organizational independence of testers

Requirements 11.4.2 and 11.4.3 require testers to be organizationally independent of the systems and teams they test. In practice, the person who administers a firewall or patches a server should not be the only person who verifies that system's scan results. Document the reporting line of each tester and show that the separation is real, not just on paper.

High-risk and critical findings

Requirement 11.3.1 requires high-risk and critical vulnerabilities found by internal scans to be resolved, and the scan repeated to confirm the fix. Keep a ticket for each high-risk or critical finding with an owner, a due date, the remediation action and the rescan result that closes it. Assessors commonly ask for this trail, so a finding closed without a passing rescan will be questioned.

Rescan and passing result evidence

Keep the scan reports, the scan configuration, the date of each run and the rescan that proves a remediation worked. Retain these records in a form an assessor can sample across the year, not only the most recent cycle. Confirm with your assessor which report format and retention period they expect before you start the first quarterly cycle.

When an ASV is still required

Internal scans can be run in-house, but external vulnerability scans must be performed by an Approved Scanning Vendor. Check the ASV list before you contract a scanner, and confirm that the vendor's listing covers the external scan you need. Keep the ASV's passing reports alongside your internal scan evidence, since assessors review both.

How to collect service provider evidence before the assessment

This sequence turns a list of outside providers into written, dated evidence that shows which party meets each PCI DSS requirement, so the assessor can test your scope and your reliance on each provider. It should finish before the assessor starts testing, not during fieldwork.

Inventory every provider and its PCI-relevant services
Your team lists each third-party service provider (TPSP) that stores, processes or transmits cardholder data, could affect the security of the cardholder data environment, or manages systems inside it. For each one, record the service delivered, the systems or data it touches, and whether it has remote access. Include internal service providers and hosting or cloud platforms, since they often sit outside the usual purchasing list. The output is a provider register that the assessor can reconcile against your data-flow diagrams and scope. Confirm the list with system owners, because shadow SaaS tools are the most common gap.
Obtain current validation or service-specific evidence
For each provider, request its current PCI DSS Attestation of Compliance or Report on Compliance and confirm that the services you use are covered by it. Read the scope section, because a valid attestation for one product line does not cover another. Where a provider is not validated, ask for documented evidence that it meets the requirements that apply to its service, such as a recent internal review or results of its own testing. The output is a file per provider showing the document, its date, its scope and the services it covers. Ask the provider to confirm in writing that the document reflects its current environment.
Confirm written agreements cover security responsibilities
Review each contract to confirm it states that the provider is responsible for the cardholder data it handles or can affect, and that it will maintain PCI DSS compliance for its services. The agreement should cover the provider's obligation to notify you of material changes and its cooperation with assessments. Under Requirement 12.8.2, you must hold these written agreements. Have legal or procurement sign off on the file. The output is a signed agreement reference for each provider, linked in the provider register. Missing terms are a contract amendment item, not a footnote.
Build the responsibility matrix for each provider
Work with each provider to map every applicable PCI DSS requirement to the party that performs it: your organization, the provider, or both with a defined split. Cover operational tasks such as log review, firewall rule changes, patching, access provisioning and incident response, not only policy statements. The PCI SSC expects these matrices to be written down, so the output is a signed matrix per provider that the assessor can test against the systems. Where you cannot confirm who meets a requirement, treat it as yours until the provider evidences it. Responsibility matrices do not transfer accountability for your own compliance.
Check each provider's status at least annually
Set a recurring check, at least once every 12 months, that confirms each provider's validation is still current, its scope has not changed, and its services still match your contract. This step under Requirement 12.8.4 should also re-read the provider's latest attestation for new exceptions or compensating controls. Record the check date, the reviewer and the result in the provider register. The output is a dated status entry per provider, which is the evidence an assessor asks for first. Set the check as a calendar task owned by a named person, so it does not depend on memory.
Test the provider evidence against the actual setup
Compare what each provider has documented with what your environment shows. Check that the services in use, the connection methods, the accounts with remote access and the data flows match the attestation scope and the responsibility matrix. Reconcile this with your network diagrams and recent scan or log results. Where a provider claims to perform a task, such as daily log review, sample a recent period and confirm the output exists in your logs or its reports. The output is a list of confirmed items and gaps, each with an owner and a closing action. Gaps found here are far cheaper to fix before the assessor arrives.
Apply the FAQ 1312 test before relying on any provider
PCI SSC FAQ 1312 explains that a provider does not need to be validated for you to meet Requirement 12.8, but if it meets a requirement on your behalf and cannot show evidence that the requirement is met, that requirement is not in place for you. Apply this test to every row of the responsibility matrix. For each requirement a provider covers, you should be able to name the evidence and the date it was produced. Where the evidence is absent, mark the requirement as your responsibility and plan to meet it internally or with a different provider. The output is a sign-off record showing that every outsourced requirement has evidence the assessor can examine.
Hand the evidence file to the assessor
Package the provider register, attestations, agreements, responsibility matrices, annual status checks and test results into one indexed evidence file for the QSA or the self-assessment owner. Keep the independence boundary clear: your team and your providers prepare this file, and the assessor decides what it proves. Identify which requirements rely on provider evidence so the assessor can request the source documents directly. The output is a versioned evidence index that matches the scope of the Report on Compliance or the SAQ. Store the file so it can be reproduced later, since the next assessment will repeat the same checks.

What the quarterly program reviews under 12.4.2 require

Requirement 12.4.2 makes the service provider responsible for proving that its own security tasks are actually running, and it must do so at least every three months. The reviewers confirm that daily log reviews, network security control configuration reviews, application of configuration standards, responses to security alerts and change management are being performed as documented. The review is a check on the operation, not a repeat of the work. That separation is the point: someone who performs the daily log review cannot also confirm that the log reviews happened, because the confirmation would simply restate their own activity. Reviewers must be other than the people doing the work, and the reviews should be recorded with the reviewer, the date, the scope sampled and any exceptions found and fixed.

This obligation sits with the provider even when a customer outsources parts of the payment environment to it. A customer that relies on a provider for those functions should not accept a verbal assurance. Ask the provider for the most recent quarterly review records, the list of tasks covered, the identity of the reviewers and their role relative to the operations team, and the record of any exceptions and their remediation. Confirm too how the provider handles a review that finds a task was skipped, because an unaddressed gap undermines the customer's own compliance position under Requirement 12.8.4, which asks the customer to check the provider's status at least annually.

Before signing, check whether the provider's responsibility matrix names these reviews explicitly as provider duties, and whether the customer's own team has a matching check for the controls it keeps. Your team should confirm the review cadence in the written agreement and schedule a sample check of the records each quarter, so that a missing review is found during the year rather than during the assessment. Your assessor will decide how much of this evidence it needs, so confirm the expectations with them early.

Common mistakes that leave gaps after outsourcing

Outsourcing PCI DSS work moves tasks to a provider, but it does not move accountability. The pitfalls below share one root cause: the organization assumed someone else's evidence covered its own obligations. Each card names the check that closes the gap.

Treating a provider's AOC as your own

A provider's Attestation of Compliance covers the services that provider was assessed on, not your environment, your configurations or your staff. Under the SAQ D note to Requirement 12.8.1, using a compliant provider does not make you compliant or remove your responsibility. Ask which services and requirements the AOC covers, then map each gap to a control you own and can evidence.

Missing the annual provider status check

Requirement 12.8.4 expects you to confirm at least once a year that each third-party service provider is still PCI DSS compliant for the services you use. Providers change scope, fail to renew or lose validation, and the gap is invisible until an assessor asks. Put the check on a recurring calendar, store the current AOC and its date, and record who reviewed it.

Vague shared-responsibility matrices

A matrix that says the provider handles security will not survive assessment. The PCI SSC expects written agreements and responsibility matrices that state which party meets which requirement, for each service. Review every row for ownership, evidence location and review date. Requirements such as log review, access reviews and change management often fall between parties, so name one owner for each.

Cloud scope assumed, not confirmed

The PCI SSC's 2021 blog on scoping cloud environments makes the point that using a cloud service provider does not remove your ultimate responsibility for payment data security, and that responsibility cannot be outsourced. Teams often scope the cloud account as a whole, or assume the provider's shared-responsibility model covers PCI controls. Confirm in writing which controls the provider inherits, which you configure, and which systems sit inside your cardholder data environment.

Partner scans taken as independent testing

Requirement 11.3.1 requires internal vulnerability scans every three months, with qualified and independent testers, and the standard does not require an ASV or QSA for internal scans. A partner that configures your systems cannot also be the independent tester for those same systems. Keep the testing function organizationally separate from the team that built the controls, document that independence, and keep the scan reports and rescans as evidence.

Questions buyers ask about outsourcing PCI DSS work

Can we outsource all of our PCI DSS work to a provider?

No. You can outsource tasks, but not accountability. PCI DSS applies to any entity that stores, processes or transmits cardholder data or could affect the security of that environment, and the standard's own guidance says responsibility for payment data security cannot be outsourced. Merchants that hand all payment processing to a provider and never touch cardholder data may see many requirements not apply directly, but they still must confirm the provider is compliant for its services, keep written agreements, check the provider's status at least annually and define shared responsibilities. Ask each provider for a responsibility matrix that names which party meets each requirement.

Does using a PCI DSS compliant provider reduce our assessment?

It can reduce the number of requirements that apply to you, but it does not remove your own compliance obligation. The SAQ D guidance states that using a compliant third-party service provider does not make an entity compliant or remove its responsibility for its own compliance. Your assessment still has to show that the provider's services are covered, that agreements exist and that responsibilities are assigned. Whether your scope shrinks depends on how cardholder data flows, so confirm the outcome with your acquirer or assessor before you rely on it.

Can our own IT team run the internal vulnerability scans?

Yes, if the people doing the scans are qualified and organizationally independent of the systems they test. Requirement 11.3.1 calls for internal vulnerability scans at least once every three months, with high-risk and critical findings resolved and rescanned. Testers may be qualified internal staff or a qualified external third party, and they do not need to be a QSA or ASV. Your team should document scan scope, tool configuration, the people involved, remediation records and rescan results, because the assessor will sample them. Confirm the independence rule with your assessor before the first cycle, since a team that also configures the systems may need a second reviewer.

Do we need a QSA or an ASV for internal scans?

No. A QSA or ASV is not required for internal vulnerability scans. Those roles matter for other work: an Approved Scanning Vendor performs the external quarterly scans that the standard requires for systems facing the internet, and a Qualified Security Assessor writes the Report on Compliance. Internal scans are different. They are the responsibility of your qualified staff or an external tester who is independent of the work. Check the listing of any external scanning provider on the official Approved Scanning Vendors list before you sign, and confirm with your acquirer whether they expect an ASV for external scans in your environment.

What evidence must we keep from our service providers?

Keep evidence that proves each provider meets the requirements it performs on your behalf. The standard's guidance says that if a provider claims to meet requirements for you and cannot show evidence, those requirements are not in place for you. Practical items include a current Attestation of Compliance for the provider's services, written agreements, the responsibility matrix, the date you last checked the provider's status, and records of the provider's quarterly reviews. Service providers must also confirm, at least every three months, through reviewers other than those doing the work, that daily log reviews, configuration reviews, alert responses and change management are performed. Request those review records as part of ongoing oversight, not only at renewal.

What does an implementation partner cost compared with our own team?

The PCI SSC publishes no price for consulting or assessment, and your cost depends on the written scope. Your internal team is paid through salaries and tools that you already carry, while a partner is paid for defined deliverables such as gap analysis, control build, evidence preparation or testing support. Costs rise with the number of systems and payment channels in scope, the maturity of existing controls, how many third parties are involved and how much remediation is required. Partners cannot issue reports or attestations, so an independent QSA or assessor fee comes on top. Ask every bidder for a quote that lists deliverables, responsibilities, assumptions and what is excluded.

How DeployOpen scopes the work you keep and the work we prepare

DeployOpen plans, implements and hardens self-hosted open-source platforms inside your own cloud accounts, data centers or private networks, and prepares the systems, configurations and evidence that your PCI DSS assessor will examine. The split of work is set in a written, fixed-scope agreement before any work starts. That agreement lists each task against one of three owners: your organization, DeployOpen, or your independent assessor. Typical rows include ownership of the policies and the risk analysis under Requirement 12, approval of changes to the cardholder data environment, the internal vulnerability scan cadence under Requirement 11.3.1, and the quarterly reviews a service provider must run under Requirement 12.4.2. Ask for this matrix in writing, and check that every requirement in your scope appears against exactly one owner, with a named individual on your side.

DeployOpen does not issue Reports on Compliance, Attestations of Compliance or certificates, and it cannot tell you that an assessment will pass. Only a Qualified Security Assessor or the appropriate PCI SSC process issues validation, and the PCI SSC states that certificates are not recognized as validation. Our role ends at delivering prepared systems, documented controls and evidence packages, along with the testing agreed in the scope. Your assessor decides what it accepts, and a failed test or a rejected piece of evidence is a result you plan for, not one we guarantee. Where a finding is open, the agreement should say who fixes it, who retests it and what evidence closes it. Remember that using a compliant provider does not remove your own compliance obligations, so the written scope is also the record that shows where your responsibility sits.

Before you sign, confirm three things with your team and your assessor: which PCI DSS version and approach you are assessed against, whether any requirement will be met through the customized approach, and how the independent testers in your scope meet the organizational independence expectation for Requirements 11.4.2 and 11.4.3. Those answers change the work breakdown more than any other input, so they should appear in the scope document. Ask any provider for a clear change procedure, because scope changes after signature are where ownership most often becomes unclear. Fixed-scope terms make it easier to compare quotes, but only if the deliverables, dates and responsibilities are described precisely enough that two providers would read them the same way.

How DeployOpen prepares your PCI DSS evidence

DeployOpen works on the split between your team, service providers and assessors by preparing the systems and evidence that each party needs. We implement and document the self-hosted open-source platforms inside your own infrastructure, while the organization keeps ownership of its controls and an independent assessor issues any validation report.

How we scope

We agree a written scope that lists which responsibilities stay with your team and which are handed to a provider or assessor.
Scope covers the systems, cloud accounts or data centers where the platforms run inside your own infrastructure.
Engagements are fixed-scope, so deliverables and timelines are agreed in writing before work starts.

How we build

We build the controls and configurations your team owns, and document which requirements each one supports.
Internal vulnerability scanning and independent testing are set up with testers who are organizationally separate from the team that runs the platforms.
We prepare responsibility matrices that show which party meets each requirement, so shared duties are not left unclear.

How we hand over

You receive documentation of the platforms, configurations, scan schedules and evidence locations, written for your team to maintain.
Evidence for quarterly service provider reviews is laid out so reviewers outside the working team can check it.
Your team and your assessor receive a handover that confirms what we delivered and what you still need to confirm with them.

How we support

Ongoing support, upgrades and continuous testing are available as retainers after the initial scope is delivered.
We can help your team prepare for the next assessment cycle, but the assessor decides what evidence is sufficient.
Questions about which parties must act, including the assessor, should be confirmed with them and with the PCI SSC documents for your situation.

What to outsource for PCI DSS and what to keep in-house