PCI DSS, scoped to the systems that touch card data
Twelve requirements, assessed against the systems that store, process or transmit cardholder data and everything connected to them. Scope is the whole game, so it lives as a decision recorded against real assets rather than as a diagram somebody redraws each year.
- Scope recorded against assets, not redrawn each year
- All twelve requirements, in their own numbering
- Quarterly scans and annual tests expire on their own clock
- The same evidence whether you file an SAQ or a ROC
PCI DSS
Organization-wide · 4.0 · 66 controls
PCI DSS coverage
- Published by
- PCI Security Standards Council
- Structure
- 12 requirements under 6 goals
- Validated by
- A QSA, or a self-assessment
- Cycle
- Annual, with quarterly scans
01
Adopt it, don't rebuild it
Adopt PCI DSS against a target rather than the whole company (the payments product, the environment that handles card data), so the boundary is a set of assets with a date on it instead of a slide. Segmentation shows up as assets left out, not as an assertion.
02
Evidence with a date on it
The requirements are dated by design: quarterly ASV scans, an annual penetration test, rule set reviews every six months. Each expires on its own clock and raises the task that renews it.
03
What the assessor leaves with
Your QSA sees the program scoped to PCI and to the dates of the assessment. Control status and evidence export for the Report on Compliance, or for the self-assessment questionnaire you are filling in yourself.
What you adopt
PCI DSS, in its own numbering
- Req 1Network security controls
- Req 2Secure configurations
- Req 3Protect stored account data
- Req 4Strong cryptography in transit
- Req 5Protect against malicious software
- Req 6Secure systems and software
- Req 7Access by business need to know
- Req 8Identify and authenticate users
- Req 9Restrict physical access
- Req 10Log and monitor all access
- Req 11Test security regularly
- Req 12Policies and programs
Twelve requirements under six goals, and every one of them assessed only against the systems your scope says are in.
What you show
What an assessor will ask to see
Network controls and segmentation
Requirement 1. Rule sets reviewed every six months, and segmentation proven rather than asserted.
No vendor defaults
Requirement 2. Hardening standards written down, applied, and shown to have been applied.
Stored and transmitted data
Requirements 3 and 4. What you keep, how long you keep it, and encryption on the wire and at rest.
Access on need to know
Requirements 7 and 8. Unique IDs, multi-factor authentication into the cardholder data environment, and reviews that remove people.
Logging and monitoring
Requirement 10. Twelve months of logs retained, with the most recent three immediately available for analysis.
Testing
Requirement 11. Quarterly scans by an approved scanning vendor, annual penetration testing, and the retests that closed what they found.
How it runs
Step 1
Adopt PCI DSS
Your organization gets its own copy of every control in PCI DSS, already mapped to the common controls you may satisfy for something else.
Step 2
Scope it
Organization-wide, or against a product, region or business line. Controls you scope out carry the reason you scoped them out.
Step 3
Collect the evidence
Connect a system or upload a document. Each piece is read, matched to the control it proves, dated, and given an expiry.
Step 4
Prove it
Invite your assessor to these frameworks and these dates, and nothing else. They leave with control status and evidence for the Report on Compliance, or for the SAQ you fill in yourself.
The standard
What PCI DSS asks for
PCI DSS is a contractual requirement from the card brands rather than a law, administered by the PCI Security Standards Council, and it reaches anyone who stores, processes or transmits cardholder data. Version 4.0 replaced 3.2.1 when that retired on 31 March 2024, and 4.0's future-dated requirements stopped being best practice and became mandatory on 31 March 2025.
Twelve requirements sit under six goals, running from network security and encryption through access control, logging and testing to the policy programme behind them. How you validate depends on volume and channel: most merchants complete the self-assessment questionnaire that matches how they take payments, and above the brand thresholds a Qualified Security Assessor performs an on-site assessment and issues a Report on Compliance.
Everything turns on scope. The cardholder data environment, plus every system connected to it or able to affect its security, is what gets assessed, and anything you can genuinely segment away is work you do not have to do. Which is why the argument is never about the twelve requirements. It is about which machines are in.
Questions
- Do we need a QSA, or is a self-assessment enough?
- That is decided by your transaction volume and by how you take payments, not by your tooling. Most merchants complete the SAQ that matches their channel; above the brand thresholds an on-site assessment and a Report on Compliance are required. Cyberwiz holds the same evidence either way.
- Does segmentation really reduce the work?
- Substantially, and it is the single biggest lever there is. Every system you can keep out of the cardholder data environment is a system the twelve requirements no longer apply to, which is why the asset register, and what it says is connected to what, is where a PCI program starts.
- Is 4.0 different enough from 3.2.1 to matter?
- Yes. It adds the customized approach, which lets you meet an objective a different way if you can document the reasoning, and it requires a targeted risk analysis behind several frequencies you used to be told. Both are documents with dates, which is what the program tracks.
Provable today, not at audit time.
Run it yourself or have Bindsec run it for you. Either way, the evidence is current and the posture is one place.