PCI DSS readiness

PCI DSS compliance is validated every year, either by a Qualified Security Assessor (Report on Compliance) or by a Self-Assessment Questionnaire, depending on your merchant or service-provider level, which the card brands and your acquirer set by transaction volume. The current version is PCI DSS v4.0.1; v4.0 was retired on 31 December 2024 and its future-dated requirements became mandatory on 31 March 2025.

Every entity that stores, processes or transmits cardholder data or sensitive authentication data, and any system that can affect their security. The cheapest control is scope reduction: hosted payment pages, hosted fields and tokenisation keep card data off your systems and can take you to SAQ A.

• Network and configuration (Req. 1–2). Network security controls around the cardholder data environment and secure configuration of every system component.
• Protect account data (Req. 3–4). Store as little account data as possible, never keep sensitive authentication data after authorisation, render PAN unreadable, and encrypt PAN over public networks.
• Vulnerability management (Req. 5–6). Anti-malware, secure software development, protection against common software attacks and management of payment-page scripts.
• Access control (Req. 7–9). Need-to-know access, strong authentication with MFA into the CDE, and physical access restrictions.
• Monitoring and testing (Req. 10–11). Audit logs for all access to cardholder data, log review, vulnerability scans, penetration tests and change detection on payment pages.
• Policy (Req. 12). Information security policy, risk analysis, security awareness, third-party service provider management and incident response.

13 RuleFix rules run when PCI DSS is selected on a project. 10 of the framework's controls have at least one rule mapped to them. The table is generated from the rule catalogue, so it always matches what the scanner runs.

A mapping means the rule checks part of that control in application code or configuration. Passing every rule does not satisfy a control: each one also needs process, people and infrastructure work that no code scanner can see.

Most of an audit is organisational. You need these in place regardless of what any scan finds:

• Network segmentation and firewalls. Requirement 1 and the segmentation testing that proves your scope.
• Anti-malware and physical security. Requirements 5 and 9.
• Log operations and testing. Daily log review, ASV scans, internal and external penetration tests (Requirements 10 and 11).
• Payment-page scripts. The script inventory and tamper detection of 6.4.3 and 11.6.1.
• Data at rest outside code. RuleFix reads code and config, not databases, file shares or backups — it is not a data-discovery tool for existing card data.
• Policies and providers. Requirement 12, including your list of third-party service providers and their responsibility matrix.

Select PCI DSS on each project in scope. Every scan then records findings with stable fingerprints. An issue becomes Fixed when a complete scan no longer finds it, when your agent resolves it with a confirming re-scan, or when a person marks it — and every status change is written to the audit log with who made it. The evidence report (print to PDF or JSON) collects the latest scan, score history, open and resolved findings and triage decisions per framework.

• Requirement 6.2.4 asks for software engineering techniques that prevent common attacks; RuleFix scans of every change, with findings fixed and verified by re-scan, are evidence for it.
• Card-number and CVV findings show that code does not log, store or hardcode PAN or CVV — useful when you argue that a system is out of scope or that SAD is not retained (3.3.1).
• Keep the evidence report for the assessment period with the rest of your Requirement 6 evidence; assessors can re-run a scan and compare fingerprints.

• Map every card data flow and decide whether a hosted payment page or hosted fields can take you out of scope.
• Confirm your merchant or service-provider level and validation method (SAQ type or ROC) with your acquirer.
• Turn on RuleFix with PCI DSS selected; clear every card-data, CVV, transport and crypto finding.
• Store tokens and last-four only; purge any PAN or CVV found in logs, seeds or backups.
• Enforce MFA into the cardholder data environment and 15-minute idle timeouts for CDE access.
• Set up the payment-page script inventory and change detection (6.4.3, 11.6.1).
• Book quarterly ASV scans and an annual penetration test.
• Collect your providers' Attestations of Compliance.