PCI compliance can be complicated, but if there’s one aspect that can feel especially time-consuming, it’s documentation.
I have some good news, though. If you’ve tackled PCI compliance in the past, you might remember that PCI DSS 2.0 wasn’t always clear on the kind of documentation needed. Because of this ambiguity, many people — such as auditors, QSAs or security professionals — had questions on just what they had to provide.
Luckily, PCI 3.0, 3.1 and 3.2 include additional detail. Instead of simply being told to document something, you’ll know what you need to document. Let’s look at the areas you’ll need to focus on thoroughly documenting.
Having defined and validated your CDE, you’ll need to document your work. That means network diagrams that outline connections and accurate diagrams of your cardholder data flows.
As you know from defining your CDE, creating an inventory of all relevant components is critical. You’ll need to include all security services and segmentation systems, virtualization and network components and server types; all internal and external applications should be in the mix as well.
Remember that you must describe your processes — their purposes and functions — and all relevant personnel, such as employees who process cardholder data or have access to cryptographic keys. Finally, remember this isn’t a one-time obligation. Your inventory must be accurate at all times.
Policies & Procedures
Here we’re talking specifically about your compliance policies, which are high-level statements concerning a particular area and the procedures you implement to carry out those policies.
Why does PCI ask for these? Because they want you to show that you understand the intent of PCI controls and have successfully implemented them within your environment.
We’ve talked about the importance of penetration (pen) testing to ensure your new controls are working as intended. As you may have guessed, this is something else you’ll need to document. PCI 3.0 and 3.1 required that you develop and document a pen-testing methodology that will validate your cardholder data environment (CDE) definition and segmentation controls. You will provide this to whomever will conduct your pen testing.
PCI 3.2 adds a new documentation requirement to your change control program. You must now add an analysis of the potential impact on PCI controls for every change within a CDE. This is not an insignificant addition as it will require work beyond documentation to implement an analysis process.
Risk assessments are important. To conduct yours, start by documenting how your organization handles cardholder data, then identify the risks you face.
After you’ve detailed every kind of threat (e.g., natural disasters, malicious human attacks and environmental threats), you’ll need to assign risk levels to each by assessing the likelihood of those threats occurring, as well as the severity of their impact. This means assessing the number of people impacted, the cost of the impact, and the impact to your brand reputation. Finally, you’ll create and implement risk mitigation strategies.
How does this relate to your PCI documentation? In addition to strengthening your security posture, a good risk assessment will generate much of the documentation PCI wants you to provide. Basically, by conducting a risk analysis, you’ll kill two security birds with one stone.