A PCI assessment sounds like a single thing developers can plan for, but the term covers a family of substantially different processes — SAQ self-assessment, internal security assessor review, QSA-led Report on Compliance, and the various PCI risk assessment activities that feed into each. The output of all of them is the same artifact: an Attestation of Compliance (AoC) — the signed document that says "this entity met PCI DSS Requirement X.Y.Z on this date" and that acquiring banks, payment processors, and card brands use to determine whether the entity is permitted to continue processing card data. This guide walks the PCI assessment landscape from a developer's perspective — what each assessment type actually involves, which merchant level requires which path, what the AoC really says, the QSA vs ISA vs self-assessment distinction, the PCI DSS vulnerability scan requirements that feed remediation evidence, and the operational workflow from scoping to submission. The broader PCI DSS 4.0.1 secure-coding-training requirement (6.2.2) is covered in the dedicated 6.2.2 guide; this post focuses on the assessment process itself.
Why PCI Assessments Are More Complicated Than They Sound
The phrase "PCI compliance" gets used as if it described a single status — compliant or not — that an entity achieves once and maintains thereafter. The operational reality is substantially more nuanced. PCI compliance is a continuous attestation: the entity attests, on a defined cadence (annually for most merchants), that it meets a specific subset of PCI DSS requirements appropriate to the entity's transaction volume, data-handling architecture, and the assessment path the acquiring bank has approved. The attestation is renewed each year against the then-current PCI DSS version (4.0.1 as of mid-2026), with each renewal cycle producing fresh AoC documents that the merchant submits to the acquiring bank, often through automated portals that the merchant's payment processor operates on the bank's behalf.
The complications cluster around four axes. First, the assessment scope: PCI applies only to systems that store, process, or transmit cardholder data, plus systems that are connected to or could affect the security of those systems. Scoping correctly is the single most consequential decision in the assessment process — a 5-system Cardholder Data Environment (CDE) assessed correctly is hundreds of times cheaper to bring into compliance than a 500-system network where the CDE boundary was drawn poorly. Second, the assessment type varies by merchant level (transaction volume) and the merchant's data handling architecture — Level 1 merchants face a Report on Compliance led by an external Qualified Security Assessor, while Level 4 merchants typically complete a Self-Assessment Questionnaire. Third, the AoC itself comes in multiple variants tied to the assessment type, with different levels of formal review and acquiring-bank acceptance. Fourth, the PCI risk assessment activities that feed into the formal assessment — the vulnerability scans, penetration tests, gap analyses, and risk treatment plans — have their own cadences and evidence requirements that the merchant has to maintain regardless of when the formal assessment cycle reaches each component.
The pragmatic mental model that produces correct expectations: a PCI assessment is a documented attestation against a known control framework, conducted by the merchant or an external assessor depending on merchant level, producing a signed AoC that the acquiring bank uses to authorize ongoing card processing. Everything else — the scoping work, the gap remediation, the vulnerability scanning, the policies and procedures, the developer training — feeds into producing that attestation defensibly.
The Four Merchant Levels — Transaction Volume Defines the Path
The four merchant levels defined by the PCI Security Standards Council determine which assessment path applies to a given merchant. The thresholds are denominated in annual card transactions across all card brands, with the highest-volume brand typically setting the level.
Level 1: More than 6 million transactions annually. Required to undergo a full Report on Compliance (RoC) led by an external Qualified Security Assessor (QSA), with quarterly external vulnerability scans by an Approved Scanning Vendor (ASV) and an Internal Security Assessor-led penetration test annually. The AoC for Level 1 is the RoC-derived AoC, signed by both the QSA conducting the assessment and an executive officer of the merchant attesting to the accuracy of the disclosed information. Level 1 assessments routinely cost six figures and take six to nine months for the first cycle, with subsequent cycles compressed by the maturity of evidence collection processes built during the first cycle.
Level 2: 1 million to 6 million transactions annually. May complete a Self-Assessment Questionnaire (typically SAQ-D for service providers and larger merchants) signed by the merchant, with the acquiring bank's option to require a QSA-led assessment if the merchant has suffered a breach or the bank judges the risk profile to warrant it. Level 2 assessments cost mid-five-figures to low-six-figures depending on whether the merchant runs the assessment internally or contracts a QSA for advisory work.
Level 3: 20,000 to 1 million e-commerce transactions annually. Completes a Self-Assessment Questionnaire appropriate to the merchant's payment architecture, with quarterly external ASV scans required. The SAQ variant depends on data handling — SAQ-A for merchants who outsource all cardholder data handling to a PCI-compliant payment processor, SAQ-A-EP for merchants whose website handles the redirect/iframe to the processor, with various other SAQs for terminal-based and mixed scenarios.
Level 4: Fewer than 20,000 e-commerce transactions or 1 million card-present transactions annually. The Level 4 self-assessment path is the lowest-bar route, with most Level 4 merchants completing SAQ-A by leveraging a PCI-compliant payment processor for all cardholder data handling. Many acquiring banks delegate Level 4 SAQ collection to the payment processor, who runs the merchant through a guided questionnaire as part of merchant onboarding. The pci compliance for small business reality is that most genuinely small businesses qualify as Level 4 and can complete the assessment in hours rather than weeks if they have chosen a tokenization-first payment architecture.
The level thresholds are not always the deciding factor. Acquiring banks can require a higher-level assessment than the transaction volume would imply if the merchant has suffered a breach, if the merchant's risk profile is unusual, or if the card brands have specifically designated the merchant for a higher level. Visa and Mastercard both publish merchant lists with specific level designations that override the volume-based defaults.
SAQ Variants — Eight Forms for Different Architectures
The Self-Assessment Questionnaire (SAQ) exists in eight variants tied to specific cardholder data handling architectures. Choosing the correct SAQ for the merchant's architecture is the second-most-important assessment decision after scoping; the wrong SAQ may technically be completable but provides no compliance value because the acquiring bank will not accept it.
SAQ-A. The simplest SAQ. Applicable to merchants who outsource all cardholder data functions to PCI DSS validated third-party service providers — typically e-commerce merchants who redirect customers to a payment processor's hosted payment page (Stripe Checkout, Square Online Store, Braintree Drop-in UI) and never see card numbers in their own systems. SAQ-A has the fewest questions (about 25 in 4.0.1) and the lowest evidence burden. The architectural pattern that qualifies for SAQ-A is the gold standard for small businesses wanting minimum PCI scope.
SAQ-A-EP. Applicable to e-commerce merchants whose website pages contain elements that interact with the payment processor's systems — JavaScript that posts to the processor, iframes that load the processor's payment form, or DOM elements that the processor's script manipulates. The merchant doesn't see cardholder data directly, but the merchant's website is in scope because a compromise of the merchant's web infrastructure could enable card-data interception. SAQ-A-EP is substantially more demanding than SAQ-A because the merchant's web infrastructure becomes subject to a broader set of PCI requirements.
SAQ-B. Applicable to merchants using only standalone, dial-out terminals (point-of-sale terminals with no internet connection, traditional knuckle-buster imprinters). Increasingly rare as modern POS terminals have networking; SAQ-B is mostly a legacy variant for retail merchants who haven't modernized.
SAQ-B-IP. Applicable to merchants using only internet-connected, PCI PTS-approved POS terminals — the modern equivalent of SAQ-B with networking added. The terminals communicate directly with the payment processor over the merchant's network, with the merchant maintaining minimal infrastructure that touches cardholder data.
SAQ-C. Applicable to merchants whose payment application is a payment application validated by the PCI SSC and connected to the internet, with the merchant maintaining the network infrastructure but not the payment application itself. Less common in 2026 as more merchants move to cloud-hosted payment processors.
SAQ-C-VT. Applicable to merchants using only virtual payment terminals through a secure web-based session to a PCI-compliant processor. The merchant manually types card data into a browser-based interface; no card data persists on the merchant's systems.
SAQ-P2PE-HW. Applicable to merchants using only PCI SSC-listed Point-to-Point Encryption (P2PE) solutions. The card data is encrypted by the P2PE terminal before it ever reaches the merchant's systems; the merchant cannot decrypt it. SAQ-P2PE-HW is the simplest path for card-present merchants and dramatically reduces PCI scope for retail businesses.
SAQ-D. The catch-all SAQ for merchants and service providers whose architectures don't fit the other SAQs. SAQ-D has the most questions (over 300 in 4.0.1) and the most extensive evidence burden, approaching the rigor of a Report on Compliance without the QSA leadership. Service providers (entities that store, process, or transmit cardholder data on behalf of merchants) typically complete SAQ-D when not undergoing a full RoC.
The correct SAQ for a given merchant is not optional — it is determined by the merchant's payment architecture against the SAQ eligibility criteria published by the PCI SSC. Acquiring banks verify SAQ eligibility before accepting the AoC.
Report on Compliance (RoC) — When QSA Leadership Is Required
The Report on Compliance is the most rigorous PCI assessment, required for Level 1 merchants and for service providers above defined thresholds. Unlike SAQs (which are self-completed questionnaires), the RoC is a comprehensive assessment document produced by an external Qualified Security Assessor (QSA) following the PCI SSC's standardized testing procedures. A typical RoC is a multi-hundred-page document containing the QSA's findings against each PCI DSS requirement, with explicit notation of compliant, not-compliant, not-applicable, and compensating-control status for every individual requirement.
The RoC process spans six to nine months for a first-cycle Level 1 merchant. The phases: scoping (defining the Cardholder Data Environment and identifying which systems are in scope), gap analysis (the QSA reviews the merchant's current state against PCI requirements and identifies the gaps), remediation (the merchant closes identified gaps; this phase is the longest), evidence collection (gathering documentation that supports each requirement's compliance status), formal testing (the QSA conducts the testing procedures defined in the PCI DSS Reporting Template), and report drafting and review (the QSA writes the RoC, the merchant reviews it for accuracy, both parties sign the AoC).
The cost of a RoC reflects the scope of work. A small Level 1 merchant with a well-scoped CDE might complete a RoC for $50,000-$150,000 in QSA fees plus internal remediation costs. A large Level 1 merchant with a complex CDE spanning multiple business units can spend $500,000+ on QSA fees alone, with remediation costs running into millions for the first cycle. Subsequent cycles compress substantially as the evidence-collection processes built during the first cycle persist.
The Attestation of Compliance — What It Actually Says
The pci attestation of compliance is the single signed document that emerges from any PCI assessment, regardless of type. It is the artifact acquiring banks, payment processors, and card brands actually consume to determine whether the merchant is permitted to continue processing card data. Understanding what the AoC says — and what it does not say — is essential to operating a defensible PCI program.
What the AoC contains. A signed declaration that the merchant has completed the specified assessment (SAQ or RoC) against the specified PCI DSS version (4.0.1 in 2026), with the assessment date, the validity period (typically one year), the merchant's identification and contact details, the scope of the assessment (the Cardholder Data Environment as defined for assessment purposes), and a high-level summary of compliance status. The AoC is typically 3-5 pages for SAQ-based assessments and 10-15 pages for RoC-derived attestations.
Who signs the AoC. For SAQ-based assessments, the AoC is signed by an executive officer of the merchant — typically the CEO, CFO, or COO — attesting to the accuracy of the questionnaire responses. For RoC-derived assessments, the AoC is signed by both the QSA leading the assessment and a merchant executive officer. The dual signature is significant: it represents the QSA's professional judgment about the assessment's accuracy and the merchant's executive accountability for the disclosed compliance status.
What the AoC does not say. The AoC does not say the merchant is "secure" — it says the merchant met the specified PCI DSS requirements on the assessment date. The AoC does not say the merchant has no vulnerabilities — it says the merchant has documented compensating controls for any identified gaps. The AoC does not say the merchant will remain compliant — it says the merchant attests to compliance at this point in time. The annual renewal cycle exists because the AoC's claims are point-in-time assertions that decay as the merchant's environment evolves.
AoC variants. The AoC comes in three primary variants tied to the assessment type. AoC for Onsite Assessment (used with RoC-derived assessments). AoC for SAQ (used with self-assessments, with the SAQ variant specified in the document). AoC for P2PE (used with PCI-listed P2PE-HW assessments). Acquiring banks verify AoC variant matches the merchant's required assessment type before accepting it.
QSA vs ISA vs Self-Assessment — Choosing the Path
The assessment path depends on the merchant level and the merchant's internal capacity. Three primary paths exist, with their respective applicability and resource implications.
Qualified Security Assessor (QSA). External, PCI SSC-certified individuals working for QSA Companies (QSACs) accredited by the PCI SSC. Required for Level 1 RoC assessments. QSAs conduct the formal testing, document findings, and produce the RoC. The merchant retains the QSA on engagement; the QSA's accreditation is what makes the resulting RoC acceptable to acquiring banks. QSAs are not the merchant's employees — the independence is structural to the assessment's credibility.
Internal Security Assessor (ISA). Merchant employees who have completed PCI SSC's ISA certification program, qualifying them to perform assessments internally. ISAs can conduct SAQ-based assessments for their own organization and can lead some Level 1 assessments depending on the acquiring bank's policy. The ISA path reduces QSA dependency and produces internal expertise that maintains evidence quality between formal assessments. ISA-led assessments are typically accepted by acquiring banks for Level 2 and below; Level 1 still requires QSA involvement in most cases, with the ISA acting as the internal coordinator.
Self-Assessment (No Certification Required). Merchants below Level 1 can self-complete SAQs without ISA or QSA involvement. The questionnaire is designed to be answerable by qualified internal staff with sufficient knowledge of the merchant's systems and controls. The AoC is signed by an executive officer who takes accountability for the accuracy. Most Level 3 and Level 4 merchants follow this path. The risk is that uninformed self-assessment can produce inaccurate AoCs that come apart at the first breach investigation; merchants serious about PCI compliance often hire QSA advisory services even when their level technically permits self-assessment.
The Assessment Workflow — From Scoping to Submission
The operational workflow that produces a defensible PCI assessment, walked from initiation through AoC submission. The steps are similar across SAQ and RoC paths; the depth and rigor differ.
Step 1 — Scope the Cardholder Data Environment. Identify every system that stores, processes, or transmits cardholder data, plus every system connected to or affecting the security of those systems. Document the data flows. Identify compensating controls and segmentation that limit CDE scope. The output is a network diagram and a data flow diagram that show exactly which systems are in PCI scope.
Step 2 — Conduct a PCI Risk Assessment. The pci risk assessment is the formal evaluation of threats against the CDE and the controls in place. Required annually under PCI DSS Requirement 12. The assessment identifies risks, documents treatments, and produces the risk treatment plan that feeds remediation prioritization.
Step 3 — Perform Gap Analysis Against PCI DSS Requirements. For each PCI DSS requirement applicable to the assessment scope (12 main requirements with 250+ sub-requirements in 4.0.1), document the current state and identify gaps. The gap analysis output is a remediation backlog ordered by risk and complexity.
Step 4 — Remediate Identified Gaps. Close the gaps the analysis identified. This is the longest phase, typically two-thirds of the calendar time in a first-cycle assessment. Remediation outputs include policy updates, technical control implementations, training delivery, and the evidence artifacts that demonstrate each control's operation.
Step 5 — Conduct Required Testing. ASV-conducted quarterly external vulnerability scans (the pci dss vulnerability scan requirement). Annual penetration testing. Internal vulnerability scanning. Configuration scanning of CDE systems. The testing produces evidence artifacts the assessment incorporates.
Step 6 — Document Compliance Status. For SAQ paths, complete the questionnaire with documented evidence references for each response. For RoC paths, the QSA produces the RoC document following the PCI SSC's Reporting Template structure.
Step 7 — Sign and Submit the AoC. Executive officer signs the AoC (and QSA co-signs for RoC). The merchant submits the AoC to the acquiring bank through whatever channel the bank requires — direct email, a compliance management portal operated by the bank or the payment processor, or a card-brand-specific submission system.
Step 8 — Maintain Continuous Compliance. The AoC's claims decay as the environment evolves. Continuous evidence collection (logging, monitoring, change management) maintains the substrate that next year's renewal cycle will draw from. The merchant's PCI program is the ongoing operation that makes annual renewal tractable rather than catastrophic.
Vulnerability Remediation Timelines and Compensating Controls
PCI DSS 4.0.1's vulnerability management requirements (in particular Requirement 6 for secure development and Requirement 11 for security testing) define explicit timelines that drive merchant remediation cadence. Critical vulnerabilities — typically CVSS 9.0+ — must be remediated within 30 days of identification. High vulnerabilities (CVSS 7.0-8.9) within a defined timeline appropriate to the merchant's risk treatment plan. Medium and low vulnerabilities tracked in the remediation backlog without specific deadlines but with the requirement that they be addressed during normal change cycles.
Where remediation is technically infeasible or imposes disproportionate operational cost, compensating controls provide an alternative path. A compensating control is an alternative technical or administrative measure that achieves the same security objective as the original requirement, with the QSA or ISA validating that the compensating control is equivalent in protection. Common compensating controls: network segmentation that limits the scope of an unpatched system, additional monitoring that detects exploitation attempts the vulnerability would enable, multi-factor authentication added to reduce the consequence of credential-related vulnerabilities. Compensating controls must be documented in detail, reviewed annually, and approved by the assessor.
The integration with the broader application security verification work — covered in the OWASP ASVS 5.0 developer guide — is that ASVS verification evidence satisfies many PCI DSS Requirement 6 sub-requirements directly. ASVS L2 verification at the application layer plus PCI-specific environmental controls produces evidence that supports both attestations from a single underlying program. Merchants running ASVS-aligned application security programs find their PCI assessment evidence collection is substantially less work than the typical merchant who treats application security and PCI assessment as separate programs.