PCI 3.0, Part 4: Documenting Your Compliance

PCI 3.0, Part 3: Validating Your Cardholder Data Environment

Summer is almost here, and that means many of you probably have made significant headway laying the groundwork for your 2015 PCI audit. However, one important aspect of 3.0 preparations that doesn’t always get the attention it should is documentation.

If you’ve tackled PCI compliance in the past, this is probably an area where you’ll have a few questions. Previous iterations of the PCI DSS requested documentation but weren’t always clear about the type and depth needed. For instance, while organizations knew they needed to document the log review process, they weren’t always sure how granular that documentation should be.

That kind of ambiguity inspired plenty of questions across all 12 standards and subsections — and auditors, security professionals, e-commerce merchants and the QSA community frequently went back to PCI asking for additional detail.

If this sounds familiar, here’s some good news: PCI 3.0 includes additional guidance right in the revised standards. Instead of simply advising to “develop appropriate documentation,” PCI has articulated what needs to be documented and how.

The Where, Why and How of Documentation

Data Flows

Defining your cardholder data environment, or CDE, is a critical part of transitioning to 3.0, and so is documenting the fruit of your work. Mapping the flow of cardholder data through your environment isn’t enough; you’ll also need to create network diagrams that outline connections and the path of the data.

If you’re using network segmentation to isolate cardholder data and reduce your compliance scope, you’ll need to document those boundaries to prove your segmentation methodology is working effectively. You must prove your data is in the right systems and nowhere else — and that means accurate diagrams of your cardholder data, or CHD, flows.

Pen Testing

One of the best ways to ensure your new controls are working is by running pen tests. Yes, this is something else that needs to be documented — but be aware that 3.0 requirements have specific guidelines on the type of pen-testing methodology you should use, such as one with both public-facing and administrative applications.

This applies both to internal methodologies and to those conducted by an outside vendor.

Inventories

One of the first tasks in getting ready for PCI 3.0 is identifying all people, processes and technology involved in your CDE. You’ll need to include all security services and segmentation systems, as well as virtualization and network components and server types. You’ll also need to account for all internal and external applications. Of course, it’s not just equipment; processes can shift, and staff with access to cryptographic keys and CHD can leave or change responsibilities.

Keep in mind that your inventory must be kept current and reflect all of these factors at any given moment. Furthermore, PCI’s actual standard states that the inventory must “include a description of function/use for each” — meaning you not only must list your components, but also describe their role in your environment.

Policies and Procedures

This is a part of documentation that often gets overlooked. Every workplace has policies and procedures, after all, but it’s important to understand their context in PCI compliance. In this instance, your compliance policies are high-level statements about a particular area, while your compliance procedures are practices that a particular department develops to implement those policies.

In all likelihood, the procedures will differ from department to department, and that’s fine, as long as they all comply with the policy. The role of this documentation? To demonstrate that you understand the intent of PCI controls and have created procedures that successfully implement those controls within your environment.

Risk Assessments

Many organizations fail to conduct good risk assessments, which is unfortunate, as they can strengthen your security posture while creating much of the evidence PCI wants you to provide. To conduct yours, you should start by documenting how your organization creates, accesses and stores cardholder data, and then identify the risks you face.

After you’ve detailed every kind of threat — including 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 and the potential severity of their impact.

Consider all aspects of the potential damage, including the number of people impacted, the financial cost of the impact, and, of course, the impact to your reputation. Finally, you’ll need to create and implement risk mitigation strategies.

Stronger Security

PCI documentation may seem fairly simple, but it is an important part of achieving compliance.

Like most tasks you’ll undertake for PCI 3.0, documentation isn’t merely an obligation to be met — it’s also a helpful step toward clarifying and improving your own security program.

Stay tuned for PCI 3.0, Part 5.