What Does a Qualified Security Assessor (QSA) Do?

This article explains the role of a Qualified Security Assessor (QSA) in the PCI DSS assessment process and clarifies what organizations should expect during a formal compliance validation. It explores how QSAs evaluate PCI DSS scope, review security controls, assess evidence, conduct interviews, observe operational processes, and prepare assessment deliverables such as Reports on Compliance (ROCs). Designed for merchants, service providers, compliance teams, security leaders, and organizations preparing for PCI DSS assessments, the article also highlights the important distinction between the responsibilities of the QSA and the organization's ongoing ownership of its compliance program, controls, and remediation activities.

By Tom Rozen

Published October 15, 2026

PCI DSS compliance is not demonstrated by having the right policies on paper. When formal third-party validation is required, the organization must show that its payment environment is scoped correctly, implements applicable controls, and that the available evidence supports that conclusion.

That is where a Qualified Security Assessor (QSA) comes in.

A QSA validates the scope of a PCI DSS assessment, evaluates applicable security controls, reviews evidence, interviews personnel, observes processes, documents findings, and prepares formal assessment outputs such as a Report on Compliance (ROC) where required.

The QSA does not own the organization's compliance program. The organization still owns its systems, controls, remediation, and ongoing PCI DSS compliance. Understanding that division of responsibility is important before an assessment begins.

» See how our QSAs can help you reach PCI DSS compliance

What is a Qualified Security Assessor (QSA)?

A Qualified Security Assessor is an individual qualified under the PCI Security Standards Council (PCI SSC) QSA program to perform PCI DSS assessments through a qualified QSA Company.

That structure has two parts. PCI SSC defines QSA Companies as independent security organizations qualified to validate an entity's adherence to PCI DSS. QSA Employees are individuals employed by a QSA Company who have satisfied, and continue to satisfy, the applicable QSA requirements.

That distinction matters. QSA status is not simply a personal security credential that someone can use independently of an approved assessment organization.

QSA Company vs. QSA Employee

The QSA Company operates under PCI SSC's QSA program. It is responsible for requirements such as independence, quality assurance, and managing its assessors. The individual QSA Employee performs or assists with PCI DSS assessment work on the company's behalf.

For an organization undergoing formal validation, both levels matter. You are not simply hiring someone who understands PCI DSS. You are engaging an assessor operating within PCI SSC's qualification and quality-management structure.

A QSA also serves a different purpose from your internal security or compliance personnel. Your teams design, implement, operate, and maintain controls. The assessor evaluates whether the controls and supporting evidence satisfy the applicable PCI DSS requirements.

Nor is a QSA a regulator. PCI SSC develops and maintains standards and qualification programs, while organizations such as payment brands and acquirers manage compliance programs and determine how their merchants or service providers must validate compliance.

Qualifications and professional independence

PCI SSC's QSA program requires more than completing a short training course. QSA Employees must meet applicable professional qualification requirements, complete PCI SSC training and examinations, work through a QSA Company, and maintain their qualification through the program's requalification process.

That qualification model supports one of the most important parts of the role: independent professional judgment.

A QSA must look beyond what an organization says a control does and determine whether the evidence supports that claim. That requires knowledge of PCI DSS, audit methodology, and the technologies being assessed.

Core responsibilities of a QSA in a PCI DSS assessment

A QSA does considerably more than collect documents and work through a checklist.

The assessor must understand the environment, validate the assessment scope, evaluate evidence against applicable PCI DSS testing procedures, identify requirements that cannot yet be supported as being in place, and accurately document the resulting assessment.

Validate the Cardholder Data Environment and PCI DSS scope

Accurate scope is the foundation of a PCI DSS assessment.

The organization is responsible for identifying and documenting what falls within its PCI DSS environment. The QSA then validates whether the scope and the applicability of requirements have been defined correctly. PCI SSC specifically assigns assessors responsibility for validating assessment scope and the applicability of PCI DSS requirements.

That means understanding how payment account data moves through the business and examining the systems, people, processes, connections, and third-party relationships that can affect the security of the Cardholder Data Environment (CDE).

For example, an organization may believe that a system is out of scope because it does not directly store cardholder data. The assessor still needs to consider whether that system connects to, provides security services for, or can otherwise affect the CDE.

The QSA also tests assumptions behind segmentation and other scoping decisions. A system cannot simply be declared out of scope because including it would make the assessment harder.

Good scoping works in both directions. It prevents relevant systems from being excluded, but it can also prevent unnecessary assessment work when systems are genuinely isolated from the CDE.

Test controls and validate evidence

Once scope is established, the QSA evaluates whether applicable PCI DSS requirements are satisfied.

That involves more than reading policies. Depending on the requirement, assessment procedures can involve reviewing configurations and documentation, interviewing personnel, observing processes, and examining operational evidence such as logs, records, access reviews, change records, scan results, or other technical artifacts.

The key question is not simply, "Do you have this control?"

It is, "Can you demonstrate that this control is implemented as required?"

Evidence must also be fit for purpose. PCI SSC makes clear that even when another auditor collects evidence, the QSA conducting the PCI DSS assessment remains responsible for determining whether that evidence is specific to the assessment scope, directly relevant to the requirement, within the appropriate timeframe, and sufficient to support an assessment conclusion.

The same principle applies when evidence already exists from another assurance activity. A SOC 2 report, for example, cannot simply substitute for PCI DSS testing. Relevant underlying evidence may sometimes be reused, but the QSA must independently determine whether it supports the applicable PCI DSS requirement.

This distinction matters for organizations already managing several frameworks: evidence reuse can reduce duplicated work, but control overlap does not remove the QSA's responsibility to validate PCI DSS independently.

Assess findings and follow-up evidence

If the evidence does not support a requirement, the QSA documents what is missing or insufficient.

Sometimes the issue is an evidence gap: the control may exist, but the organization cannot provide adequate proof. In other cases, testing identifies a control that is not implemented or operating as required.

The organization remains responsible for addressing the problem.

Where the engagement and applicable reporting process allow time for remediation, the organization can implement corrective action and provide updated evidence. The QSA then evaluates that evidence or retests the affected control as appropriate before concluding.

The QSA's role here is to clearly explain why a requirement cannot yet be supported and what needs to be validated, not to quietly change the assessment conclusion to keep the project moving.

Document the assessment in the ROC and AOC

For assessments documented through a Report on Compliance, the QSA Company records the scope, testing performed, evidence considered, findings, and conclusions in the ROC.

The report therefore needs to do more than state that a requirement passed. It needs to provide enough information to support the assessor's conclusions.

The associated Attestation of Compliance (AOC) also has defined responsibilities. For ROC-based assessments, PCI SSC's current process includes an attestation from an executive officer of the assessed merchant or service provider and a QSA acknowledgement signed by a duly authorized officer of the QSA Company. The AOC is not simply the individual assessor's unilateral "certification" of the company.

That terminology matters because PCI SSC does not recognize generic "PCI DSS compliance certificates" as official validation documentation. Official forms include the ROC, AOC, and applicable SAQs.

How does a QSA conduct a PCI DSS assessment from start to finish?

A QSA-led assessment typically progresses from scope confirmation and planning into active validation, evidence review, findings and follow-up, and final reporting.

Organizations may also conduct gap assessments or other readiness work before formal testing begins. These activities can make the formal assessment more predictable, but they should not be confused with mandatory stages defined by PCI SSC.

Scope confirmation and assessment planning

The priority is understanding what is actually being assessed.

The QSA needs a clear picture of the payment environment, including relevant data flows, infrastructure, applications, network connections, third parties, locations, security services, and control owners.

At this point, the assessor can challenge scope assumptions before they create larger problems later in the project.

Assessment planning also establishes how testing will be performed. This may involve identifying evidence owners, arranging interviews, determining which systems or locations to examine, and deciding where representative sampling is appropriate.

The better the organization understands its own environment at this stage, the less time everyone spends untangling scope during detailed testing.

Active control validation

The assessment then moves into evidence-based testing. The QSA evaluates applicable requirements using the relevant PCI DSS testing procedures. Depending on the control, that can mean:

Examining policies, procedures, configurations, and records;
Interviewing personnel responsible for operating controls;
Observing processes or security mechanisms;
Reviewing technical outputs and system behavior; and
Evaluating evidence from required security activities, such as scans or penetration testing where applicable.

Some assessment work can be performed remotely, but PCI SSC still treats on-site testing as the expected approach. Its guidance states that on-site presence is part of QSA assessment responsibilities and that on-site testing should be the norm, while recognizing that not every validation activity requires physical presence. Remote assessment methods may be appropriate in legitimate circumstances, subject to applicable requirements from the compliance-accepting entity.

The practical point is that a PCI DSS assessment should not be assumed to be a document exchange conducted entirely by email.

Evidence review and sampling

A QSA does not necessarily examine every possible instance of every control.

PCI DSS permits sampling in appropriate circumstances, but the assessor needs enough representative evidence to support the conclusion being reached. The sample must make sense in the context of the population, environment, control, and testing procedure.

This is another area where assessor judgment matters.

For example, reviewing one administrative account does not necessarily tell the assessor how privileged access is managed across several technology platforms. Likewise, one security-awareness record may not demonstrate that the required process applies consistently across the workforce.

Evidence also needs traceability. The assessor should be able to connect what was examined to the requirement being tested and explain why it supports the resulting conclusion.

Findings, remediation, and follow-up validation

Testing may expose incomplete evidence, incorrect scope assumptions, or controls that do not satisfy the applicable requirement.

A well-run assessment surfaces these issues clearly rather than waiting until final reporting.

The organization can then address the gap. That might mean correcting a configuration, updating a process, producing missing evidence, or implementing a control that was not operating as expected.

The QSA then validates the new state.

The distinction matters: the organization fixes the problem; the assessor determines whether the fix can now be supported as compliant.

This is one reason preparation matters. Finding a major scoping or control issue during formal testing is much more disruptive than discovering it during readiness work.

Final reporting and attestation

Once testing and any permitted follow-up validation are complete, the QSA Company finalizes the assessment documentation.

For a ROC-based assessment, PCI SSC considers the Date of Report the assessment completion date. It represents the point at which the QSA Company and assessed entity agree on the final ROC.

The associated AOC then records the appropriate entity attestation and QSA Company acknowledgement.

Where the resulting documentation goes depends on the applicable compliance program. QSAs do not send ROCs directly to PCI SSC. PCI SSC instructs QSAs to follow the relevant payment-brand-specific procedures.

» Learn how a thorough PCI DSS gap assessment can identify compliance gaps and reduce security risk.

Where does the QSA's responsibility end?

The organization remains responsible for PCI DSS compliance.

A QSA independently evaluates the environment and documents the assessment. The assessor does not take over ownership of security controls, remediation, or ongoing compliance.

This responsibility model also includes a third party: the compliance-accepting entity. PCI SSC explains that organizations such as payment brands and acquirers determine the PCI DSS validation and reporting method that their merchants and service providers must follow; for example, whether compliance must be documented through a ROC or an SAQ.

A useful way to separate those roles is:

Activity	Primary responsibility
Define and document the initial PCI DSS scope	Assessed organization
Validate scope and applicability	QSA
Implement and operate security controls	Assessed organization
Provide assessment evidence	Assessed organization
Determine whether evidence supports a conclusion	QSA
Assess applicable PCI DSS requirements	QSA
Address control or evidence gaps	Assessed organization
Validate remediated controls	QSA
Determine the required validation/reporting method	Applicable acquirer, payment brand, or other compliance-accepting entity
Prepare the ROC where applicable	QSA/QSA Company
Complete applicable AOC attestation and acknowledgement	Assessed entity and QSA Company, according to the form
Maintain PCI DSS compliance	Assessed organization

This division of responsibility matters operationally. Your engineering team cannot hand responsibility for control operation to the assessor. Likewise, the QSA should not accept unsupported conclusions simply because the organization believes a control is working.

Can a QSA help with remediation and still remain independent?

Yes, but independence rules set clear boundaries for what each party can do.

A QSA can explain requirements, discuss findings, and help an organization understand why the available evidence does not support a requirement. QSA Companies may also provide advisory or implementation-related services.

However, PCI SSC requires separation of duties. If a QSA Employee recommends, designs, develops, provides, or implements a specific control, that same individual cannot then assess that control or the requirements affected by it. Another QSA not involved in that work may assess whether the QSA Company has adequate, documented separation of duties.

For the organization, this means two things.

First, you should be able to get useful guidance rather than having an assessor refuse to explain what a finding means.

Second, you should expect the QSA Company to manage advisory and independent assessment responsibilities carefully. The assessor cannot implement a control on your behalf and then independently approve their own work.

Why QSA validation matters beyond completing the ROC

The real value of a QSA assessment isn't creating a report. It is the independent validation behind that report.

A credible assessment should give stakeholders greater confidence that the PCI DSS scope has been challenged, relevant controls have been examined, and evidence rather than assumptions support the conclusions.

That depends heavily on technical understanding.

A cloud-native payment platform, for example, may rely on identity services, APIs, serverless workloads, managed databases, CI/CD pipelines, third-party payment services, and segmented environments. Understanding how those components interact is necessary to determine what can affect the CDE and which evidence actually demonstrates control effectiveness.

This is where a technically shallow assessment creates unnecessary friction. If the assessor does not understand the architecture, teams can spend time explaining normal technology patterns, producing irrelevant evidence, or debating scope that should have been resolved much earlier.

Accurate validation also helps expose gaps between documented procedures and operational reality. A policy may say privileged access is reviewed. The assessment needs evidence that the review actually occurs as required.

The ROC and AOC are therefore outputs of the process, not the security objective.

Systems change. Vendors change. New services are deployed. Access changes. Payment flows evolve. PCI DSS compliance must still be maintained after the assessment.

» Get expert QSA guidance for ROC, AOC, and SAQ requirements, and ensure your PCI DSS compliance is properly documented.

Prepare for a QSA-led PCI DSS assessment with GRSee

Once you understand what the QSA will test, the next question is whether your organization is ready to support that assessment without unnecessary scope, evidence churn, or late surprises.

At GRSee, our PCI DSS work spans readiness, implementation support, formal assessment and ROC reporting, and ongoing compliance support. Our current PCI DSS process also includes scope and descoping work, gap assessment, remediation planning, testing, and audit-readiness review.

The goal is not to turn preparation into another layer of paperwork. It is to make sure the fundamentals are clear before formal validation begins:

Get the scope right. Understand the CDE, payment data flows, dependencies, and opportunities to reduce scope where the architecture genuinely supports it.
Know where the gaps are. Resolve control and evidence problems before they become assessment blockers.
Prepare evidence around how your environment actually works. Modern SaaS, cloud, API, and payment architectures require technical context, not generic templates.
Maintain clear separation of duties. When we support implementation or remediation, assessment independence must be preserved.
Plan beyond the report. PCI DSS controls must still operate after the ROC and AOC are complete.

» If you need to confirm your validation path, review your CDE scope, or prepare for a QSA-led assessment, our PCI DSS Level 1 and ROC assessment services provide a practical place to start.