Can your QSA also be your PCI consultant? Independence rules

Can your QSA also be your PCI DSS consultant?

Not for the same controls. A QSA employee who recommends, designs or implements a control for an entity may not assess that control. Another QSA employee at the firm who was not involved in the design work may perform the assessment, according to the PCI SSC's FAQ 1562 on QSA independence. So the answer to your contract or acquirer question depends on which controls, which people and which deliverable are in play, not on whether the firm is a QSA company in general. In practice, check three things before you sign. First, who on the consulting side touched each control: if the same individual designed a control and would also test it, the firm needs a different assessor for that control. Second, what the deliverable is: a Report on Compliance (ROC) needs an independent QSA for the controls it tests, while a self-assessment questionnaire (SAQ) has its own rules, covered in the next section. Third, whether the evidence comes from another team at the firm. Your own organization owns its controls. An implementation partner prepares systems, configurations and evidence. Only the QSA issues the ROC and the Attestation of Compliance (AOC), and the QSA's independence has to hold for every control it assesses. Ask the firm in writing how it will separate its consulting and assessment teams, which QSA will sign the ROC, and whether that person had any role in the controls under review. Ask for the independence statement before scoping begins, not after the gap analysis is finished. If the same firm must both build and assess, plan for a second QSA for the affected requirements, and budget for that in the assessment scope rather than discovering it at the end of the engagement.

Which PCI work the same firm can and cannot do

A QSA employee who recommends, designs or implements controls for an entity may not assess those controls. Another QSA employee at the same firm who was not involved in that work may perform the assessment, so the firm can stay in the engagement only if the people are separated. The rule is about individuals and the specific controls they touched, not about the firm as a whole.

Personnel separation: The assessing QSA must be someone who did not design, recommend or implement the controls under review.
Scope of the conflict: The restriction applies to the controls the QSA helped build, so other controls the same firm did not touch may still be assessed by the same team.
Documentation: Ask the firm in writing which people worked on which controls and how the assessment team was staffed.
Quality of the build: A consultant's design work still needs to be tested by an independent assessor, who decides whether the controls meet the intent of each requirement.
Pre-assessment advice: Advice that stays general, such as explaining what a requirement means, is different from designing the control, so ask the firm to label its work accordingly.

Before signing, confirm with the firm and the assessor how the two teams are separated and who will sign the Report on Compliance.

How separating consulting and assessment teams works in practice

Independence in PCI DSS attaches to the people on the engagement, not only to the firm name. A QSA employee who recommends, designs or implements controls for an entity may not assess those same controls. Another QSA employee at the firm who was not involved in that design work may perform the assessment. The practical question for you is therefore not whether the firm does consulting, but whether the individuals who will sign off on your Report on Compliance had no hand in building the controls they are testing.

Ask the firm how it records which staff did which work. A workable answer names the separation mechanism in writing: who on the consulting side produced which deliverables, who on the assessment side is assigned, and how the firm confirms that the assessor had no design role. Ask to see how the team roster is kept and how a conflict is raised and resolved if a consultant is later needed on the assessment team. Also ask whether the same person may hold a consulting role for one requirement and an assessment role for another within your environment, since that is the arrangement most likely to cause a problem at review.

Confirm the arrangement with the QSA in writing before any work starts, including which named individuals will act in each role and what happens if staffing changes mid-engagement. If you plan to use your implementation partner for design work, the same question applies to that partner's relationship with the assessor. The QSA is the party the payment brands and acquirers will rely on, so an independence gap discovered after the ROC is issued is your problem to resolve, not only the firm's. Check the current QSA qualification details against the PCI SSC list of Qualified Security Assessors before you agree the scope.

How a QSA can help with an SAQ without losing its role

This sequence sets the QSA's role in writing before any SAQ work begins, so that the QSA's involvement, any Internal Security Assessor involvement and the final Attestation of Compliance all agree with each other. The result is an SAQ that records who did what.

Confirm the SAQ is the right document
Your team confirms with the payment brand or acquirer which SAQ type applies to your environment and whether your organization is eligible for it. A QSA can advise on eligibility, but you own the choice of questionnaire. The output is a short written note naming the SAQ type and the validation requirement you are working toward.
Agree the QSA's role in writing
Before any work starts, your compliance lead and the QSA's engagement manager define what the QSA will do, such as explaining requirements, reviewing draft answers or pointing to gaps. They also agree what the QSA will not do, including designing or implementing controls that the same QSA later assesses. The PCI SSC sets no specific reporting rules for this, so the parties must agree them. The output is a signed role letter.
Check the independence limits against the role
Compare the agreed role letter with the independence rule for QSAs. If the QSA recommends, designs or implements a control, a different QSA at the firm who was not involved must assess that control. Your team records this check in the engagement file. The output is a documented decision on which QSA, if any, will later review each control area.
Complete the SAQ with the QSA's input
Your internal team drafts the SAQ answers and evidence references, and the QSA reviews the draft within the agreed role. Your team keeps ownership of every answer and of the evidence behind it. The QSA's review comments and your responses are kept in your records so the reasoning for each answer can be traced. The output is a reviewed draft SAQ.
Record the QSA's involvement in Part 3c
The QSA completes Part 3c of the SAQ to state its role and the extent of its involvement. The entry should match the signed role letter word for word in substance, so an assessor or your acquirer can see the same account in both places. The output is a completed Part 3c entry that the QSA has reviewed.
Record any Internal Security Assessor involvement in Part 3d
If an Internal Security Assessor helped with the SAQ, that person records the involvement in Part 3d. If no ISA was involved, your team should confirm that this is accurate rather than leave the section unchecked by default. The output is a completed Part 3d entry consistent with the Part 3c entry and the role letter.
Sign and file the Attestation of Compliance
An authorized officer of your organization reviews the completed SAQ and signs the Attestation of Compliance, which states the validation status. The signatory should confirm the answers rest on evidence your team holds, not on the QSA's assurance alone. The output is a signed AOC filed with the SAQ and the role letter, ready to send to the entity that requested validation.

Using evidence from SOC 2 and other auditors in a ROC

A QSA can draw on evidence that another auditor collected, but the ROC stays the QSA's responsibility from start to finish. The cards below separate what the QSA may reuse, what the QSA must verify independently, and what the organization should settle in writing before any evidence crosses from one audit to another.

SOC 2 reports are not enough alone

A QSA cannot rely on a SOC 2 or SOC 3 report by itself to validate a PCI DSS requirement. The report is an input, not a finding. Before the assessment starts, confirm with the QSA that the report is treated as supporting material and that the QSA will still test each PCI requirement it relies on. Ask for this position in writing so nobody discovers it during fieldwork.

Verify scope before reuse

A QSA may use SOC 2 evidence only after independently confirming four things: the systems in scope, how SOC 2 criteria map to PCI requirements, the period the evidence covers, and that the controls were operating. A SOC 2 system description that excludes the cardholder data environment gives the QSA nothing to reuse for those systems, even when the report is clean.

Map criteria to requirements in writing

Before reuse, produce a written mapping from each SOC 2 criterion the team wants to rely on to the PCI DSS requirement it supports. Note gaps where a SOC 2 control is broader or narrower than the PCI requirement, such as log retention or access review frequency. A mapping that exists only in someone's head will not survive a QSA's review.

Check timing and period coverage

SOC 2 reports cover a defined period, and PCI DSS testing covers its own window. Where the periods do not line up, the QSA will need additional evidence for the gap. Check the report period against the assessment period early, and plan to collect bridging evidence for any months the report does not cover.

Another auditor may collect evidence

A SOC 2 auditor at the same firm can collect evidence for the ROC, but the QSA conducting the assessment keeps ultimate responsibility for the ROC and its workpapers. Ask which individual will sign off on reused evidence, and confirm that the QSA reviews the underlying samples rather than accepting a summary. Responsibility does not move to the collecting auditor because the work happened in the same firm.

Agree sampling approach with the QSA

Evidence collected for another audit may use a different sample size or selection method from the one the QSA needs for PCI DSS. Confirm the sampling approach before collection starts, including population definition, sample size and the period sampled. Samples drawn to a different standard can leave gaps the QSA will need to fill with new testing.

Who keeps responsibility for the ROC and its workpapers

The QSA that conducts the assessment keeps ultimate responsibility for the Report on Compliance and its workpapers, even when another auditor at the same firm, such as a SOC 2 auditor, gathers some of the evidence. That responsibility does not move to the auditor who collected the evidence, and it does not move to the consultant who helped build the controls. For you, this means the ROC is only as sound as the QSA's own testing, so ask early which people at the firm will sign the ROC and confirm they are independent of any design or build work done for you (see PCI SSC FAQ 1566 on evidence collected by other auditors).

Responsibility for the controls stays with your organization. Your team owns the controls, runs them day to day, and signs the Attestation of Compliance that accompanies the ROC or SAQ. An implementation partner or consultant can prepare systems, configurations, policies and evidence, but it does not issue the ROC, an AOC or any certificate. PCI SSC FAQ 1220 is explicit that certificates are not recognized as validation, so any document that looks like a PCI certificate from a consultant should be treated as having no validation value. Confirm in writing which deliverables the consultant will produce and which will come from the QSA.

Decide, before work starts, where the ROC and its supporting material will be held. PCI SSC FAQ 1014 notes that ROCs and scan results are not sent to the PCI SSC by default, so the copies you rely on are the ones you keep. Store the signed ROC, the AOC, scan reports and the evidence index in a location your acquirer or payment brand can request, and agree with your QSA who receives the signed copies. Confirm with your acquirer which format and retention period it expects, because those requirements come from the acquirer or brand rather than from the PCI SSC.

Where QSA judgment stays with the assessor, not the consultant

A consultant can help design the controls, compensating controls and customized approach documentation that an entity relies on. The QSA then decides whether those choices meet the intent of each requirement. The four cards below mark where that line sits and what each side should hold.

No pre-approved configurations

The PCI SSC does not approve specific configurations or compensating controls in advance. Nobody outside the assessment can certify a design as acceptable before the assessor looks at it, so a consultant's recommendation carries no validation weight. Ask the consultant to show you the requirement intent behind each design choice, and keep that reasoning in the evidence folder so the assessor can review it.

QSA decides intent

The QSA, trained by the PCI SSC on the intent of each requirement, decides during the assessment whether a compensating control meets that intent. This judgment belongs to the assessor, not to the firm that designed the control. Plan for the QSA to ask how the control works, how it was tested and who reviews it, and make sure your team can answer those questions without the consultant in the room.

Design allowed, judgment not

A consultant may draft a compensating control, but the same firm cannot then be the one judging whether it works. If a QSA employee designed or implemented a control, a different QSA employee who was not involved must assess it. Confirm in writing which people on the consulting side are walled off from the assessment team, and ask your assessor how it will handle any control the firm helped build.

Customized approach records

Under the customized approach, the entity meets a stated objective in its own way, which makes the documentation the test. The entity owns the targeted risk analysis, the control design and the evidence showing the objective is met, and the QSA tests all three. Ask that the consultant write this documentation as the entity's own record, not as a sales deliverable, so the assessor can trace each decision back to the entity.

How an implementation partner fits alongside an independent QSA

DeployOpen can prepare the systems and evidence, but it cannot issue the Report on Compliance, the Attestation of Compliance or any certificate. Those documents come only from an independent assessor. DeployOpen's role is to plan, implement, document and harden self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks, then hand over configurations, logs, records and runbooks that your QSA can examine. Your organization keeps ownership of every control. If DeployOpen helps design a control, the QSA reviewing that control must come from a different part of the assessing firm, and the QSA must not have recommended or built it.

Practically, agree the division of work in writing before implementation starts. The written scope should name which controls DeployOpen builds, which evidence it produces, and which steps belong to your team or the QSA. Ask your QSA to confirm in advance whether it will accept the proposed evidence design, since the assessor decides whether an implementation meets the intent of a requirement. Ask DeployOpen to show, for each control, where the evidence is stored, who can read it and how an assessor would reproduce the result. Confirm with your QSA the sampling and timing expectations for the evidence period before any build is signed off.

Keep the records that show who did what. Your internal team should retain the change tickets, approval records and handover documents for each implemented control, so that the independent assessor can trace a configuration back to a decision made by your organization. Treat implementation support as an input to the assessment, not a substitute for it. Any work that DeployOpen performs as part of testing, such as security testing of the same systems, should be scoped separately so that it does not blur the line between the party that builds a control and the party that assesses it.

Questions buyers ask about QSA independence

Can the same firm build our PCI controls and also assess them?

Not with the same people. A QSA employee who recommends, designs or implements controls for an entity may not assess those controls. A different QSA employee at the firm who was not involved in the design work may perform the assessment, so the firm can sometimes serve both roles, but only through separated teams. Ask the firm to describe, in writing, which people worked on the design and which people will assess, and how they keep those roles apart. Your own team still owns the controls, so the design work does not transfer assessment responsibility to the firm. Confirm the separation against the QSA Qualification Requirements before you sign.

Does the QSA independence rule apply when we complete an SAQ?

The independence rule is the same concern, but the SSC sets no specific reporting rules for QSAs who help merchants complete a Self-Assessment Questionnaire. In practice, agree the QSA's role before the work starts. The QSA records that role in Part 3c of the SAQ, and an Internal Security Assessor records any involvement in Part 3d. If the same QSA helped implement a control and then reviews the answer to it, expect the reviewer to question the result. Ask the firm to state exactly what it will do, what it will not do, and how it will document both.

Who is responsible if our SOC 2 auditor collected the evidence?

The QSA conducting the PCI DSS assessment keeps ultimate responsibility for the Report on Compliance and its workpapers, even when another auditor at the same firm, such as a SOC 2 team, collected the evidence. A QSA cannot rely on a SOC 2 or SOC 3 report as validation. It can use that evidence after independently confirming the scope, the mapping to PCI DSS requirements, the timing, and that the controls were in place. Expect the QSA to retest or sample the items that matter for PCI DSS. Your organization should ask which person signs the ROC and who answers for the workpapers.

Can we use our own internal security assessor instead of an outside QSA?

An Internal Security Assessor can help prepare and assist with a PCI DSS assessment, but the ROC must be completed by a QSA from a QSA company. Your ISA's role is recorded in Part 3d of an SAQ or in the assessment documentation, and it should not be confused with the independent assessment itself. Confirm the ISA's qualification and the scope of their role with the PCI SSC listings. Also check whether any internal person who built a control is reviewing it, because that raises the same independence question that applies to outside firms.

Will switching QSA firms reset all of our assessment work?

Switching firms does not automatically erase prior work, but the new QSA must reach its own conclusions. A new QSA will normally need to confirm the scope, review the current controls and examine evidence rather than accept a previous report at face value. Keep your network diagrams, data-flow records, policies, prior workpapers and evidence in a organized repository so a new assessor can verify them quickly. Ask the new firm, before engagement, how it will treat prior assessment results and what it needs from you to start.

What should we ask a QSA firm to confirm in writing?

Ask for a written statement covering four points. First, the names and roles of anyone who designed or implemented controls and of anyone who will assess them, with confirmation they are separate. Second, the QSA's role in any SAQ, recorded for Part 3c. Third, which firm staff, including any SOC 2 or other auditors, will collect evidence, and who holds responsibility for the ROC and workpapers. Fourth, how prior assessments and evidence will be treated. Include these points in the statement of work so they are part of the agreed scope, and confirm the firm's QSA status on the PCI SSC list before you sign.

Does DeployOpen assess our PCI DSS controls?

No. DeployOpen plans, implements, hardens, documents and prepares evidence for self-hosted open-source platforms inside your own infrastructure. It does not issue Reports on Compliance, Attestations of Compliance or certificates. Those are issued only by an independent QSA or another qualified assessor. Because DeployOpen helps build the controls, it would not be the party that assesses the same controls. Most engagements are fixed-scope and agreed in writing before work starts, so the separation of design and assessment should be settled in that scope document. Confirm the assessor and its independence with your QSA before the work begins.

How DeployOpen prepares your systems and evidence for an independent assessor

DeployOpen prepares systems, controls and evidence so your independent assessor can test them. We do not issue reports or attestations, and the assessor makes the final call on scope and findings. Our work stays on the preparation side of the line, so the firm that assesses you is never the firm that built what it tests.

How we scope

Each engagement starts with a written scope that names the systems, networks and third parties in the environment.
We confirm with you which assessor is engaged so scope decisions are agreed before any build work begins.
Engagements are fixed-scope, with deliverables and timelines agreed in writing before work starts.

How we build

We implement and harden open-source platforms inside your own infrastructure, mapped to the requirements in scope.
We document each control as built, so the assessor can trace design, configuration and operation separately.
Where a DeployOpen engineer advised on a design, we record that advice so the assessor can judge its independence.

How we hand over

You receive configuration records, system diagrams and evidence packs that the assessor can sample directly.
Ownership of every control, policy and evidence artifact transfers to your team at handover.
Confirm with your assessor in advance which evidence formats and sampling approach they accept.

How we support

Ongoing support, upgrades and continuous testing are available as retainers after handover.
Retainer work can keep evidence current between assessment cycles, which your team still reviews and owns.
Ask your QSA firm to confirm, before work starts, which DeployOpen activities they will treat as consulting.

Can your QSA also be your PCI consultant: independence rules