Assessment Guide
Your First PCI Assessment — Prepare in 30 Days, Not 6 Months
A PCI DSS assessment can feel overwhelming the first time. This guide walks you through every stage — from understanding which assessment type you need, through evidence collection and preparation, to what happens on assessment day and beyond.
Understanding Assessment Types
Before you prepare for an assessment, you need to understand which type of assessment applies to your organisation. PCI DSS offers two primary validation methods, and the one you need depends on your transaction volume, how your acquirer classifies you, and whether you are a merchant or a service provider.
Self-Assessment Questionnaire (SAQ)
An SAQ is a self-validation tool for merchants and service providers not required to undergo an on-site assessment. There are nine SAQ types, each corresponding to a specific payment environment. SAQ A is the simplest (approximately 22 controls) and applies to merchants who fully outsource all payment processing to PCI-validated third parties. SAQ D is the most comprehensive (300+ controls) and applies to merchants who store, process, or transmit card data in their own environment.
Use the SAQ Decision Engine to determine which SAQ type applies to your business. The answer depends on how you accept payments, whether you store cardholder data, and the technologies you use in your payment flow.
Report on Compliance (ROC)
A ROC is a formal assessment conducted on-site by a Qualified Security Assessor (QSA). It is required for Level 1 merchants (typically those processing more than 6 million transactions per year) and all service providers processing, storing, or transmitting cardholder data. The ROC involves detailed testing of every applicable requirement, staff interviews, configuration reviews, and evidence validation.
Even if your acquirer does not require a ROC, some organisations choose to have a QSA conduct their assessment for the rigour and credibility it provides. A QSA-signed SAQ carries more weight with business partners than a self-completed one.
Which Do You Need?
Your acquirer (the bank or payment processor that enrolled you as a merchant) ultimately determines your validation requirements. Contact them to confirm whether they require an SAQ or ROC. As a general rule:
- Level 1 merchants (6M+ transactions/year) — ROC with on-site QSA assessment
- Level 2 merchants (1–6M transactions/year) — SAQ with possible QSA validation (varies by card brand)
- Level 3–4 merchants (under 1M transactions/year) — SAQ self-assessment
- Service providers — ROC for those on the Visa/Mastercard SP registry; SAQ D-SP for others
Choosing a QSA
If you need a QSA — whether for a ROC assessment or to help validate your SAQ — selecting the right one is one of the most consequential decisions in your compliance journey. Not all QSAs are equal, and the wrong choice can cost you months and tens of thousands of dollars in unnecessary remediation.
What to Look For
- Industry experience — A QSA who has assessed e-commerce companies understands payment page risks differently than one who primarily assesses brick-and-mortar retailers. Ask for references in your specific industry vertical.
- v4.0.1 experience — All QSAs should be current on PCI DSS v4.0.1, but ask specifically how many v4.0.1 assessments they have completed. The customised approach and targeted risk analysis requirements are new, and experience matters.
- Team stability — Your assessor should ideally remain the same person year over year. High QSA turnover within a firm means you re-educate a new assessor on your environment every cycle.
- Communication style — During the assessment, you need clear, timely communication. Ask about their reporting cadence, how they handle findings, and whether they provide interim status updates.
- Remediation guidance — The best QSAs do not just identify gaps; they provide actionable guidance on how to remediate them. Ask whether their reports include specific recommendations.
- Scope validation — A quality QSA will validate your CDE scope before beginning the formal assessment. If they dive straight into testing without confirming scope, that is a concern.
Red Flags
- Guaranteed compliance — No reputable QSA will guarantee you will pass before conducting the assessment. If they do, question their integrity.
- Unrealistic timelines — A thorough Level 1 ROC assessment takes weeks to months, not days. Extremely compressed timelines suggest corners are being cut.
- Vague pricing — Assessment costs should be transparent and based on scope. Avoid QSAs who cannot provide a clear cost estimate after understanding your environment.
- Consulting and assessing — PCI SSC prohibits a QSA from both implementing controls and then assessing those same controls. If the same firm is offering to do both, ensure they have appropriate separation between teams.
Browse verified QSA companies and read merchant reviews in the GRCTrack QSA Directory.
Pre-Assessment Checklist
Complete these 10 preparation tasks before your assessment begins. Each one addresses a common area where first-time assessments stall or fail.
- Define your CDE boundary and document all data flows
Use the CDE Scoping Tool to map every system that stores, processes, or transmits cardholder data. Include connected systems and security-impacting systems. Document data flows showing how cardholder data enters, moves through, and exits your environment.
- Create or update your network diagram
Your network diagram must show all connections between the CDE and other networks, all system components within the CDE, and all network security controls. Include IP ranges, VLAN assignments, and firewall placement. This is typically the first document your assessor will request.
- Create or update your cardholder data flow diagram
Separate from the network diagram, the data flow diagram shows how cardholder data moves through your systems — from initial capture through processing, transmission, and storage (if any). Include all third parties that handle cardholder data on your behalf.
- Review and update all security policies
Ensure every security policy references PCI DSS v4.0.1 (not v3.2.1), has been reviewed and approved within the last 12 months, and includes the specific requirements mandated by Requirement 12. Policies must cover information security, acceptable use, access control, encryption, and incident response.
- Run internal and external vulnerability scans
External scans must be performed by an Approved Scanning Vendor (ASV). Internal scans can be performed internally or by a third party. You need at least four consecutive quarters of passing ASV scans. If this is your first assessment, begin scanning immediately to build the required history.
- Verify MFA is implemented for all CDE access
Under PCI DSS v4.0.1, MFA is required for all access into the CDE — not just remote access. Verify that every access method (VPN, console, jump servers, database tools, application interfaces) requires multi-factor authentication with independent factors.
- Collect and organise security awareness training records
Training must be conducted at hire and annually. Records should show completion dates, topics covered (including phishing awareness per Req 5.4.1), and personnel who completed training. Ensure training content has been updated for v4.0.1 changes.
- Conduct a penetration test
PCI DSS requires annual external and internal penetration testing per an industry-accepted methodology (Req 11.4). The test must include both network-layer and application-layer testing. Remediate any high or critical findings and re-test to confirm remediation before your assessment.
- Prepare an inventory of all system components in the CDE
List every server, workstation, network device, application, and database within your CDE. Include operating system versions, software versions, and patch levels. Your assessor will use this inventory to select samples for configuration review and testing.
- Brief relevant staff on the assessment process
Your assessor will interview staff including system administrators, security personnel, developers, and potentially customer service representatives. Brief each team on what to expect: factual answers about their daily processes, not scripted responses. Honesty is essential — assessors are trained to detect rehearsed answers.
Use the PCI Compliance Checklist to track completion of each preparation task against your SAQ type.
Evidence Collection Guide
Evidence is the foundation of your assessment. Without well-organised, complete evidence, even a perfectly compliant environment will fail its assessment because the assessor cannot verify controls. Here is what to gather and how to organise it.
Evidence Types
PCI DSS evidence falls into eight categories. Understanding these categories helps you systematically collect everything your assessor will need.
- Policies — Written information security policies covering each of the 12 PCI DSS requirement domains. Must be approved by management, reviewed annually, and distributed to relevant personnel.
- Procedures — Documented operational procedures for security activities such as user provisioning, change management, incident response, and key management.
- Configuration samples — Screenshots or exports of firewall rules, system hardening configurations, access control lists, encryption settings, and logging configurations.
- Logs and audit trails — Samples of audit logs showing security events, access attempts, configuration changes, and administrative actions. Must demonstrate that logging is active and reviewed.
- Diagrams — Network diagrams showing CDE boundaries, data flow diagrams showing cardholder data movement, and architecture diagrams for key systems.
- Scan and test reports — ASV scan reports (quarterly), internal vulnerability scan reports, penetration test reports, and wireless scanning reports.
- Training records — Completion records for security awareness training, developer secure coding training, and role-specific training.
- Third-party documentation — Service provider AOCs, contracts with security clauses, and responsibility matrices showing which PCI requirements each party fulfils.
How to Organise Evidence
Organise your evidence by PCI DSS requirement number (1 through 12, with sub-requirements). For each requirement, create a folder containing all relevant evidence. Label each file clearly with: the requirement number, evidence type, date collected, and system or scope it covers. For example: Req-8.3.6_Config_2026-01-15_AD-Password-Policy.png.
The Evidence Library contains sample evidence artefacts for every requirement, showing exactly what good evidence looks like. GRCTrack's platform automatically organises collected evidence by requirement and tracks collection completeness.
Evidence Freshness
PCI DSS requires that at least the most recent three months of evidence be readily available, and all evidence must be retained for at least one year. Do not wait until the week before your assessment to collect evidence — many items (like quarterly scan reports) must be collected throughout the year. Set calendar reminders for recurring evidence collection activities.
What Happens During the Assessment
Knowing what to expect reduces anxiety and helps you prepare effectively. Here is a typical assessment timeline for a ROC assessment. SAQ assessments follow a similar process but are condensed and may be conducted remotely.
Phase 1: Scoping and Planning (1–2 Weeks)
The assessor begins by reviewing your CDE scope documentation, network diagrams, and data flow diagrams. They validate the accuracy of your scope by asking probing questions about how cardholder data enters, moves through, and exits your environment. Scope errors at this stage cascade through the entire assessment, so be thorough and honest. If the assessor identifies systems you missed, the scope expands and the assessment timeline extends.
Phase 2: Documentation Review (1–2 Weeks)
The assessor reviews all policies, procedures, and documentation evidence. They verify that policies align with v4.0.1 requirements, that procedures match actual operational practices, and that documentation is current. This phase often reveals gaps between what is documented and what is implemented — addressing these gaps before Phase 3 saves significant time.
Phase 3: Technical Testing (2–4 Weeks)
This is the most intensive phase. The assessor tests actual configurations against requirements: firewall rules, access control lists, encryption implementations, patch levels, logging configurations, and more. They select samples from your system component inventory and examine each in detail. This phase includes observation of operational processes like change management, user provisioning, and incident response.
Phase 4: Interviews (1–2 Weeks, Often Concurrent)
The assessor interviews personnel across multiple roles: system administrators, security analysts, developers, help desk staff, and management. Interviews verify that staff understand and follow documented procedures. The assessor is looking for consistency between documentation, configurations, and human behaviour. Brief your staff to answer honestly about their actual daily practices — inconsistencies between documented procedures and actual behaviour are common findings.
Phase 5: Findings and Remediation (Variable)
After testing, the assessor compiles findings. These may include: controls that are fully in place, controls that are in place with minor issues, and controls that are not in place. For any non-compliant finding, you will need to remediate and provide evidence of remediation before the assessor can close the finding. Some assessors offer a "findings call" mid-assessment to give you early visibility into issues.
Phase 6: Report Issuance (2–4 Weeks)
Once all findings are resolved, the assessor issues the formal ROC and AOC (Attestation of Compliance). The ROC is typically 200+ pages and documents the testing procedures and results for every requirement. The AOC is the summary document you share with your acquirer, payment brands, and business partners.
Common Reasons for Assessment Failure
Based on data from hundreds of assessments, these are the five most common reasons organisations fail their first PCI assessment. Addressing each of these proactively dramatically improves your chances of a clean assessment.
1. Incomplete or Inaccurate Network Diagrams
The network diagram is the assessor's roadmap. If it is inaccurate, incomplete, or outdated, the assessor cannot validate your CDE scope. Common problems include: missing cloud environments, unlabelled network segments, outdated IP addressing, missing connections to third parties, and diagrams that do not show security control placement. Invest time in creating accurate diagrams before the assessment. Use the CDE Scoping Tool to ensure completeness.
2. Missing Quarterly ASV Scan Results
PCI DSS requires quarterly external vulnerability scans by an Approved Scanning Vendor (ASV) and quarterly internal vulnerability scans. You need four consecutive quarters of passing scans to demonstrate a full year of compliance. First-time assessment candidates often only begin scanning a few months before assessment, resulting in an insufficient scan history. Start scanning immediately — you cannot fabricate historical scan data.
3. Inadequate Logging and Monitoring
Requirement 10 demands comprehensive audit logging across all CDE systems, and v4.0.1 adds automated log review (Req 10.4.1.1). Many organisations have logging enabled but lack the coverage, retention, or review mechanisms required. Assessors check that logs capture: all individual user access to cardholder data, all actions taken by anyone with root or administrative privileges, all access to audit trails, invalid access attempts, use of identification and authentication mechanisms, and initialisation of audit logs. Ensure your SIEM or log management solution covers all these categories.
4. Outdated or Missing Security Policies
Policies must exist, be current (reviewed within 12 months), be approved by management, and be distributed to relevant personnel. First-time assessment candidates often have informal security practices but lack formal documentation. Requirement 12 is extensive and requires policies covering every major security domain. Do not treat policy writing as an afterthought — it is a requirement in its own right and underpins every other requirement.
5. Insufficient Change Management Evidence
Requirement 6.5.1 requires a formal change management process for all changes to system components in the CDE. This includes documenting: the change description, approval authority, impact analysis, testing results, and back-out procedures. Many organisations, especially smaller ones, make changes informally without documented approval or testing. Assessors will request change management records for recent changes and verify that the process was followed consistently.
After the Assessment
Completing your assessment is a milestone, but it is not the finish line. PCI DSS compliance is a continuous obligation, and your assessment validates a point in time. Here is what happens after your assessor signs off.
Attestation of Compliance (AOC)
Your assessor issues an AOC — a formal attestation that your environment was assessed against PCI DSS v4.0.1 and found compliant as of the assessment date. Submit this to your acquirer, who will update your compliance status with the card brands. The AOC is typically what your business partners and customers request as proof of compliance. Keep it readily accessible but understand that it is a summary — the detailed ROC is the full evidence record.
Report on Compliance (ROC)
The ROC is the comprehensive assessment report documenting every testing procedure and result. It is typically shared only with your acquirer and the card brands if requested. Retain it securely for at least one year. The ROC serves as your detailed compliance record and is invaluable for preparing for your next assessment.
Remediation of Open Items
If your assessment identified findings that were remediated during the assessment cycle, ensure the underlying root causes are addressed to prevent recurrence. Create a remediation tracker for any items that required corrective action and verify they remain in place during subsequent quarters.
Ongoing Compliance Activities
Between assessments, you must maintain continuous compliance. Key recurring activities include:
- Quarterly ASV scans — Schedule and run external vulnerability scans every quarter without gaps.
- Quarterly internal scans — Conduct internal vulnerability scans and remediate findings based on risk severity.
- Annual penetration testing — Schedule your next penetration test well in advance of your next assessment.
- Annual security awareness training — Deliver training to all relevant personnel and maintain completion records.
- Annual policy review — Review and re-approve all security policies within 12 months of the last review.
- Continuous logging and monitoring — Ensure audit logs are collected, reviewed (Req 10.4.1.1 requires automated review), and retained.
- Change management — Follow your documented change management process for every CDE change throughout the year.
GRCTrack's platform automates tracking of these recurring activities, sending reminders when quarterly scans are due, flagging policy review deadlines, and providing a continuous compliance dashboard. Explore the platform overview to see how it works.
Ready to Prepare for Your First Assessment?
GRCTrack walks you through every preparation step, organises your evidence, and connects you with QSAs who specialise in first-time assessments.