PCI DSS 4.0 – What You Need to Know About INFI Worksheets
Posted by: Dan Mengel
Consistently maintaining compliance with any cyber security standard, especially a more prescriptive one like the PCI Data Security Standard (DSS), is challenging for any organization. Like many aspects of an organization, if compliance is not built into “business as usual” – i.e., emphasized as a necessary component of operations and given corresponding priority, time, and resources accordingly – balls get dropped. The PCI Security Standards Council (SSC) has emphasized the necessity of continuous compliance to minimize risks to account data; this is reflected in both the DSS itself, with its recurring-activity requirements that must be executed throughout the year, and the Items Noted for Improvement (INFI) initiative.
When the SSC first published version 4.0 of the PCI DSS, the corresponding reporting templates included an option to indicate a requirement is “In Place with Remediation”, joining “In Place,” “Not In Place,” “Not Tested,” and “Not Applicable.” The intent was to capture and document a more complete picture of the entity’s status and risk level relative to account data – not just at the time of the assessment, but stretching into the prior year. Based on industry feedback, the SSC has removed this option from those templates and has instead developed a separate template called an Items Noted for Improvement (INFI) Worksheet. The SSC is mandating that an INFI be completed as part of all PCI DSS 4.0 assessments resulting in a Report on Compliance (ROC) and recommends (but does not mandate) that an INFI be completed as part of an assessment resulting in a Self-Assessment Questionnaire (SAQ). The INFI is “intended to help entities better understand their security posture, improve their security processes and controls, and identify areas for improvement as they work towards security as a continuous process” (INFI, p. 2).
The INFI provides a mechanism for an entity to be compliant even if a non-compliant condition is identified during the assessment – provided that they have addressed the root cause of the issue that caused the non-compliant condition and taken provable steps to ensure the issue does not happen again. This proviso cannot be overemphasized. The INFI Introduction clearly lays out the ground rules:
It is common during a PCI DSS assessment for the assessor to identify PCI DSS requirements that are not fully in place or security controls that have not been consistently maintained in accordance with a requirement. When this occurs, and if the entity has implemented corrective action to successfully address the identified issues prior to completion of the assessment, the assessor can reassess the controls to determine whether the requirement is now fully in place.
Items identified as needing corrective action may be considered In Place only after the assessor has verified that the reason for the failure has been addressed, and that controls and processes intended to both prevent reoccurrence of the failure and fully meet the requirement have been implemented.
This approach is further reinforced by FAQ 1572 on the SSC’s Web site. This FAQ is specific to recurring requirements but, like the vast majority of the FAQs, shines a light on the Council’s thinking. Under previous versions of the PCI DSS, if a recurring requirement was missed at any point during the year prior to a formal assessment (such as a quarterly vulnerability scan), it was technically not possible for an organization to be fully PCI-compliant until the recurring requirements were fulfilled in their entirety for a full-year period. The INFI provides a way for entities to be compliant despite such an issue having occurred in the past.
Some organizations may look at the INFI solely as a written record of their failings related to PCI compliance over a period of time, which is not something many organizations want documented, especially if the condition was corrected sufficiently that a Compliant attestation document was the eventual outcome. However, the INFI is much more than that; download it from the Council site and take a close look at page 7, which is the actual worksheet itself. The data that must be captured on the INFI includes not just the issue and the cause of failure, but also the corrective and preventive actions taken to ensure the issue does not occur again in the future. This showcases the entity’s ability to course-correct and learn from previous issues and demonstrates the entity is taking the compliance requirement seriously. The assessed entity can leverage this documented record to ensure the corrective and preventive actions remain effective going forward.
It should also be noted that the INFI is “intended for internal use between the assessor and the assessed entity” (INFI, p. 2). It is not provided to any other entity, including acquirers, payment brands, etc., by default. These entities could request the document, but there is no contractual requirement to do so under the PCI framework. Legal counsel should be consulted to determine if the document would be discoverable in a legal situation and under what conditions this might occur.
We are now less than seven months from saying goodbye to version 3.2.1 of the DSS and fully embracing version 4.0. Now is the time to do so. Consult with your GuidePoint QSA to determine the impact of version 4.0 and plan resourcing accordingly to adjust to applicable new and/or updated requirements. As part of this planning, keep in mind that, if you are required to obtain a v4.0 ROC, an INFI will accompany it.
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.