PCI DSS Report

The PCI DSS Compliance Report is the most compliance-specific deliverable Ethiack produces. It maps every finding to the specific PCI DSS requirement numbers it violates, making it the correct document to present to a QSA (Qualified Security Assessor), payment processor, or internal compliance team during a PCI audit.

Findings are tagged not just with a CWE and CVSS score but with the exact PCI DSS control IDs. A single finding can fail multiple requirements simultaneously — for example, a misconfigured monitoring platform may simultaneously violate system hardening, change management, access control, user identity management, strong authentication, MFA, and application account security requirements.

It is classified TLP:AMBER and should be treated with the same confidentiality as all other reports from the same engagement.

What is PCI DSS?

PCI DSS (Payment Card Industry Data Security Standard) is a security framework specifically designed for organizations that handle, process, store, or transmit payment card data. It is mandated by the major card networks and enforced through contractual requirements with payment processors and acquirers. Non-compliance can result in fines, increased transaction fees, or loss of the ability to accept card payments entirely.

Unlike OWASP frameworks, which are general web security standards, PCI DSS is directly tied to the cardholder data environment (CDE) and carries legal and contractual weight for any organization with an e-commerce or payment processing component.

How it differs from the other reports

The PCI DSS Report is the most structurally distinctive of all Ethiack's deliverables:

• PCI DSS control IDs are the primary organising principle — every finding entry lists which controls are violated with their full requirement text, making the report self-contained for compliance purposes. A reader does not need a separate copy of the PCI DSS standard to understand what rule was broken.
• A single finding can fail many controls simultaneously — this multi-control mapping is unique to this report format and reflects the interconnected nature of PCI DSS requirements.
• Section 4 — Retesting Requirements — exists only here — this section provides per-severity SLAs for verifying that remediations have been completed, along with specific validation procedures and evidence requirements for each finding type. This is essential for PCI audit closure documentation.
• The Compliance at a Glance table is PCI-specific — the Executive Summary shows a table of PCI DSS control numbers with their finding counts and severity breakdowns, immediately readable for a compliance officer scanning for control gaps.
• Clean controls are explicitly stated — controls tested with no findings are explicitly called out, providing audit attestation that those controls were assessed and passed.

Report structure

1. Executive Summary

1.1 Overview frames the assessment explicitly around PCI DSS compliance. It directly states the purpose is to evaluate whether the organization can protect payment card data and names the potential consequences of the findings: non-compliance with PCI DSS requirements, data breaches, and regulatory penalties. This framing positions security issues not as abstract technical risks but as compliance failures with direct business and legal consequences.

1.2 Compliance at a Glance is the PCI-specific dashboard. It lists each triggered PCI DSS control ID with its finding counts and severities. The cluster of failures typically seen around requirements 7 and 8 (access control and authentication) reflects that access and authentication issues are fundamentally compliance failures in PCI's view, not just information disclosure issues.

1.3 Key Findings is a priority table showing high-severity findings mapped to their PCI DSS controls — the page a compliance officer or QSA is most likely to reference first.

1.4 Overall Posture and Business Impact is the most payment-specific narrative in any of Ethiack's reports. It explicitly connects vulnerabilities to cardholder data risk and calls on executive leadership to prioritise resource allocation — language calibrated for the board or C-suite audience that typically owns PCI compliance.

2. Scope Summary

Standard content: in-scope assets, out-of-scope assets, constraints, coverage ratio, and limitations.

3. Detailed report

Each finding is presented with its PCI DSS requirement(s) listed prominently at the top, followed by the standard finding structure (severity, asset, CWE, CVE/EPSS if applicable, description, steps to reproduce, evidence, impact, and mitigations). The full requirement text is written out — not just the number — so a reader can understand the compliance gap without looking up the standard.

Findings not mapped to any control — a dedicated section captures findings that could not be mapped to specific PCI DSS controls. This is an honest reflection of a genuine gap in PCI DSS's framework: injection and input validation vulnerabilities are implicitly required to be addressed but are not mapped to specific numbered controls in the same way authentication requirements are.

4. Results summary and retesting requirements

This section is unique to the PCI DSS Report and the most operationally useful section for compliance teams managing remediation.

4.1 Summary consolidates the finding count across PCI DSS controls and explicitly identifies the most critical concerns from a payment data security perspective.

4.2 Retesting Requirements provides a structured remediation validation framework that is absent from all other reports. It defines:

• Retesting SLAs by severity — Critical within 24–48 hours, High within 1 week, Medium within 2–4 weeks, Low within 30–60 days
• Validation approach per tier — full re-assessment with proof-of-concept verification for Critical; targeted testing with evidence collection for High; verification testing with configuration review for Medium
• Per-finding validation procedures — specific steps for verifying each finding type has been remediated
• Evidence requirements — what artefacts must be collected and documented to consider a finding closed for audit purposes

This section transforms the report from a point-in-time assessment into a remediation governance document that can be tracked through closure.

Appendices

Appendix A — Severity and Risk Rating Explanations covers CVSS severity ranges including a Cosmic tier (for CISA KEV-listed actively exploited vulnerabilities that sit above Critical), EPSS, and the organisational Risk Rating methodology.

Appendix B — Out-of-Scope Assets: The full list of excluded assets for traceability.

Appendix C — Methodology: The full test coverage list explicitly framed as aligning with PCI DSS requirements for penetration testing.

Value this report delivers

The PCI DSS Report is the correct document to use when demonstrating security assessment coverage to a payment industry audience. It enables:

• Providing a QSA with evidence of which PCI DSS controls were tested, which passed, and which failed — reducing the scope of on-site assessment work
• Prioritising remediation in the language of compliance obligations rather than generic security risk, which resonates with finance and legal stakeholders who own PCI compliance
• Using the Retesting Requirements section as a formal remediation tracking document with evidence requirements suitable for audit closure
• Demonstrating to payment processors or card brands that identified gaps are being actively managed with documented timelines
• Explaining to leadership why a single misconfiguration can simultaneously resolve failures across multiple PCI DSS requirements