PCI DSS v4.0.1 Readiness Assessment — Sample Report
PCI DSS v4.0.1 Readiness Assessment — Illustrative Sample. A fictional readiness engagement for SampleCompany.com, a mid-market e-commerce retailer, showing how TMG Security scopes, tests, and reports a PCI DSS v4.0.1 readiness assessment across all twelve PCI DSS requirement areas.
SampleCompany.com is a fictional entity. No actual PCI DSS assessment, gap analysis, or readiness review was performed, and no Report on Compliance (ROC) or Attestation of Compliance (AOC) was issued.
Overview
A PCI DSS readiness assessment is a gap-analysis-style engagement performed ahead of a formal PCI DSS validation activity — a Self-Assessment Questionnaire (SAQ) or, for larger merchants and service providers, a Report on Compliance (ROC) produced by a Qualified Security Assessor (QSA). It reviews an organization's people, processes, and technology against the twelve PCI DSS requirement areas, identifies gaps, and produces prioritized remediation guidance so the organization can close those gaps before a real validation engagement begins. A readiness assessment does not itself produce a ROC or AOC and is not a substitute for one.
This sample report shows how TMG Security structures that deliverable. It is built around SampleCompany.com, a fictional mid-market e-commerce and online retail organization, and covers a simulated assessment period of 01–21 August 2026. SampleCompany.com's fictional environment processes card-not-present transactions through a hosted storefront, a public-facing API layer, and a client-side integration with a third-party payment gateway's tokenization service — a payment model that reduces, but does not eliminate, the scope of the cardholder data environment (CDE).
What this sample demonstrates
SampleCompany.com does not exist. Every finding, control status, and figure in this sample is fictional and constructed to show TMG's methodology and reporting standard for a PCI DSS v4.0.1 readiness engagement — not to describe any real organization's compliance posture.
- How TMG defines and documents cardholder data environment (CDE) scope before testing begins
- How evidence and sampling are referenced against each of the twelve PCI DSS v4.0.1 requirement areas
- How a requirement-by-requirement control review is structured, objective by objective
- How findings are rated for severity, root-caused, and mapped to specific PCI DSS requirements
- How a 90-day remediation roadmap and management action plan are built from findings
- The full appendix structure — evidence register, finding register, and assessment limitations — that supports a real engagement
Assessment scope
The illustrative scope below reflects the boundary TMG Security would define and document ahead of a PCI DSS v4.0.1 readiness engagement, including the fictional cardholder data environment (CDE), connected systems, and third-party dependencies that reduce but do not remove SampleCompany.com from PCI DSS scope.
In scope
- Internet-facing e-commerce platform — customer storefront, checkout, and account management
- Web application front-end and server-side application logic
- API layer supporting order, session, and checkout services
- Application, order, and transaction metadata database
- Cloud compute, storage, and networking supporting the CDE
- Privileged and administrative access paths to in-scope systems
- Centralized logging infrastructure and SIEM supporting in-scope systems
- Vulnerability management program covering in-scope assets
Dependency / third party
- Third-party hosted payment gateway and tokenization service
- Outsourced security monitoring and detection service (SOC/MDR)
Out of scope
- Corporate workstation and internal business-system access
- Human resources and payroll platforms with no CDE connectivity
Assessment methodology
TMG Security applies a structured, repeatable eleven-stage methodology across every PCI DSS readiness engagement. Because this is a demonstration report, every interview, evidence review, and technical validation step is simulated — no actual SampleCompany.com personnel were interviewed, and no actual systems were accessed, scanned, or tested.
Scope Validation
Confirm the boundary of the cardholder data environment and any connected systems.
Documentation Review
Review policies, standards, network diagrams, and data flow documentation.
Control Walkthroughs
Observe and walk through key controls across IT, security, and business functions.
Personnel Interviews
Interview control owners across IT, security, and operations.
Evidence Review
Collect and evaluate artifacts supporting each control objective.
Technical Validation
Perform configuration reviews and technical checks against sampled systems.
Sampling
Apply a representative sampling methodology across system components and locations.
Gap Identification
Identify and document control gaps relative to PCI DSS v4.0.1 requirements.
Risk Assessment
Assign risk ratings to identified gaps based on likelihood and impact.
Remediation Recommendations
Develop actionable, prioritized remediation guidance for each finding.
Management Review
Present findings to management and align on ownership and timelines.
PCI DSS v4.0.1 requirement coverage
A fictional, sample-level summary of illustrative assessment status across all twelve PCI DSS v4.0.1 requirement areas assessed in the full report.
| # | Requirement | Illustrative Status |
|---|---|---|
| 1 | Install and Maintain Network Security Controls | Partially In Place |
| 2 | Apply Secure Configurations to All System Components | In Place |
| 3 | Protect Stored Account Data | Partially In Place |
| 4 | Protect Cardholder Data with Strong Cryptography During Transmission | In Place |
| 5 | Protect All Systems and Networks from Malicious Software | In Place |
| 6 | Develop and Maintain Secure Systems and Software | Not In Place |
| 7 | Restrict Access to System Components and Cardholder Data | Partially In Place |
| 8 | Identify Users and Authenticate Access to System Components | In Place |
| 9 | Restrict Physical Access to Cardholder Data | In Place |
| 10 | Log and Monitor All Access to System Components and Cardholder Data | In Place |
| 11 | Test Security of Systems and Networks Regularly | In Place |
| 12 | Support Information Security with Organizational Policies and Programs | In Place |
Evidence & sampling
The full sample report references fourteen illustrative evidence categories — including information security policies, standard operating procedures, network and data flow diagrams, asset inventory records, user access and recertification records, multi-factor authentication configuration, vulnerability scan and penetration test reports, firewall and network security control configuration, logging and SIEM configuration, incident response records, security awareness training records, change management records, and backup and recovery records. Every evidence reference (EV-xxx) throughout this sample is an illustrative placeholder only — no actual documents or artifacts were collected.
Where full-population testing was not practicable, a representative sampling methodology was applied consistent with common assessment practice: samples were selected to reasonably represent the population of in-scope system components, locations, and time periods, with sample sizes adjusted based on population size and control criticality. All sampling described in this report is fictional and provided to illustrate TMG Security's documented sampling approach.
Example findings & risk reporting
Across all twelve PCI DSS v4.0.1 requirement areas assessed, this fictional sample produced 10 findings — 0 rated Critical, 1 High, 3 Medium, 3 Low, and 3 Observations. Every finding, evidence reference, and management response below is fictional.
Incomplete Vulnerability Remediation Tracking
A fictional sample review of vulnerability scan output found that remediation activity for several sampled vulnerabilities was not consistently logged against a defined remediation timeline, because no centralized, single system of record existed for tracking. Recommendation: implement centralized vulnerability remediation tracking with defined ownership, risk-based remediation timelines, and closure validation.
Archived Account Data Retained Beyond Organization-Defined Retention Period
A sample of archived transaction records was found to exceed SampleCompany.com's own documented retention period prior to disposal, because the automated disposal job supporting the archival data store was not consistently executed. Recommendation: implement an automated, monitored data lifecycle and disposal process aligned to the documented retention policy.
Security Awareness Training Completion Not Centrally Tracked
Security awareness training completion was confirmed for sampled personnel; however, completion tracking was maintained manually rather than through a centralized learning management system, increasing administrative burden and the risk that incomplete population coverage could go undetected. Recommendation: adopt a centralized LMS to track training completion and automate reminder escalation.
| ID | Title | Severity | PCI DSS Requirement |
|---|---|---|---|
| PCI-SD-006 | Incomplete Vulnerability Remediation Tracking | High | Requirement 6 |
| PCI-NSC-001 | Network Security Control Rule Set Contains Undocumented Legacy Rules | Medium | Requirement 1 |
| PCI-DAT-003 | Archived Account Data Retained Beyond Organization-Defined Retention Period | Medium | Requirement 3 |
| PCI-IAM-007 | Quarterly User Access Review Evidence Incomplete for Sampled Accounts | Medium | Requirement 7 |
| PCI-CFG-002 | Secure Configuration Standard Not Updated for Newly Deployed Cloud Service | Low | Requirement 2 |
| PCI-MAL-005 | Anti-Malware Audit Logs Not Consistently Retained per Requirement 10.5.1 | Low | Requirement 5 |
| PCI-LOG-008 | Audit Log Retention Configuration Inconsistent Across Sampled Systems | Low | Requirement 10 |
| PCI-TST-009 | Internal Security Observation — Segmentation Test Governance | Observation | Not Applicable |
| PCI-TLS-004 | Internal Security Observation — Legacy TLS Configuration | Observation | Not Applicable |
| PCI-GOV-010 | Security Awareness Training Completion Not Centrally Tracked | Observation | Requirement 12 |
Remediation planning
The fictional 90-day remediation roadmap sequences remediation activity ahead of an actual PCI DSS validation engagement, prioritizing the High-severity finding for early closure.
0–30 days
- Remediate the High-severity finding: implement centralized vulnerability remediation tracking (PCI-SD-006)
- Complete recertification of privileged and administrative access across in-scope systems
30–60 days
- Complete logging and alerting configuration improvements across all sampled systems
- Update information security policy and configuration standards to reflect the current environment
- Refresh security awareness training content and completion tracking approach
60–90 days
- Execute segmentation and network security control testing, including formal management review
- Conduct an incident response tabletop exercise validating updated escalation procedures
- Complete third-party / service provider risk review and annual governance program assessment
What the full sample report contains
The complete 33-page PDF includes every section TMG Security would build for an actual PCI DSS v4.0.1 readiness engagement:
- Document control, important disclaimer, and PCI DSS assessment terminology reference
- Executive summary and illustrative assessment dashboard
- Management overview — business environment, payment processing model, and strategic recommendations
- Scope & environment table and illustrative cardholder data environment architecture diagram
- Eleven-stage assessment methodology and evidence & sampling methodology
- Requirement-by-requirement narrative review across all twelve PCI DSS v4.0.1 requirements
- Findings summary, full consulting-format detailed findings, and risk dashboard
- 90-day remediation roadmap and management action plan
- Final assessment & conclusion, evidence register, finding register, assessment limitations, and glossary of terms
SampleCompany.com is a fictional entity. It does not correspond to any real business, and any resemblance to an actual organization is purely coincidental.
No actual PCI DSS assessment, gap analysis, or readiness review was performed against any real environment, system, or organization. No production environment, system, or network of any kind was accessed, scanned, or tested in the creation of this report, and no actual evidence — including policies, configuration exports, screenshots, logs, or records — was collected, reviewed, or relied upon. No actual interviews or control walkthroughs were conducted with any personnel, and no actual vulnerability scanning, configuration scanning, penetration testing, or segmentation testing was performed.
All findings, risk ratings, evidence references, control statuses, and remediation timelines in this report are illustrative and fictional. They were constructed to demonstrate realistic reporting conventions and do not describe any actual security or compliance condition.
This document is not an official PCI DSS validation output. No formal PCI DSS validation activity — of any type, by any assessor — was undertaken in connection with this document. No Report on Compliance (ROC), Attestation of Compliance (AOC), Self-Assessment Questionnaire (SAQ), or other PCI DSS validation artifact was issued, and this document does not constitute or substitute for one. TMG Security does not represent itself as a PCI SSC-certified Qualified Security Assessor (QSA) company in connection with this sample document.
View the full sample PDF
The complete 33-page illustrative report, including the full requirement-by-requirement review, finding register, evidence register, and appendices.
Request a similar assessment
Preparing for a first, or a subsequent, PCI DSS validation engagement? TMG Security's GRC & Compliance team can scope a real PCI DSS readiness assessment built with the same structure, methodology, and reporting depth shown in this sample — scope definition, evidence and sampling review, requirement-by-requirement testing, a finding register, and a remediation roadmap your team can execute against. Not sure which framework applies to your organization? See how PCI DSS compares to other frameworks in TMG's ISO 27001 vs SOC 2 vs PCI DSS comparison guide.