I am sure many of you are reading this title thinking "what is he talking about, v3.2 went live ages ago" and you would be correct, however version 3.2 of the PCI DSS continues with the concept of future requirements, meaning the one year countdown to the 31st January 2018 has begun.
Save the date
The PCI Security Standards Council introduced nine requirements in PCI DSS v3.2 which are best practice until 31st January 2018, after which time they become mandatory.
Now let’s be realistic, the majority of merchants and service providers are going to treat 'best practice' as 'optional' until they undergo an assessment after 31st January 2018; but please don't wait. Compliance is not just the assessment with the Qualified Security Assessor (QSA); we should be striving to meet every requirement, at all times and they must be in place by the 31st January 2018 even if your assessment is not until after that date.
Do I need to do something now?
YES! The majority of these future dated requirements are for Service Providers, so if you choose to postpone doing something about them now, this is going to be highlighted in your Attestation of Compliance.
In this hyper-competitive world, can you afford to show this to your clients and the payment brands? Will it make the difference when touting your wares? If I was looking for a service provider, part of my due diligence requirement (12.8.3) would be to see how you're doing with your future dated requirements.
Don’t forget, you have not only got these requirements going mandatory, you may also have the GDPR on the horizon too. So let’s get planning.
What are the requirements?
The table below was compiled from the PCI DSS v3.2, so be sure to get the full requirements from there:
| Requirement | Details | Service Provider only? |
| 3.5.1 | Maintain a documented description of the cryptographic architecture. | Yes |
| 6.4.6 | Upon completion of a significant change, all relevant PCI DSS requirements must be implemented on all new or changed systems and networks, and documentation updated as applicable. | No |
| 8.3.1 | Incorporate multi-factor authentication for all non-console access into the CDE for personnel with administrative access. | No |
| 10.8 | Implement a process for the timely detection and reporting of failures of critical security control systems. | Yes |
| 10.8.1 | Respond to failures of any critical security controls in a timely manner. | Yes |
| 11.3.4.1 | If segmentation is used, confirm PCI DSS scope by performing penetration testing on segmentation controls at least every six months and after any changes to segmentation controls/methods. | Yes |
| 12.4.1 | Executive management shall establish responsibility for the protection of cardholder data and a PCI DSS compliance program. | Yes |
| 12.11 | Perform reviews at least quarterly to confirm personnel are following security policies and operational procedures. | Yes |
| 12.11.1 | Maintain documentation of quarterly review process to include: - Documenting results of the reviews - Review and sign-off of results by personnel assigned responsibility for the PCI DSS compliance program. | Yes |
…and that means I have to do what?
Some of these requirements are nothing but forcing you to employ good practice. On first look this seems cheeky perhaps, but if it is good practice you can hopefully already demonstrate this either within your self-assessment or to your QSA.
3.5.1 – Documenting your cryptography
This is not a daunting as you might think. It is only going to apply to your organisation if you are storing encrypted cardholder data, and if you are a service provider; so you might be off the hook already. Pragmatically, this is only an extension of 3.6 so review that documentation and add details accordingly.
6.4.6 – This is an extension of change control
Possibly the EASIEST of the future dated requirements. Why you say? Because it is just good change management. If you are achieving a good change management posture, this goes without saying that you will be ensuring that PCI DSS compliance is being maintained on all changes, let alone those deemed ‘significant’.
Review the process, insert a reminder/action/decision point to say “Is this significant? Was all affected documentation from this change updated appropriately” and record.
8.3.1 – Multi-factor Authentication for Non-Console Administration
This could be an awkward one. Here’s the problem for Admin’s – sitting at the machine in the CDE, don’t need MFA to logon (but I won’t complain if you have it!). Sitting elsewhere and connecting to the CDE to administrate it, you will need something. Start planning now if this is not in place as it will affect a number of requirements and likely to attract the attention of 6.4.6 above.
10.8 & 10.8.1 – Find out that it is broken, why it happened and fix it without delay
This one is for service providers only - but once again I will not object to Merchants doing it too! You need to show how you are monitoring the monitoring systems for failure. This can go hand in hand with testing your incident management processes, particularly for things which do not get tested on a daily basis. Work out a control test to apply to each of those system where appropriate. If the monitoring processes do their job, you will not only be giving yourself evidence of testing the incident management plan, but you have checked the monitoring systems itself is working
11.3.4.1 – Segmentation Testing
This is a recurring activity to test your segmentation, only for service providers too. Check the requirements in the standards and have it done, either by an independent qualified resource, or engage the services of a penetration testing company.
12.4.1 – Executive Management and a PCI Charter
This is new, and not entirely unfamiliar. If you are running an ISO 27001 ISMS, you will know about Top Level Management needing to be part and parcel of the programme. A RACI matrix here will help, along with keeping top management in the loop; this requirement is a good place to start if you have not already.
12.11 & 12.11.1 – Perform reviews
Again, this is not a new idea but a real boost for maintaining compliance. Thinking again about ISO 27001, you are doing internal auditing as that is mandatory, then it is a control to go into your management system and you are covered. It is about assessing that you are performing BAU activities and can evidence this, so some evidence that change controls and BAU activities were observed in place and effective and that documentation evidence exists of such a review.
So it is all quite straightforward?
Yes - a general review of your day to day activities is going to ‘smash these out of the park’. And if you are struggling with where to start, contact your QSA Company for assistance; they will be happy to help.
If you have done nothing yet, please try and minimise your delay. Also, remember that these are all requirements designed to minimise risks, so pop an entry into your risk log (requirement 12.2) and as you work through them, drop them off; the assessment process will love you for it!
P.S. Save the Date – 31st January 2018, not only is it a significant day for PCI DSS, it is also a total lunar eclipse and in the UK we sadly don’t get to see too much of it.
To contact Nettitude's editor, please email media@nettitude.com.
