QSA vs ASV vs ISA in PCI DSS: who does what

Which PCI DSS QSA role do you need, and who signs the report?

If a card brand, acquirer or customer requires PCI DSS validation, the employee of a QSA company who validates your adherence completes the Report on Compliance (ROC). An Approved Scanning Vendor (ASV) runs the external vulnerability scans that Requirement 11.3.2 calls for, and an Internal Security Assessor (ISA) is one of your own employees, trained and sponsored to run internal assessments. None of these roles takes over ownership of your controls. Your organization stays accountable for every control, whether or not a partner helped build it. A useful way to split the work is to separate preparation from validation. An implementation partner can prepare systems, write procedures and assemble evidence, but it does not issue the validation. Only the QSA issues the ROC for a Level 1 style assessment, and for smaller entities the validation is the Self-Assessment Questionnaire with its Attestation of Compliance (AOC) signed by your authorized officer. Confirm with your acquirer or the relevant payment brand which validation type and which level apply to you, since the PCI SSC does not enforce compliance or set those obligations.

Before you engage anyone, ask the requiring party three questions: which validation type do they accept, does the ROC or AOC need to be signed by a QSA company, and do they expect an ASV scan report for the external scan. Then check the assessor's status on the PCI SSC QSA list, filtering by region and language, and confirm the company is listed at the time you sign. The PCI SSC QSA listing is the natural starting point. Keep the ROC, AOC and scan reports together, because the requiring party will ask for them, not the PCI SSC.

What a QSA, an ASV and an ISA each may do

PCI DSS assigns different assessment work to different qualified roles. The cards below separate who validates the standard, who scans externally, who tests internally, and which document each role supports, so you can match each piece of evidence to the right party.

QSA company and QSA employees

A QSA company is an independent security organization qualified by the PCI SSC to validate adherence to PCI DSS, and its QSA employees are the individuals who meet and keep meeting the qualification requirements. Only a QSA company can complete a Report on Compliance for a Level 1 assessment or a validation that requires a ROC. Before you sign, check the PCI SSC QSA list for the firm and confirm the individual assessors are listed.

The ROC and its attestation

The Report on Compliance is the detailed assessment document a QSA completes, and it is paired with an Attestation of Compliance that summarizes the result. The organization owns its controls and the AOC, while the QSA signs the ROC on its own judgment. Certificates or logos from any party are not accepted as validation, so ask for the signed ROC and AOC rather than a badge.

ASV external scans for Requirement 11.3.2

An Approved Scanning Vendor runs the external vulnerability scans that validate Requirement 11.3.2, using an ASV scan solution the PCI SSC has approved. ASVs are re-approved every year. An ASV scan report covers that one requirement only and is not evidence that any other requirement is met, and the PCI SSC does not endorse supplemental letters from ASVs. Confirm the vendor is on the ASV list before buying scans.

ISA sponsorship and experience

The Internal Security Assessor program trains your own staff to perform internal PCI DSS assessments, recommend remediation and act as liaison with the external QSA. Candidates must be sponsored by their employer, and the PCI SSC recommends at least five years of relevant audit or security experience. An ISA does not replace the QSA's independent assessment and cannot issue the ROC as a QSA would, so confirm the ISA's status on the PCI SSC list before relying on them.

Internal testers under Requirements 11.4.2 and 11.4.3

Penetration testing and internal vulnerability scanning under Requirement 11.3.1 can be performed by qualified internal staff or a qualified external third party. The testers must be organizationally independent from the systems they test, and they do not need to be a QSA or ASV. Document their qualifications and reporting lines, because the QSA will ask how independence was established.

Who may run internal scans and penetration tests?

Requirement 11.3.1 asks for internal vulnerability scans at least once every three months, with high-risk and critical findings resolved and then confirmed by rescans. The standard does not require a QSA or an ASV to run these scans. The scanner operator must be a qualified person who is organizationally independent of the system being scanned, which can be your own staff or a qualified external firm. Your team owns the schedule, the scope and the remediation tracking, and the assessor will sample the scan reports and rescan evidence.

Who may run them: Qualified internal staff or a qualified external third party, provided they are independent of the systems they scan.
Cadence: At least once every three months, with the scan set and results kept as evidence for each quarter.
Remediation: High-risk and critical vulnerabilities must be resolved, and a rescan must show that they are closed.
Scope: Cover the systems in the cardholder data environment and the connected systems that could affect it.
Tool choice: An open-source scanner can satisfy the requirement if your team can produce consistent, dated reports.

Confirm in writing who runs each scan, how their independence is established, and where the reports are stored before the first quarter begins.

How to check an assessor's listing before you sign

This sequence confirms that the QSA company, ASV or ISA sponsor you plan to use holds a current PCI SSC qualification, and it leaves a dated record that procurement can file with the engagement.

Confirm the QSA company is listed
Procurement or the compliance lead opens the PCI SSC QSA list and searches for the exact legal name of the QSA company, not a brand or regional trading name. The company must appear as a QSA company on the list. If the name differs from the contract, ask the firm to explain the legal relationship before going further. The output is a saved copy or screenshot of the listing entry, dated and filed with the draft engagement letter.
Filter the listing for your location and language
Use the list's filters for place of business, region and language to confirm the firm is qualified to work in the country or region where your cardholder data environment and staff sit. Ask the firm to name the individual QSA employees who will sign the Report on Compliance, then check the firm's listing and your own records against that list. The output is a note recording the filters used and the names of the proposed QSA employees.
Repeat the QSA check at every engagement
Run the same search again each time you engage the QSA company, including renewals, scope changes and follow-up assessments, because a company's status must be maintained and is not fixed once it is hired. Compare the new result with the previous dated record. The output is a new dated entry in your assessor file, and any change in status goes to the risk owner before work starts.
Verify the ASV listing and annual approval
If an Approved Scanning Vendor will run your external vulnerability scans, search the PCI SSC ASV list for the exact company name and confirm the company is listed as an approved scanning vendor. Because ASV approval is renewed every year, record the listing date and confirm with the vendor that the scan solution named in the contract is the one approved. The output is a dated ASV listing record that you can match against the scan reports.
Confirm employer sponsorship for each ISA
For each Internal Security Assessor on your team, ask for evidence that the individual completed the PCI SSC ISA program through your organization and that the employer sponsorship is current. The ISA credential is tied to the sponsoring company, so confirm the individual still works for that employer and is the same person named in the program records. The output is a signed statement from HR or the compliance lead, filed with the ISA certificate, that states the sponsorship and the date it was checked.
File the dated records for procurement
Combine the QSA listing record, the ASV listing record and each ISA sponsorship statement into one assessor file with the date each check was made and the name of the person who made it. Include a line confirming that the individuals named in the QSA or ISA roles match the people who will do the work. The output is a single assessor verification record that procurement can reference when the contract is signed and when the next engagement is renewed.

Which assessor fits which validation path?

This table compares five ways PCI DSS work gets done, from a QSA-led ROC to an independent internal tester, and shows what each produces, who may perform it and when it fits. Read it by first confirming your validation level and SAQ eligibility with your payment brand, then matching the row that covers your path.

Path	What it produces and who may perform it	When it fits
QSA-led ROC	A Report on Compliance and Attestation of Compliance, completed by a Qualified Security Assessor from a QSA company listed by the PCI SSC	Entities that the payment brand requires to validate with a ROC, typically the highest validation levels; confirm your level with the brand, for example on Visa's compliance validation page
SAQ completed with or without QSA help	A Self-Assessment Questionnaire and Attestation of Compliance, signed by the entity; the entity answers, and a QSA may advise but the SAQ is not a QSA-issued report	Entities whose payment channel and architecture match an SAQ type they are eligible for; the SAQ type is set by the payment brand, not chosen by preference
ASV external scan	Quarterly external vulnerability scan reports for Requirement 11.3.2, performed by an Approved Scanning Vendor using an approved scan solution	Any entity where external scanning applies; an ASV report alone does not show that other requirements are met
Internal ISA-led assessment with QSA liaison	Internal assessment work performed by an Internal Security Assessor employed by the sponsoring company, with the QSA acting as the external assessor of record where a ROC applies	Organizations with a qualified ISA on staff that want internal capacity while keeping external validation; confirm with the QSA and payment brand whether this suits your level
Independent internal tester	Internal vulnerability scan and penetration test evidence from qualified, organizationally independent testers, who need not be a QSA or ASV	Covers Requirements 11.3.1, 11.4.2 and 11.4.3; suits teams that run internal scans and tests themselves, with independence from the people who manage the systems tested

Where the QSA's independence limits what it can also do

The firm that validates your PCI DSS controls generally cannot also design or build them. PCI SSC FAQ 1562 addresses QSA independence, and the practical consequence is that a QSA company that helps build the controls it later assesses puts its own independence at risk. Before you engage a QSA, ask any firm you are considering to state in writing which of its teams would work on consulting and which would perform the assessment, and whether the same people would do both for your organization.

Internal Security Assessors sit on the other side of the line. An ISA is an employee of your organization, trained and sponsored by your company, who performs internal assessment work, recommends remediation and acts as liaison with the external QSA. An ISA does not replace the QSA, and the ISA's role does not make your internal team independent of the controls it runs. Confirm the individual's current ISA status through the PCI SSC program page before you rely on them for internal assessment work.

Keep the Report on Compliance in mind when planning who sees what. Under PCI SSC FAQ 1014, a ROC and its scan results are not sent to the PCI SSC by default, so the evidence trail between you and your QSA is the record that matters. Ask your QSA how it will document its independence for your engagement, and read the sibling topic on QSA independence before deciding how to split consulting and assessment work between firms.

Mistakes that delay validation or invalidate evidence

Most delays in PCI DSS validation come from a small set of misunderstandings about who may perform each activity and what documents count as proof. The cards below cover the errors that assessors most often find, and the checks that prevent them before the assessment window opens.

Using an ASV report as proof of other requirements

An ASV scan report only shows the result of an external vulnerability scan against Requirement 11.3.2. It does not show that firewalls, access controls, encryption, logging or policies are in place. Teams that hand an ASV report to an assessor as evidence for unrelated requirements usually discover the gap late, when the QSA asks for the actual evidence. Check each requirement against its own testing procedure and collect evidence for it separately.

Accepting a certificate instead of an AOC

A certificate or letter saying an organization is compliant is not validation under PCI DSS. Validation rests on a completed Report on Compliance from a QSA, or a Self-Assessment Questionnaire, each with an Attestation of Compliance. Before a partner or acquirer accepts a document, confirm it is the correct template and is signed by the assessor or the entity as required.

Engaging a QSA whose status has lapsed

QSA companies and employees must keep meeting qualification requirements, and the PCI SSC publishes a QSA list you can filter by region, place of business and language. A firm listed last year may no longer be qualified. Check the listing at the start of each engagement and record the date, because a report signed by a lapsed assessor can be rejected and the work repeated.

Assuming internal testers must be QSAs or ASVs

Internal vulnerability scans required by Requirement 11.3.1 do not need a QSA or ASV to run them. Penetration testers under Requirements 11.4.2 and 11.4.3 may be qualified internal staff or an external third party, but they must be organizationally independent of the system they test. Teams that delay internal testing while waiting for a certified vendor lose time, and teams that let the system owner test their own work lose the independence assessors look for.

Relying on another auditor's SOC 2 report unchecked

A SOC 2 report can support parts of a PCI DSS assessment only when its scope covers the same systems, services and time period as the payment environment. The PCI SSC explains in FAQ 1567 that an assessor must still decide how far such a report can be used. Before accepting one, compare the in-scope systems, the carve-out services and the testing period against your cardholder data environment, and confirm the assessor agrees with the reliance.

Missing rescans after remediation

When a scan finds a failing vulnerability, the fix must be followed by a rescan that shows it resolved. An ASV validates a scan only when the result passes, and the PCI SSC expects four passing quarterly scans to be documented in a validation cycle. Teams that patch and move on without rescanning, or that let a failed scan go unresolved past the quarter, leave assessors with gaps in the evidence trail. Ask your ASV for the rescan schedule when you book the quarterly scans.

Common questions about PCI DSS assessors and roles

Can an Internal Security Assessor replace a QSA for our PCI DSS validation?

No. An Internal Security Assessor (ISA) is a member of your own staff, trained by the PCI SSC to perform internal PCI DSS assessments, recommend remediation and act as the liaison with the external QSA. An ISA can strengthen your internal assessment work and reduce the time your QSA spends on the basics, but the Report on Compliance must be completed by a Qualified Security Assessor from a QSA company. The ISA program is sponsored by your employer, and the SSC recommends at least five years of relevant audit or security experience for candidates. Confirm with your QSA which parts of the assessment they will accept from your ISA team and how they will document that reliance.

Does an ASV scan cover every PCI DSS requirement?

No. An Approved Scanning Vendor performs external vulnerability scans that validate adherence to Requirement 11.3.2, and nothing more. An ASV scan report is not evidence that any other PCI DSS requirement is met, and the SSC does not endorse supplemental certificates or letters from ASVs. Your external scans must still be run quarterly by an ASV, and internal scans can be run by your own qualified staff, so an ASV is not a substitute for the wider assessment. Ask your assessor how they will use the scan results, and confirm the scan scope matches the systems in your cardholder data environment.

Can our own staff run the penetration tests PCI DSS requires?

Yes, if the testers are qualified and organizationally independent. Requirements 11.4.2 and 11.4.3 allow testing by qualified internal staff or a qualified external third party, and those testers do not need to be a QSA or ASV. The practical questions are whether your team has the skills and independence to test the systems they also operate, and whether your assessor accepts the methodology and reporting. Many organizations use internal staff for routine testing and an external party for independent review. Confirm the tester qualifications, the independence arrangement and the report format with your QSA before testing begins.

How do we verify that a QSA company is still listed?

Check the PCI SSC's QSA list each time you engage a QSA, because the SSC advises that the list confirms the company has maintained its status. You can filter the list by place of business, region and language, so start there and match the company name and the individual assessor against the listing. Keep a dated record of the check in your assessment file. If the company or the named employee is not on the list, do not accept the Report on Compliance as a valid output of a QSA engagement. Ask the firm for written confirmation of its listing and the individual's QSA status before the contract is signed.

Does a QSA help us complete a Self-Assessment Questionnaire?

A QSA can help you understand a Self-Assessment Questionnaire, but the choice of SAQ and the completion of the questionnaire and its Attestation of Compliance remain your organization's responsibility. A Report on Compliance is the other route, and it is completed by a QSA. Some organizations engage a QSA for a readiness review of their SAQ answers, while others use an implementation partner to prepare evidence and keep the assessor's role separate. Ask whether the QSA firm will also review your SAQ, how that review affects their independence, and whether their fee covers the review. Keep in mind that SAQ eligibility depends on your payment channel and environment.

What does the assessment need from our team internally?

Your team owns the controls, the evidence and the decisions, and an assessor or provider cannot take those over. In practice this means maintaining an accurate scope and data-flow picture, running or commissioning the quarterly internal scans and the required testing, keeping policies and records current, and naming an accountable owner who answers the assessor's questions. Effort depends on the size of your cardholder data environment, the number of third parties involved and how well your evidence is organized. Ask your assessor for a written list of the evidence they expect, the people they will need access to, and the schedule for interviews and sampling before work starts.

What to confirm with your assessor and your payment brand

The payment brand or acquirer, not the PCI Security Standards Council, decides who must validate and which enforcement programs apply to you. The SSC maintains the standard and the assessor programs, but it does not enforce compliance or impose penalties. Before you scope any QSA or ASV work, confirm your required validation level, the SAQ type or ROC route, and your external scan schedule with your acquirer or the relevant brand. Those answers determine whether you need a ROC at all, how often ASV scans must run and what evidence the assessor will expect.

Once the requirements are confirmed, check the assessor's standing yourself. Ask your QSA company for its listing reference and compare it against the SSC's QSA list, which the SSC advises clients to check each time they engage a QSA. Ask your ASV whether its scan solution is current on the Approved Scanning Vendor list. Then put the following questions to them in writing: For the QSA: Which assessor employees will sign the ROC and AOC? Which systems, locations and third parties are in scope, and who signed off on that scope? What evidence formats do you accept, and will you rely on any other auditor's work or SOC 2 report, and under what conditions? For the ASV: Which IP addresses and domains does the scan cover, and who approves the scope? How do you handle false positives and rescans? Confirm that your report will be presented as scan evidence for Requirement 11.3.2 only.

Keep the answers in a short written record that names the brand, acquirer, QSA and ASV contacts and the agreed scope. This record protects your team if scope changes mid-engagement. Note also that an ASV scan report is not evidence that any other requirement is met, and the SSC does not endorse supplemental letters from ASVs, so ask your assessor which artifacts they will accept for each requirement before the work starts.

QSA vs ASV vs ISA: who does what in PCI DSS compliance