Preparing for a PCI DSS Audit

An audit of your cybersecurity according to the Payment Card Industry Data Security Standard (PCI DSS) is a complicated but necessary procedure for modern commerce. While PCI data security can be confusing at first, it’s vital to protect your customers’ sensitive data from theft and your organization from potential penalties and lawsuits.

Whether you’re submitting to an external audit from a qualified security assessor (QSA) or performing a self-assessment questionnaire (SAQ), you can prepare for a successful audit in four steps: examine the PCI requirements; determine the scope of your network; build a system of record; and test your existing controls.

Determine the Applicability of Requirements

The PCI DSS requirements were designed by the major payment card service providers to create a system where any company that handles cardholder data can demonstrate compliance. As such, not every requirement will apply to every business. The size of your company, the volume of your annual credit card transactions, and the systems you use to process credit card data are all factors that determine which PCI DSS guidelines will apply to your specific business. Non-compliance with these guidelines can cause your credit card processing privileges to be revoked, so knowing which compliance requirements apply to your organization is critical.

The PCI framework is complex at first glance but becomes easier to navigate once you study it. There are four merchant levels as determined by the PCI Security Standards Council (PCI SSC), which are grouped by annual volume of credit card transactions; companies with more transactions are subject to more requirements. There are 12 primary requirements:

1. Protect cardholder data (CHD) with well-maintained firewalls. 
2. Don’t use default passwords or security measures.
3. Make sure that any CHD you store is also protected.
4. CHD should be encrypted across open networks.
5. Install anti-virus programs and protections against malware. 
6. Confirm that all systems and applications are secure. 
7. Allow staff to access CHD only on a need-to-know basis.
8. Create unique IDs and passwords for any employee who needs to access CHD.
9. Minimize physical access to CHD whenever possible. 
10. Assure that all access to CHD and the network is tracked and monitored.
11. Test all systems and controls regularly. 
12. Train all staff to be aware of the importance of information security and the controls that are in place. 

Within these 12 requirements are 251 sub-requirements—but not every sub-requirement applies to every business that handles CHD. It’s important to know before your audit what specific requirements your business will need to satisfy to prove compliance. By determining your merchant level and examining the requirements before your audit, you can narrow your focus and save time moving forward.

Determine Network Scope and Reduce Where Possible

The scope of your audit is defined by how much of your network processes, transmits, or stores cardholder data. Any server, point-of-sale system, mobile device, or computer that accesses cardholder information is considered in scope; so are any web applications that are connected to these devices. The more devices and applications within your scope, the more vulnerable you are to a potential data breach.  

One way to your scope is through network segmentation. Network segmentation uses firewalls to separate the PCI portions of your company’s network from other necessary devices and applications. This separation makes it much easier (and cheaper) to maintain PCI compliance. Another way to reduce scope is to avoid storing cardholder data whenever possible. Data storage increases the number of devices that have access to CHD and creates more of a compliance burden. So the less cardholder data you store, the fewer devices are within the scope of the PCI DSS audit. 

Wireless networks can be a particular point of contention for PCI compliance. Minimize the number of wireless networks that are integrated with your cardholder data environment (CDE), leaving only those that are necessary for processing transactions. You can also implement point-to-point encryption (P2PE), which renders cardholder data unreadable once it has been processed—which, in turn, leaves point-of-sale devices out of scope.

Building Your System of Record

A System of Record (SOR) refers to a storage system for information that is the definitive, most accurate source for a particular data element. In our PCI context, your System of Record documents your network configuration, the PCI controls you have in place, and the ways in which you audit those controls. By examining these controls beforehand and creating a system of record, you can locate opportunities to further minimize your audit scope and prepare for any documentation you might need moving forward. 

A good way to minimize your scope before an audit is to identify common controls between sites or facilities. Any controls that apply to multiple branches of your CDE can be tested once, saving time overall. Controls that apply only to a particular portion of your security system will need to be tested separately. 

Larger companies may need to submit a Report on Compliance (RoC), which isn’t required of organizations with fewer transactions. Your System of Record can be useful for your PCI system assessor, who will need to prove your organization’s compliance after your audit.

Test Your Existing PCI Controls

The criteria for testing have been defined by the PCI DSS, and it may be less challenging than you might expect. The testing procedures include a description of each requirement, how it should be tested, and what constitutes acceptable evidence of compliance. You can use this information to prepare for your audit by determining what areas of your system might need more attention, and which areas are already compliant. 

PCI DSS compliance also requires penetration testing, a process that actively searches for security vulnerabilities in your system that could be exploited. Because penetration testing can disrupt your day-to-day processes, it’s important to set aside appropriate time for these tests or to create an environment specifically for testing that accurately reflects the system components of your actual CDE.

Information security is complex, but a security audit doesn’t need to be an overwhelming experience. Security awareness and a secure network can go a long way towards making a PCI audit easier. By examining the requirements and your existing controls in advance, you can ensure that your security policies are effective and that your PCI audit will be as smooth as possible.