Your acquiring bank wants proof of PCI DSS compliance, a partner’s contract requires a current Attestation of Compliance, or your payment volume just moved you to a Report on Compliance. PCI DSS v4.0.1 is detailed and unforgiving about scope. Readiness shrinks your cardholder data environment where it can, closes the gaps against the requirements that remain, and prepares you for the Qualified Security Assessor or the Self-Assessment Questionnaire your acquirer requires.
PCI DSS is the data security standard maintained by the PCI Security Standards Council and enforced by the payment card brands and acquiring banks. It applies to any entity that stores, processes or transmits cardholder data or sensitive authentication data, and to any system that can affect the security of that environment. Version 4.0.1 is the current version, and the requirements that v4.0 introduced as future-dated are now in force.
How you validate depends on your merchant or service provider level, which the card brands and your acquirer set. The largest merchants and service providers need a Report on Compliance completed by a Qualified Security Assessor. Others complete the Self-Assessment Questionnaire that matches how they accept payments, from SAQ A for fully outsourced e-commerce to SAQ D for everything else. Either way, you sign an Attestation of Compliance that your acquirer and customers rely on.
The costliest PCI mistake is scope. Every system in or connected to the cardholder data environment is in scope unless segmentation proves otherwise. Readiness is grounded in where card data actually flows and in reducing that footprint — tokenization, hosted payment pages, point-to-point encryption, network segmentation — so you don’t spend effort securing and validating systems that never needed to be in scope.
You use a hosted payment page or embedded payment fields and assume you are out of scope. Since v4.0, the scripts on and around your payment pages matter, and the SAQ you’re eligible for depends on exactly how your checkout is built and protected.
Processors, gateways, payment facilitators, hosting providers and SaaS platforms that touch card data or can affect its security. Your customers need your AOC and a clear responsibility matrix for their own assessments.
Growth or a new acquirer requirement has moved you from an SAQ to a QSA assessment. Readiness shows where practices that passed self-assessment won’t survive a QSA’s sampling and interviews.
You meet a requirement’s objective in a different way. The customized approach allows that, but it demands a controls matrix and a targeted risk analysis for every customized control.
A Qualified Security Assessor (Report on Compliance) or your own organization (Self-Assessment Questionnaire), as your acquirer or the card brands require
Report on Compliance or Self-Assessment Questionnaire, with a signed Attestation of Compliance
CyberlySecure is not a QSA and not an Approved Scanning Vendor. We prepare your environment, documentation and testing evidence; the QSA you engage, or your own signed SAQ, provides the formal validation, and an ASV of your choice runs the external scans the standard requires.
Diagrams of how card data enters, moves through and leaves your environment, with an inventory of in-scope and connected system components — the scoping evidence a QSA will start from.
Concrete options to take systems, networks and people out of scope, with the trade-offs of each, so you secure less and validate less.
A clear answer on which SAQ applies to each payment channel, or, for a Report on Compliance, how ready each requirement is for QSA testing.
Your status against each applicable PCI DSS v4.0.1 requirement, including those that were future-dated in v4.0, with what closing each gap takes.
Written targeted risk analyses for the requirements that let you set your own frequency, and for any control you meet through the customized approach.
The documented policies and operational procedures each requirement calls for, plus a responsibility matrix showing which requirements you, your service providers and your customers each own.
Internal and external penetration tests and segmentation testing against a documented methodology, with retesting of exploitable findings, as Requirement 11.4 calls for.
Help closing gaps before your QSA arrives or before you sign your SAQ, from multi-factor authentication and logging to service provider agreements and payment page script controls.
Better found now, by people on your side, than by your assessor.
A cardholder data environment boundary that has never been documented or formally confirmed
Flat networks where segmentation is assumed but has never been tested
No inventory or authorization of the scripts running on payment pages
Multi-factor authentication on remote access but not on all access into the cardholder data environment
Requirements with entity-defined frequencies and no targeted risk analysis behind them
Service provider agreements that don’t say which PCI DSS requirements each party is responsible for
Penetration tests that cover the external perimeter but not the internal network or the segmentation controls
Card data turning up in logs, support tickets or spreadsheets outside the intended environment
Requirement 11.4.3 calls for external penetration testing at least annually and after any significant infrastructure or application upgrade or change.
What the test coversRequirement 11.4.2 calls for internal penetration testing on the same basis, covering the cardholder data environment perimeter and critical systems.
What the test coversIf segmentation reduces your scope, Requirements 11.4.5 and 11.4.6 call for testing that it works — at least annually for merchants, and more often for service providers.
What the test coversRequirement 11.4.1 defines penetration testing to include the application layer, and e-commerce checkouts and payment applications are exactly where attackers aim.
What the test coversPayment APIs and integrations with gateways and processors are part of the application layer an assessor expects to see tested.
What the test coversRequirement 11.3.1 calls for internal vulnerability scans on the schedule the standard sets. External scans under 11.3.2 must come from an Approved Scanning Vendor, which CyberlySecure is not.
What the test coversRequirement 11.2 calls for finding and identifying every wireless access point, authorized or not, and wireless that touches the cardholder data environment has its own configuration rules; a wireless test shows whether a rogue or weak network gives a way in.
What the test coversPayment and point-of-sale software running on workstations sits inside the cardholder data environment; testing the client application shows whether card data or keys can be pulled from the device itself.
What the test coversNo. CyberlySecure is neither a Qualified Security Assessor nor an Approved Scanning Vendor, and we don’t sign Reports on Compliance or Attestations of Compliance. We do the preparation and the penetration and segmentation testing the standard calls for. Your QSA validates, and an ASV runs your external vulnerability scans.
It depends on how each payment channel works. A fully outsourced e-commerce checkout may qualify for SAQ A; a website that controls how card data reaches the processor points toward SAQ A-EP; standalone terminals, validated P2PE solutions and virtual terminals each have their own SAQ; and anything else, including service providers eligible to self-assess, falls to SAQ D. Your acquirer has the final say, and choosing the wrong SAQ is a common reason a self-assessment fails to hold up.
Version 4.0 introduced the customized approach and targeted risk analyses, extended multi-factor authentication to all access into the cardholder data environment, added payment page script controls, and strengthened requirements for passwords, phishing protection and log review. Many of those requirements were future-dated and are now mandatory. Version 4.0.1 is a limited revision that clarified wording and guidance. If your program was built for v3.2.1, expect real work.
Usually, yes. Tokenization, hosted payment pages or iframes from your processor, validated point-to-point encryption and network segmentation can each take systems out of scope. Every option has conditions: segmentation has to be tested, and outsourcing the payment form still leaves you responsible for the page that hosts it. Readiness tells you which options fit your architecture and what each one leaves in scope.
It lets you meet a requirement’s stated objective with a control that differs from the defined requirement. You document a controls matrix and a targeted risk analysis for each customized control, and your QSA derives specific testing procedures for it. It isn’t available through a Self-Assessment Questionnaire, and it suits mature environments rather than serving as a shortcut.
PCI DSS calls for penetration testing by a qualified internal resource or a qualified external third party with organizational independence, following a defined methodology. It doesn’t require the tester to be a QSA or an ASV. Your QSA reviews the methodology, scope, results and retesting, so the testing is planned to meet Requirement 11.4.1 from the outset.
One conversation with someone who does this work. You leave knowing where you likely stand and what readiness would involve for you.
Not sure where to start? One of our testers reviews your internet-facing footprint and sends you a short summary of what an attacker would see — free. Nothing you don’t own is ever touched, and there’s no sales sequence.
Free. No obligation.
