Five Things You Need to Start Right Now to Get Ready for PCI DSS v4.0
Posted by: Dan Mengel
The game, Mrs. Hudson, is ON!
Version 4.0 of the PCI DSS has been published, along with the Report on Compliance (ROC) and Self-Assessment Questionnaire (SAQ) templates, a bunch of blogs on the PCI Council Web site, and delta training for PCI Qualified Security Assessors (QSAs). Version 4.0 is a superset of the previous version, 3.2.1, under which entities can still attest compliance until March 31, 2024. For all the folks saying, “oh, we’ve got two years,”… I hate to burst your bubble, but six months are already gone. At what point do you have to submit strategic plans and budgets for 2023? And there is quite a bit of work that needs to be started immediately in order to have a chance of having all the required controls in place by that 2024 date–especially if you are even thinking about using the Customized Approach anywhere. Here are the five things you need to start TODAY:
1. Read the DSS and the applicable ROC and SAQ templates from top to bottom
I know this sounds very, um, elementary, but it continues to astonish me how many merchants and service providers have not done this. You simply cannot implement, maintain, and attest to a compliant environment when you don’t even know the specifics of what you are attesting to. The Council has wisely moved a great deal of content formerly provided as guidance/information supplements directly into the DSS, giving this content the force of requirement. This content includes:
- The relationship between PCI DSS and PCI SSC Software Standards (Section 3).
- Scoping and segmentation (Section 4).
- Third-party service providers (TPSPs) (Section 4).
- Definitions of timeframes (“quarterly,” “annually,” etc.) and “significant change” (Section 7).
- The all-important Glossary (Appendix G).
The Summary of Changes published by the Council is helpful, but a ton of content has been moved around and clarified (not to mention the addition of the Customized Approach objectives), and many terms have been clarified. Even the most experienced PCI professional should read through the docs from top to bottom. While you’re doing so, note the changes that will be impactful to the environments for which you are responsible or on which you will be assessing or advising. For example, guess which two significant requirements have been added to everyone’s favorite SAQ, SAQ A?
2. Implement your scope validation and documentation process
Requirement 12.5.2 mandates that an entity’s PCI DSS scope “is documented and confirmed by the entity [emphasis mine] at least once every 12 months and upon significant change to the in-scope environment.” Yes, that means you, not your assessor–although they still have to validate your scopeas part of your assessment, too. (If you’re a service provider, you get to do this every six months starting in 2025.) You also cannot be compliant if you do not know exactly where, when, and how you are storing account data or how you are affecting the security of same. Get your detective hat on and start deducing that scope; get help from your friendly neighborhood Watson (someone with an ISA or QSA certification, like a GuidePoint QSA).
3. Learn, socialize, and leverage your dates
Unlike in the Sherlock Holmes stories, time is not fluid and the clock is ticking. The Council has provided this timeline for the implementation of version 4.0 and the retirement of version 3.2.1:
Keep in mind that all version 4.0 requirements not marked as future-dated must be in place by March 31, 2024. Many requirements will require significant additional capital, operational, and personnel expenditures for successful implementation, maintenance, and documentation. Future-dated requirements must be in place by March 31, 2025, and it will be easier to budget for and build toward some of those requirements as part of your initial 4.0 push. Two examples are the targeted risk analysis process and the inventory maintenance process, which we’ll discuss in a moment. All of your stakeholders, from the board down to each individual system component owner, need to be aware of and involved in your project plan and the dates attached to same.
4. Implement your targeted risk analysis process
For each requirement using the term “periodically,” the entity must conduct and document a Targeted Risk Analysis (TRA) to determine and justify what the frequency of the required activity will be. Req. 12.3.1 describes the required components and documentation for the TRA process. While this requirement is technically future-dated, the term “periodically” appears in multiple requirements that are NOT future-dated, so you should really implement this process now and leverage it against those requirements to ensure there are no questions come assessment time. If you’re going to use the Customized Approach for any requirement, you’re going to need this process out of the gate anyway (see Req. 12.3.2 and our prior blog posts on this subject here and here).
5. Start building all inventories and maintenance processes for same
PCI DSS v4.0 requires (immediately or in 2025) that inventories of ALL the following items be developed, documented, and maintained by the entity. Some of these are new in v4.0 and will take considerable sleuthing and effort to identify and document.
- System components that are in scope (ALL components, not just “critical hardware and software”)
- Trusted keys and certificates used to protect PAN
- Bespoke and custom software AND any third-party software components incorporated into same
- Electronic media with cardholder data
- All payment page scripts, including justification for each
- Authorized wireless access points
- Cryptographic cipher suites and protocols in use
- (Service providers only) Hardware security modules, key management systems, and other cryptographic devices used for key management
Nervous yet, Sherlock? No worries. Start right now with these five tasks and you can solve the mystery of how to be compliant with PCI DSS v4.0 before your personal Moriarty (whether it be brand, acquirer, or third party) shows up asking questions you can’t answer.
Dan Mengel
Practice Director, Compliance,
GuidePoint Security
Dan Mengel, Practice Director at GuidePoint Security, began his career in the security industry in 2000. He has delivered high-quality consulting services, directly and by leading others, in the areas of information security program architecture, security policy development, and security vulnerability, risk, and compliance assessments. He has developed sales and delivery processes and documentation templates for all of these engagement types. Dan is currently leading GuidePoint’s Compliance team in delivering assessment and advisory services for multiple information security standards. He also has significant prior experience designing and integrating security technology solutions from Cisco, Check Point, Websense, RSA, and others.
Dan earned a Bachelor of Science degree in Computer Information Systems from Goldey-Beacom College and holds several recognized information security industry certifications.