Posted on by TBF_Shawn

Intro to PCI version 4: Requirement 12

We have come to the end of our PCI version 4 by requirement journey.  I know it has been a thrilling experience, full of ups and downs (mostly filled with bullet points, but whatever.)

Overall Thoughts

Requirement 12 has been the backbone of the PCI program management process.  The majority of the focus is on the management of processes, risk, and third parties.  In v4 this does not change, but there are some changes and updates worth mentioning.

What’s New for Req 12 in v4

The new controls in requirement 12 of v4 are:

  • 12.1.2 – So unlike all the other requirement updates, the SSC does not add in a new control for 12.1.2.  Then why do I mention it?  Only as an anchor to reference the lack of it, so you aren’t confused and thinking I forgot it (as if!)
  • 12.3.1 – A targeted risk analysis is documented to support each PCI DSS requirement that provides flexibility for how frequently it is performed.  Where TRAs are used, you need to determine the “R” and impact probabilities to use as the determining factor for how often you perform the TSA.  Some areas this might be annually and others it could be quarterly, monthly, or every couple of years.
  • 12.3.2 – A targeted risk analysis is performed for each PCI DSS requirement that is met with the customized approach. (ie – if you are going to use the customized approach towards compliance, you need a TRA for EACH control.  Not one per assessment, but one per control).
  • 12.3.3 – Cryptographic cipher suites and protocols in use are documented and reviewed. – Basically, you need to create an inventory type record of the different cipher suites and protocols in the environment, along with a review process to ensure that it is stays accurate.
  • 12.3.4 – Hardware and software technologies are reviewed. Be MORE proactive with your inventories and manage support contracts/models.
  • 12.5.2 – Requirement to document and confirm scope of PCI compliance annually. Prior to your PCI assessment, the company needs to review the cardholder data environment (CDE) to validate the scope is accurate.  This does not replace the scoping efforts required of the QSA but should make the process significantly easier (if done correctly).
  • 12.5.2.1 – PCI DSS scope is documented and confirmed at least once every six months and upon significant changes. Additional requirements for service providers.  In a nutshell this is the same as 12.5.2, but the frequency has changed.
  • 12.5.3 – The impact of significant organizational changes on PCI DSS scope is documented and reviewed and results are communicated to executive management. Another service provider control, focusing on changes to employee resources.  If administrative staff leave, document what was done to manage the impact to the environment.
  • 12.6.2 – The security awareness program is reviewed at least once every 12 months and updated as needed. On top of doing the required training within the company, you must also formally review the training program itself and document the process.  Looking to improve and make corrections that have such a major impact on the security culture of the company.
  • 12.6.3.1 – Security awareness training includes awareness of threats that could impact the security of the CDE, to include phishing and related attacks and social engineering. Adding in requirements for employees to be taught about the different entry points they have some form of risk associated to them.
  • 12.6.3.2 – Security awareness training includes awareness about acceptable use of end-user technologies. (Same as above, but different topics).
  • 12.9.2 – TPSPs support customers’ requests to provide PCI DSS compliance status and information about PCI DSS requirements that are the responsibility of the TPSP. This one is something I am glad about.  It is service provider only and requires for a process to provide the proof of compliance to your clients AND the ever-elusive Responsibility Matrix.  It is very common for me to have clients that can’t get this from their providers and must create one for themselves.  If the service provider doesn’t agree with what is written, this responsibility matrix isn’t worth much.
  • 12.10.4.1 – A targeted risk analysis is performed to determine frequency of periodic training for incident response personnel.
  • 12.10.5 – The security incident response plan includes alerts from the change- and tamper-detection mechanism for payment pages. The expansion of FIM, or something similar in functionality for payment pages.  Some could make the argument that even if you are using iFrames to outsource this, you should be monitoring the pages with the links to those as well, to prevent someone from changing that page and redirecting to their own iFrame for card capture.
  • 12.10.7 – Incident response procedures are in place and initiated upon detection of PAN.

Changes to 12 in v4

Requirement 12 changes/modifications are mostly focused on just providing additional details in what the expectations are going to be (along with the structural changes – of course).

  • 12 – Clarification/guidance – Updated principal requirement title to reflect that the focus is on organizational policies and programs that support information security.
  • 12.2 – Removed – Evolving Requirement – Removed requirement for a formal organization-wide risk assessment and replaced with specific targeted risk analyses (12.3.1 and 12.3.2).
  • 12.4 – Now 12.1.3 – Evolving Requirement – Added formal acknowledgment by personnel of their responsibilities. Executive management will now be required to sign a document confirming they are aware of their responsibilities.
  • 12.5 / 12.5.1 – 5 – Now 12.1.4 – Clarification/Guidance – Clarified that responsibilities are formally assigned to a Chief Information Security Officer or other knowledgeable member of executive management. Merged requirements for formally assigning responsibility for information security.
  • 12.3 / 12.3.1 – 9 – Now 12.2.1 – Clarification/Guidance – Clarified the intent of the requirement is for acceptable use policies for end-user technologies. Merged and removed requirements to focus on explicit management approval, acceptable uses of technologies, and a list of hardware and software products approved by the company for employee use.
  • 12.3.10 – Now 3.4.2 – Evolving Requirement – Removed requirement and added new Requirement 3.4.2 for technical controls to prevent copy and/or relocation of PAN when using remote-access technologies.
  • 12.11 / 12.11.1 – Now 12.4.2 / 12.4.2.1 – Structure/format – Moved requirements for reviews to confirm that personnel are performing PCI DSS tasks in accordance with policies and procedures under Requirement 12.4, to align with other requirements for managing PCI DSS compliance activities.
  • 2.4 – Now 12.5.1 – Structure/format – Moved under Requirement 12.5 to align with other requirements for documenting and validating PCI DSS scope.
  • 12.6 – Now 12.6.1 – Clarification/guidance – Clarified that the intent is that all personnel are aware of the entity’s information security policy and their role in protecting cardholder data.
  • 12.6.1 / 12.6.2 – Now 12.6.3 – Structure/format – Merged requirements for security awareness training.
  • 12.8 – Removed – Structure/format – Removed “null” requirement (all content pointed to other requirements).
  • 12.8.1 – 12.8.5 – Now the same – Clarification/guidance – Replaced “Service Provider” with Third-Party Service Provider (TPSP). Clarified that the use of a PCI DSS compliant TPSP does not make an entity PCI DSS compliant, nor does it remove the entity’s responsibility for its own PCI DSS compliance.  Clarified that where an entity has an agreement with a TPSP for meeting PCI DSS requirements on behalf of the entity, the entity must work with the TPSP to make sure the applicable PCI DSS requirements are met. If the TPSP does not meet those applicable PCI DSS requirements, then those requirements are also “not in place” for the entity. Clarified that the information about PCI DSS requirements managed by the TPSP and the entity should include any that are shared between the TPSP and the entity.
  • 12.10 – Removed – Structure/format – Replaced “system breach” and “compromise” with “suspected or confirmed security incident.”
  • 12.10.1 – Now Same – Clarification/guidance – Replaced “system breach” and “compromise” with “suspected or confirmed security incident.”
  • 12.10.3 – Now Same – Clarification/guidance – Replaced “alerts” with “suspected or confirmed security incidents.”
  • 12.10.4 – Now Same – Clarification/guidance – Replaced “system breach” with “suspected or confirmed security incidents.”
  • 12.10.5 / 11.1.2 / 11.5.1 – Now 12.10.5 – Evolving Requirement – Merged requirements and updated the security monitoring systems to be monitored and responded to as part of the incident response plan to include the following:
    • Detection of unauthorized wireless access points (former 11.1.2),
    • Change-detection mechanism for critical files (former 11.5.1),
    • New requirement bullet for use of a change- and tamper-detection mechanism for payment pages (relates to new requirement 11.6.1).
    • (This bullet is a best practice until 31 March 2025.)

Conclusion

If you have been involved in a PCI assessment and had the need to review the actual report on compliance (sorry for you on that), you have probably noticed that the majority of requirement 12 just reads as the name of the QSA doing the assessment.  “Provide the name of the assessor who confirms . . .)” So, it might see like there are a LOT of changes to a requirement that is just demonstrating compliance with someone’s name.  Well, the backend work that has to be done to get that signature has always been somewhat substantial, since 12 is all about the PCI program and management thereof.  When you look over the additions and changes you can see that from the perspective of the goals behind requirement 12 not much has changed.  It is still about focusing on making sure the PCI program within each entity is something that is proactive in its approach and not something designed solely to skirt security and do the least amount possible to get the AoC.

As always, I hope this tidbit of information gives you a base to have discussions with your internal subject matter experts and your trusted external sources for IT security and PCI knowledge.  Feel free to reach out to me directly with questions or to have a conversation via my email and/or social media information on the TBF website.  Thanks for taking the time to read my thoughts on PCI v4 Requirement 12.  We will continue to work through each of the PCI requirements each week.

~ Shawn