Learning Center Home > Guide > SecurityMetrics Guide to PCI DSS Compliance

SecurityMetrics Guide to PCI DSS Compliance


A Resource for Merchants and Service Providers to Become Compliant

This post contains part of the text from the SecurityMetrics Guide to PCI Compliance. To view the full text, download the PDF below.

Download the latest guide to PCI compliance

Download Now


No matter the advances in cyber security technology and despite government initiatives and regulations, attackers will continue to steal unprotected payment card data.

Some organizations have simple, easy-to-correct vulnerabilities that lead to data breaches. In other instances, organizations with intricate IT defenses and processes are overridden by an employee opening a phishing email.

Our guide was specifically created to help merchants and service providers address the most problematic issues within the 12 PCI DSS requirements, including auditors’ best practices and IT checklists.

Rather than reading this guide cover to cover, we recommend using it as a resource for your PCI compliance efforts.

Ultimately, our goal is to help you better protect your data from inevitable future attacks.



SecurityMetrics Audit Director


The information described in this guide is presented as a reference and is not intended to replace security assessments, tests, and services performed by qualified security professionals. Users are encouraged to consult with their companies’ IT professionals to determine their needs to procure security services tailored to those needs.

Download the latest guide to PCI compliance

Download Now







Whether you’re a new employee with limited PCI knowledge or an experienced system administrator, our guide aims to help you secure your environment and for your organization to become compliant with PCI DSS requirements. We specifically designed this document as a reference guide to address the most challenging aspects of PCI DSS compliance.

Depending on your background, job role, and your organization’s needs, some sections may be more useful than others. Rather than reading our guide cover to cover, we recommend using it as a resource for your PCI compliance efforts.

The chart below displays an overview of the PCI Security Standards Council’s Prioritized Approach. The Prioritized Approach offers organizations a risk-based roadmap to address issues on a priority basis, while also supporting organizational financial and operational planning.

The Prioritized Approach is broken down into the following six milestones (based on high-level compliance and security goals):

Remove sensitive authentication data and limit data retention
Protect systems and networks, and be prepared to respond to a system breach
Secure payment card applications
Monitor and control access to your systems
Protect stored cardholder data
Finalize compliance efforts, and ensure all controls are in place



The Payment Card Industry Data Security Standard (PCI DSS) was established in 2006 by the major card brands (e.g., Visa, MasterCard, American Express, Discover Financial Services, and JCB International).

All businesses that process, store, or transmit payment card data are required to implement the security standard to prevent cardholder data theft. The investigation of numerous credit card data compromises has confirmed that the security controls and processes required in the PCI DSS are essential to protecting cardholder data.

Merchants often have a difficult time attaining (or maintaining) compliance for a variety of reasons. Many smaller merchants believe it’s too technical or costly, while others simply don’t believe it’s effective and refuse to comply. In fact, our data concluded that the average breached organization at the time of data compromise was not compliant with at least 44% of the PCI DSS requirements.

None of the organizations SecurityMetrics investigated in 2019 were found to be fully PCI DSS compliant at the time they experienced a data breach.

Download the latest guide to PCI compliance

Download Now



  • Install a hardware and software firewall

  • Tweak firewall configuration for your system

  • Have strict firewall rules



  • Avoid using default passwords

  • Harden your systems

  • Implement system configuration management



  • Encrypt stored card data

  • Find where card data is held

  • Craft your card flow diagram



  • Know where data is transmitted and received

  • Encrypt all transmitted cardholder data

  • Stop using SSL and early TLS


  • Create a vulnerability management plan

  • Regularly update anti-virus

  • Maintain an up-to-date malware program



  • Consistently update your systems

  • Patch all critical systems and software

  • Establish software development processes



  • Restrict access to cardholder data

  • Document who has access to the card data environment

  • Establish an access control system



  • Use unique ID credentials for every employee

  • Change ID credentials

  • Configure multi-factor authentication


  • Control physical access at your workplace

  • Keep track of POS terminals

  • Train your employees often



  • Implement logging and alerting

  • Establish log management

  • Create log management system rules



  • Know your environment

  • Run vulnerability scans quarterly

  • Conduct a penetration test



  • Document everything

  • Implement a risk assessment process

  • Create an incident response plan


The following graphs demonstrate the compliance of compromised businesses we investigated noting whether each requirement was in place at the time of compromise or not in 2018:


The following graphs detail how non-compliance to the different PCI requirements affected breaches for compromised organizations we investigated in 2018:


We scanned our merchant database in search of the top 10 areas where SecurityMetrics merchants struggle to become compliant. Starting with the least adopted requirement, these are the results:

  1. Requirement 12.1: Establish, publish, maintain, and disseminate a security policy.
  2. Requirement 12.6.1: Educate personnel {with security awareness training] upon hire and at least annually.
  3. Requirement 12.5.3: Establish, document, and distribute security incident response and escalation procedures to ensure timely and effective handling of all situations.
  4. Requirement 12.10.1: Create an incident response plan to be implemented in the event of system breach.
  5. Requirement 12.1.1: Review the security policy at least annually and update the policy when the environment changes.
  6. Requirement 12.4: Ensure that the security policy and procedures clearly define information security responsibilities for all personnel.
  7. Requirement 12.8.5: Maintain information about which PCI DSS requirements are managed by each service provider, and which are managed by the entity.
  8. Requirement 9.9.2: Periodically inspect device surfaces to detect tampering (e.g., addition of card skimmers to devices), or substitution (e.g., by checking the serial number or other device characteristics to verify it has not been swapped with a fraudulent device).
  9. Requirement 12.3.5: [Verify that the usage policies define] acceptable uses of the technology.
  10. Requirement 12.8.4: Maintain a program to monitor service providers’ PCI DSS compliance status at least annually.


Unfortunately, 2018 showed significant decreases in compliance levels when compared to previous years.

None of the investigated breached organizations in 2018 were found to be compliant with PCI DSS. Furthermore, in nearly every case, the vulnerabilities that attackers leveraged to gain access to merchant systems were covered by specific sections of the PCI DSS.

In other words, had the organization been compliant with those sections of the PCI DSS, the breach likely would not have occurred.

Have an Upcoming PCI Audit Deadline?

Request a Quote Here


PCI DSS 3.2.1 introduced several changes, particularly about extending PCI scope and further explanation of SAQ categories. PCI scope deals with environment systems that must be tested and protected to become PCI compliant, while an SAQ is simply a validation tool for merchants and service providers to self-evaluate their PCI DSS compliance.

If the people, process, or technology component stores, processes, or transmits cardholder data (or is connected to systems that do), it’s considered in scope for PCI compliance. This means that PCI requirements apply and the system components must be protected.

System components most likely in scope for your environment may include:

  • Networking devices

  • Servers

  • Switches

  • Routers

  • Computing devices

  • Applications

You should annually fill out a PCI SAQ to make sure you aren’t missing any business security requirements. Although starting and completing your SAQ might seem daunting, 85% of SecurityMetrics customers who started their SAQ achieved a passing status in 2018.

Depending on the way you process, store, and transmit payment data, there are different SAQs that you must choose to fill out. For example, if you don’t have a storefront and all products are sold online through a third party, you probably qualify for SAQ A or SAQ A-EP. These different SAQ types will be further explained later in this section.

85% of SecurityMetrics customers who started their SAQ achieved a passing status in 2018.


In December 2016, the PCI Security Standards Council (SSC) released a supplemental guide for scoping and network segmentation. The purpose of this guidance was to help organizations identify the systems that need to be considered in scope for PCI DSS compliance and clarify how segmentation can reduce the number of in-scope systems.

You need to understand your business environment—especially what systems are included and how those systems interact with sensitive data. You are then required to apply PCI DSS security requirements to all system components included in or connected to the cardholder data environment (CDE), which is “comprised of people, processes, and technologies that store, process, or transmit CHD or sensitive authentication data.”


When scoping your environment, start with the assumption that everything is in scope until it is verified that all necessary controls are in place and actually provide effective segmentation.

When performing your annual PCI DSS scope assessment, list and confirm all connected-to systems, which are system components that:

  • Directly connect to the CDE (e.g., via internal network connectivity)

  • Indirectly connect to the CDE (e.g., via connection to a jump server with CDE access)

  • Impact configuration or security of the CDE (e.g., web redirection server, name resolution server)

  • Provide security to the CDE (e.g., network traffic filtering, patch distribution, authentication management)

  • Segment CDE systems from out-of-scope systems and networks (e.g., firewalls configured to block traffic from untrusted networks)

  • Support PCI DSS requirements (e.g., time servers, audit log storage servers)

Make sure any changes to your environment are reflected in your annual scope assessment.

Without adequate network segmentation, your entire network is in scope of the PCI DSS assessment and applicable PCI requirements.

Segmentation prevents out-of-scope systems from communicating with systems in the CDE or from impacting the security of the CDE. An out-of- scope system is a system component that:

  • Does NOT store, process, or transmit cardholder data

  • Is NOT in the same network segment as systems that store, process, or transmit CHD

  • CANNOT connect to any system in the CDE

  • Does NOT meet any criteria describing connected-to or security- impacting systems

To be considered out of scope, controls must be in place to provide reasonable assurance that the out-of-scope system cannot be used to compromise an in-scope system component. Here are some examples of controls you can use:

  • Host-based firewall and/or IDS/IPS

  • Physical access controls

  • Logical access controls

  • Multi-factor authentication

  • Restricting administrative access

  • Actively monitoring for suspicious network or system behavior

While not required, best practice is for you to implement PCI DSS controls on out-of-scope systems to prevent them from being used for malicious purposes.



To discover your PCI scope and what must be included for your PCI compliance, you need to identify anything that processes, stores, or transmits cardholder data, and then evaluate what people and systems are communicating with your systems. In December 2016, the council released an informational supplement regarding PCI scoping. The document helps reinforce and clarify scoping points that have always been part of PCI scoping. The document can help you work through your annual scoping exercise and can lead you to discover card flows and in-scope systems that you may have previously ignored.

In my experience performing PCI audits, entities often overlook the same types of systems when doing their own PCI scoping. For instance, call centers usually pay little attention to QA systems, which often store cardholder data in the form of call recordings. These systems are in scope for all PCI requirements!

Simple questions can help you begin the scoping process. For example, ask yourself:

  • How do you collect money?

  • Why do you handle card data?

  • How do you store, process, and transmit this data?

There are always processes you might not realize. For example, if you are a retail store that swipes cards, do you ever take card numbers over the phone or receive emails with card information? Are any paper orders received? Organizations often have finance, treasury, or risk groups that have post-transaction processes involving cardholder data. It is important to include these processes when determining scope.

Don’t forget power outage procedures where card data is sometimes taken down manually. For example, in most call centers, we’ve discovered that agents are typically unaware that card data should never be written down. But when the application they use for recording cardholder data freezes, they tend to resort to typing or writing it down in a temporary location and retrieving it later for entry. These temporary locations are rarely considered in an organization’s PCI compliance efforts but can lead to increased risk and should be included in PCI scope.

Often, paper trails of hand-written information or photocopied payment card data can sometimes fill multiple rooms. Even if card data is 10 years old, it is still in PCI scope.

If you access a web page for data entry, there’s a decent chance card data can be found in temporary browser cache files. In addition, it’s the website developer’s responsibility to make sure websites don’t generate cookies or temporary log files with sensitive data. However, you don’t always have full control of your website, which is why it’s important to evaluate all systems for cardholder data, even where you might not expect it to reside.

You might think your databases are set up to encrypt all cardholder data. However, servers you consider out of scope will often hold temporary files, log files, or back-ups with lots of unencrypted data. System administrator folders on file servers are also common culprits, as they often back up failing servers in a rush to prevent data loss without considering the PCI implications.

Do not panic if you find data where it does not belong.

Usually organizations can find ways to fix processes and delete this sensitive data, rather than add servers to their scope. A simple way to find unencrypted card data is by running a card discovery tool, such as SecurityMetrics PANscan®.

For organizations with web portals, if someone mistypes card data into an address or phone number field, it is still considered in PCI scope.

Organizations need to have methods to detect these mistakes and prevent or delete them. Some use a data loss prevention (DLP) solution to help them with this process.

The next step in determining your PCI scope is to find everything that can communicate with the devices you have identified. This is often the hardest part about scoping because you may not understand what can communicate to your systems. Ask yourself:

  • How do you manage your systems?

  • How do you log in to them?

  • How do you backup your systems?

  • How do you connect to get reports?

  • How do you reset passwords?

  • How do you administer security controls on your systems? 

If you have a server that handles cardholder data, you must always consider what else communicates with that server. Do you have a database server in some other zone you consider out of scope but is reaching that web server to pull reports and save data? Anything that can initiate a connection to an in-scope server that handles cardholder data will be in scope for compliance.

In addition, if your system in the CDE initiates a communication out to a server in another zone, that server will also be in scope. There are very few exceptions to this.



Download the latest guide to PCI compliance

Download Now


SAQ Overview


How you process credit cards and handle cardholder data determines which of the 9 Self-Assessment Questionnaire (SAQ) types your business needs to fill out. Here are the different SAQ type requirements:



  • Your company only accepts card-not-present (e-commerce or mail/telephone-order) transactions.

  • All processing of cardholder data is entirely outsourced to a PCI DSS validated third-party service providers.

  • Your company does not electronically store, process, or transmit any cardholder data on your systems or premises, but relies entirely on a third party(s) to handle all these functions.

  • Your company has confirmed that all third party(s) handling storage, processing, and transmission of cardholder data are PCI DSS compliant.

  • Any cardholder data your company retains is on paper (such as, printed reports or receipts), and these documents are not received electronically.



  • Your company only accepts e-commerce transactions.

  • All processing of cardholder data – with the exception of the payment page – is entirely outsourced to a PCI DSS validated third-party payment processor.

  • Your e-commerce website does not receive cardholder data but controls how consumers – or their cardholder data – are redirected to a PCI DSS validated third-party payment processor.

  • If the merchant website is hosted by a third-party provider, the provider is validated to all applicable PCI DSS requirements (e.g., including PCI DSS Appendix A if the provider is a shared hosting provider).

  • Each element of the payment page(s) delivered to a consumer’s browser originates from your website or a PCI DSS compliant service provider(s).

  • Your company does not electronically store, process, or transmit any cardholder data on your systems or premises, but relies entirely on third parties to handle all of these functions.

  • Your company has confirmed that all third parties handling storage, processing, and transmission of cardholder data are PCI DSS compliant.

  • Any cardholder data your company retains is on paper (e.g., printed reports, receipts), and these documents are not received electronically.



  • Your company only uses an imprint machine and/or uses only standalone, dial-out terminals (connected via a phone line to your processor) to take your customers’ payment card information.

  • Standalone, dial-out terminals are not connected to any other systems within your environment.

  • Standalone, dial-out terminals are not connected to the Internet.

  • Your company does not transmit cardholder data over a network (either an internal network or the Internet).

  • Any cardholder data your company retains is on paper (e.g., printed reports, receipts), and these documents are not received electronically.

  • Your company does not store cardholder data in an electronic format.



  • Your business only uses standalone, PTS-approved POI devices connected via IP to your payment processor to take your customers’ payment card data.

  • Standalone IP-connected POI devices are validated to the PTS POI program as listed on the PCI SSC website (excludes SCRs).

  • Standalone IP-connected POI devices are not connected to any other systems within your environment.

  • The only transmission of cardholder data is from PTS-approved POI devices to the payment processor.

  • The POI device doesn’t rely on any other device (e.g., computer, mobile phone, tablet) to connect to the payment processor.

  • The business has only paper reports or paper copies of receipts with cardholder data, and these documents are not received electronically.

  • Your company does not store cardholder data electronically.



  • Your company only processes payments through a virtual payment terminal accessed by an Internet-connected web browser.

  • Your company’s virtual payment terminal solution is provided and hosted by a PCI DSS validated third-party service provider.

  • Your company accesses the PCI DSS-compliant virtual payment terminal solution through a computer that is isolated in a single location, and is not connected to other locations or systems within your environment.

  • Your company’s computer does not have software installed that causes cardholder data to be stored.

  • Your company’s computer does not have any attached hardware devices that are used to capture or store cardholder data.

  • Your company does not otherwise receive or transmit cardholder data electronically through any channels.

  • Any cardholder data your company retains is on paper and these documents are not received electronically.

  • Your company does not store cardholder data in an electronic format.


  • Your business has a payment application system and an Internet connection on the same device and/or same local area network (LAN).

  • The payment application system isn’t connected to any other systems within your environment.

  • The POS environment isn’t connected to other locations, and any LAN is for a single location only.

  • Any cardholder data your business retains is on paper (e.g., printed reports, receipts), and these documents are not received electronically.

  • Your company does not store cardholder data in an electronic format.



  • All payment processing is through a validated PCI P2PE solution approved and listed by the PCI SSC.

  • The only systems in the merchant environment that store, process, or transmit account data are the Point of Interaction (POI) devices, which are approved for use with the validated and PCI-listed P2PE solution.

  • You do not otherwise receive or transmit cardholder data electronically.

  • There’s no legacy storage of electronic cardholder data in the environment.

  • If your business stores cardholder data, this data is only in paper reports or copies of paper receipts and isn’t received electronically.

  • Your business has implemented all controls in the P2PE Instruction Manual (PIM) provided by the P2PE Solution Provider.


SAQ D applies to merchants who don’t meet the criteria for any other SAQ type. This SAQ type handles merchants who store card information electronically and do not use a P2PE certified POS system. Here’s what qualifies you for SAQ D:

  • E-commerce merchants who accept cardholder data on their website.

  • Merchants with electronic storage of cardholder data.

  • Merchants that don’t store cardholder data electronically but that do not meet the criteria of another SAQ type.

  • Merchants with environments that might meet the criteria of another SAQ type, but that have additional PCI DSS requirements applicable to their environment.



A service provider is a business entity that isn’t a payment brand, but is directly involved in the processing, storage, or transmission of cardholder data on behalf of another organization. Service providers can also provide services that control or could impact the security of cardholder data. Here’s what qualifies you for SAQ D:

  • A service provider handles card data on behalf of another business.

  • A service provider provides managed firewalls used in another entity’s cardholder data environment.

  • A service provider that hosts a business’s e-commerce environment/website.


PCI DSS 3.2.1 was released on May 17, 2018, replacing version 3.2. PCI DSS 3.2 brought with it some extensive changes, among which were new requirements for service providers and additional guidance about multi-factor authentication. PCI DSS 3.2 remains valid through December 31, 2018, retiring on January 1, 2019.

The changes from PCI DSS 3.2.1 are characterized by the PCI Council as clarification – as opposed to additional guidance or actual changes in requirements. The intent of clarification from the PCI Council is to ensure that “concise wording in the standard portrays the desired intent of requirements.”



Using SSL/early TLS encryption for card data transmission poses risks to security since it has many exploitable vulnerabilities.

As of June 30, 2018, SSL/early TLS is no longer an accepted technology for protecting card data in transit. You should now have implemented a more secure encryption protocol such as TLS 1.1 or higher (TLS 1.2 or above is strongly encouraged). The practice of having a risk mitigation plan in place for usage of previous insecure versions will no longer be accepted for PCI DSS compliance.

For merchants still using Point of Sale (POS) Point of Interaction (POI) terminals that utilize SSL and/or early TLS, you need to verify that the terminals (and connected SSL/early TLS termination points) are not susceptible to any known exploits (see appendix A of PCI DSS 3.2.1 for additional requirements). If you are in this situation, it is recommended that you begin a transition plan for upgrading POS/POI terminals to those that support the latest version of TLS.

If you are a service provider that supports POS/POI terminals still using SSL and/or early TLS, then you must have a formal Risk Mitigation and Migration Plan in place until all terminals you support are upgraded to support secure TLS versions. In addition, you must also provide a secure service offering that supports the latest TLS versions (see appendix A of the PCI DSS).



PCI DSS 3.2.1 evaluates additional multi-factor authentication (MFA) requirements for administrators within a CDE. Multi-factor authentication is an effective way to secure your CDE. To properly configure multi-factor authentication, you must have at least two of three things:

  • Something you know (e.g., password/passphrase, PIN)

  • Something you have (e.g., token device, one-time password)

  • Something you are (e.g., fingerprint scan, retina scan)

Prior to PCI DSS 3.2 and 3.2.1, multi-factor authentication was just required for remote access to the network by employees, administrators, and third parties. But now, even if your connection into the CDE is from an internal network segment, you need to use multi-factor authentication.

As with all PCI DSS requirements, this requirement is a reflection of the current threat landscape. This change helps strengthen security behind your edge firewall as well as outside of it.

Additionally, make sure that you “incorporate multi-factor authentication for all remote network access (both user and administrator, and including third-party access for support or maintenance) originating from outside the entity’s network.”



Last year, the PCI Security Standards Council released a supplemental guide on multi-factor authentication, clarifying multi-factor authentication policies. Specifically, the MFA mechanisms should be independent of one another, so that access to one factor does not grant access to another, and the compromise of any one factor does not affect the integrity or confidentiality of any other factor.

For example, if the same set of credentials (e.g., username/password) is used as an authentication factor and also for gaining access to an email account where a secondary factor (e.g., one-time password) is sent, these factors are not independent. Another faulty example is if you use a software certificate that is stored on a mobile device and protected by the same set of credentials used to log in to that device.

For good MFA implementation, you should include independence of authentication mechanisms and protection of authentication factors. You should also ensure that knowledge of the success or failure of a factor is not provided to the individual until all factors have been submitted.

All non-console administrative access to CDE requires multi-factor authentication.

A common way to implement the independence of authentication factors is through physical separation of these factors. You might also be able to use highly robust and isolated execution environments, such as “trusted execution environment [TEE], Secure Element [SE], and Trusted Platform Module [TPM]).” 


PCI DSS 3.2.1 clarifies masking criteria for when primary account numbers (PAN) are displayed. Masking is described as hiding data from view; this is not the same as encryption. When displaying a credit card number or bank identification number (BIN) outside of your organization, you are allowed to display (at a maximum) the first six and last four numbers. If you include more than this information, you’re not compliant.

Additionally, you must have “a list of roles that need access to displays of more than the first six/last four (includes full PAN).” Whether or not you should display fewer PAN numbers could depend on various legal requirements. If your business stores PAN, you’re also required to encrypt and properly secure it.



PCI DSS 3.2.1 explains that you need to have a change management process in place to ensure that all new or changed systems and networks implement relevant PCI DSS requirements after a significant change. Your documentation should include what qualifies as a significant change and these process updates.

Examples of requirements that could be impacted by significant changes:

  • Network diagram is updated to reflect changes.

  • Systems are configured according to configuration standards with all default passwords changed and unnecessary services disabled.

  • Systems are protected with required system controls (e.g., FIM, anti-virus, patches, audit logging).

  • Sensitive authentication data (SAD) is not stored and all cardholder data (CHD) storage is documented and incorporated into data-retention policies and procedures.

  • New systems are included in the quarterly vulnerability scanning process.


PCI DSS 3.2.1 further explains that “the extent to which the service provider is responsible for the security of cardholder data will depend on the particular service and the agreement between the provider and assessed entity.”

You should obtain a written security acknowledgment from the service provider. In this document, they need to acknowledge their responsibility to protect cardholder data that affects your organization’s security.

You need to maintain a list of all PCI requirements your service provider meets and a list of requirements they need to meet.

Have an Upcoming PCI Audit Deadline?

Request a Quote Here


This section contains the most important new and revised requirements for service providers. Remember, a service provider is an organization that’s not a payment brand but is directly involved in the processing, storage, or transmission of cardholder data on behalf of another organization (e.g., managed firewalls, merchant processor).



Since February 1, 2018, service providers who use segmentation are required to perform penetration testing (e.g., segmentation checks) on segmentation controls at least every six months and after any changes to segmentation controls/methods.

Validation of your PCI DSS scope should be performed as frequently as possible to ensure your PCI DSS scope remains up to date and aligned with changing business objectives.

Penetration testing should be performed by a qualified internal resource or third party. If applicable, the tester should also have organizational independence (though they aren’t required to be a QSA or ASV). The purpose of penetration testing is to test segmentation controls/methods to verify whether they are operational and effective.

If you use segmentation as a service provider, perform penetration testing on segmentation controls at least every six months and after any changes.

Although this requirement only applies to service providers, any organization can request a penetration test whenever they wish to measure their business security.

To find security weaknesses, penetration testers analyze network environments, identify potential vulnerabilities, and try to exploit those vulnerabilities (or coding errors) just like a hacker would.


Service providers need to interview responsible personnel and maintain a documented description of cryptographic architectures, including:

  • Details of all algorithms, protocols, and keys used for the protection of cardholder data, including key strength and expiry date

  • Descriptions of the key usage for each key

  • Inventory of any HSMs and other SCDs used for key management

You must keep pace with evolving threats to your architecture by planning for and documenting updates (e.g., different algorithms/key strengths changes). Maintaining such documentation helps you detect lost or missing keys and key-management devices, as well as helps you identify unauthorized additions to your cryptographic architecture.


Service providers are required to “examine detection and alerting processes and interview personnel to verify that processes are implemented for all security controls, and that failure of a critical security control results in the generation of an alert.” Examples of critical security control systems include:

  • Firewalls


  • FIM

  • Anti-virus

  • Physical access controls

  • Logical access controls

  • Audit logging mechanisms

  • Segmentation controls (if used)

Service providers must respond to failures of any critical security controls in a timely manner. Processes for responding to security control failures must include:

  • Restoring security functions.

  • Identifying and documenting the duration (date and time, start to end) of the security failure.

  • Identifying and documenting cause(s) of failure (including the root cause) and documenting remediation required to address root cause.

  • Identifying and addressing any security issues that arose during the failure

  • Performing a risk assessment to determine whether further actions are required as a result of the security failure.

  • Implementing controls to prevent another failure.

  • Resuming monitoring of security controls.

Document that processes and procedures are in place to respond to security failures. Make sure staff are aware of their responsibilities in the event of a failure. If you are breached, document your organization’s actions and responses to the security control failure.

If security failures are not quickly and effectively addressed, attackers may use this time to insert malware, take system control, and can then steal data from your environment.


Executive management need to establish responsibility for the protection of cardholder data and a PCI DSS compliance program, including:

  • Overall accountability for maintaining PCI DSS compliance

  • Defining a charter for a PCI DSS compliance program and communication to executive management

Smaller organizations should add these roles to an individual’s job responsibilities, while larger organizations might need to establish a PCI compliance team (e.g., a compliance team made up of IT, accounting, and management). Whichever is the case, management should give their PCI officer and team power to act and implement necessary changes to become PCI DSS compliant, as well as have monthly – or weekly – meetings with executive management.


Service providers need to perform reviews at least quarterly to confirm personnel are following security policies and operational procedures.

Reviews must cover the following processes:

  • Daily log reviews

  • Firewall rule-set reviews

  • Applying configuration standards to new systems

  • Responding to security alerts

  • Change management processes

You must also maintain documentation of quarterly review processes, making sure to include:

  • Documentation of review results

  • Review and sign-off of results by personnel assigned responsibility for the PCI DSS compliance program

Think You've Had a Data Breach?

Click for Incident Response



SecurityMetrics Payment Card Industry Forensic Investigators (PFIs)* thoroughly analyze the point-of-sale (POS) or E-commerce environments of organizations that suspect a payment card data compromise.

Through a forensic examination of the in-scope computer systems related to the processing of customer payment card information, data acquired from the breach site can reveal when and how the breach occurred, contributing vulnerabilities, and aspects of the IT environment out of compliance with the PCI DSS.

SecurityMetrics Forensic Investigators have witnessed the rise and fall of popular attack trends over 15 consecutive years.

*SecurityMetrics PFIs are Qualified Security Assessors, but do not perform a complete QSA audit of each PCI requirement during a PCI forensic investigation. PCI DSS requirement data is analyzed to the extent observed throughout the course of an investigation.



The window of compromise starts from the date an intruder accesses a business network and ends when the breach is contained by security remediation. Based on data collected by SecurityMetrics Forensic Investigators from 2018 breaches, it took an average of 166 days from the time an organization was vulnerable for an attacker to compromise the system. The average organization was vulnerable for 275 days.

Nearly every organization will experience system attacks from a variety of sources. Due to inherent security weakness in systems or technology, some organizations have systems, environments, software, and website weaknesses that can be exploited by attackers from the day their environment is set up. In other cases, an organization becomes vulnerable because they fail to apply a security patch or make system modifications without properly updating related security protocols.

Once compromised, attackers had access to the sensitive data for an average of 127 days in 2018 investigations. This may be due to aggregation methods employed by data thieves. Attackers have been known to save sensitive data through malware scraping (or other tools), without using or selling the data for months to years.

Using these aggregation methods prevents organizations from identifying malicious account activity until long after the start of the window of compromise, giving the attackers a longer period of time to access vulnerable sensitive data.


  • The average breached organization was vulnerable for 275 days.
  • Cardholder data was captured for an average of 127 days.
  • Cardholder data was exfiltrated for an average of 127 days.
  • 50% of organizations were breached through remote execution/injection.
  • 33% of organizations were breached internally (i.e., employee assisted).
  • 17% of organizations were breached through phishing emails.


Vulnerable: A system, environment, software, and/or website can be exploited by an attacker.

Captured: Data is being recorded, gathered, and/or stored from an unauthorized source.

Exfiltrated: Unauthorized data is transferred from a system.


Passwords may not be the security you’re looking for. We will start to see next year—and more so in the coming years—that passwords will no longer be considered an element of security. There is current technology that can search and break password hashes at a rate of 600 billion attempts per second. This means that attackers could span every possible combination of keys, in most languages, in just a few days. As developers put more steam behind this tool, the time and resources needed to break passwords will greatly reduce, regardless of password complexity level.

Biometric data will be compromised. Information like fingerprints and other biometric scans needs to be stored somewhere. But if data can be stored, it can also be stolen. Just as there are large repositories of stolen username/password combinations available for sale on the dark web, stolen biometric data will follow as well.

A major cloud storage provider will be seriously breached. With so many businesses and individuals uploading massive amounts of data to the cloud, it’s only a matter of time before hackers figure out a way to get to it.

Foreign nation-states will increase recruitment of corporate insiders to steal insider secrets.

Large-scale social-media-based hacks will lead to massive data losses. For example, many individuals play games through their social media accounts. Related to some of these games are offers for the user to receive “unlimited coins” and “unlimited lives” via a third-party site. In exchange for these coins and lives, users are asked to download apps from the provider. Often, the provider will state that the purpose of requiring the app download is that it “proves you’re not a robot” or it “helps keep the offerings free.”
One of our forensic investigators installed some of these games and app downloads into a sandbox environment and found that they were actually VPNs–giving the providers a backdoor into the user’s device. With kids and adults regularly downloading these games and apps to devices, a social media/game hack is going to lead to a massive data breach.
Artificial intelligence (AI) will be on your side and against you. We will likely soon start to see security tools with artificial intelligence that can detect and adapt to data breaches. But we will also likely see AI on the attackers’ side–with malware that can self-move, self-manipulate, and self-hide in response to what it sees a user do. AI will start to show up with increasing frequency, and it’s going to make the future of data security very interesting.

Think You've Had a Data Breach?

Click for Incident Response




Network firewalls are vital for your security. A firewall’s purpose is to filter potentially harmful Internet traffic to protect valuable sensitive data. Simply installing a firewall on your organization’s network perimeter doesn’t make you secure.



A hardware firewall–or perimeter firewall–is typically installed at the perimeter of an organization’s network to protect the internal networks from the Internet. Hardware firewalls are also used inside an environment to create isolated network segments. Higher security internal network segments would be created to limit access to sensitive data from networks that don’t need that access.

In summary, a properly configured hardware firewall protects environments from the outside world. For example, if attackers try to access your network from the outside, your hardware firewall would act as the first line of defense and should block them.



Most robust security option

Rules need to be carefully documented

Protects an entire network
Difficult to configure properly

Can segment internal parts of a network

Needs to be maintained and reviewed regularly


You also need a firewall between systems that store sensitive data and other systems on your network. Typically, this is a second hardware firewall installed inside your corporate network to create a secure zone to further protect sensitive data.

Many personal computers come with pre-installed software firewalls. This feature should be enabled and configured for any laptop computers that commonly connect to sensitive data networks. For example, if a sales manager accidentally clicks on a phishing email scam, their computer’s software firewall should stop the malware from propagating through the corporate network.




Fewer security options

Protects mobile workers when outside the corporate network
Should not replace hardware firewalls for network segmentation
Easier to maintain and control
Doesn’t protect an entire network


A common mistake regarding firewalls is assuming they are a plug-and-play technology. After initial installation, additional effort is almost always necessary to restrict access and protect the CDE.

The end goal of firewall implementation is to filter potentially harmful Internet traffic and other untrusted networks to protect valuable confidential data. In e-commerce applications, a firewall should be used to limit traffic to only essential services needed for a functioning CDE. By identifying sensitive systems and isolating them through the proper use of firewalls (e.g., network segmentation), merchants can more precisely control what type of access is allowed into and out of these zones, and more easily protect payment data.

In a recent data breach investigation conducted by SecurityMetrics Forensic Investigators, an organization had a sophisticated security and IT system. However, amongst 300 pages of firewall rules (with about 100 rules on every page), two incorrectly written firewall rules essentially negated the whole firewall, leaving the entire network exposed. It was through this vulnerability that the attacker accessed their network and stole sensitive data.


  1. CREATE FIREWALL CONFIGURATION STANDARD: Before implementing firewall settings and rules on the hardware carefully document settings and procedures, such as hardware security settings, port/service rules needed for business, justify need for rules, consider both inbound and outbound traffic, etc.).

  2. TRUST BUT VERIFY: After implementing firewall rules/settings, test the firewall appropriately externally and internally to confirm settings are correct (pen test, scans, etc.).

  3. LIMIT OUTBOUND TRAFFIC: Often we worry too much about blocking inbound ports/services and forget that outbound traffic from inside the network should be limited to just what is needed, this limits hackers’ paths for exfiltrating data.

  4. PERSONAL FIREWALLS: Configure personal firewalls on mobile computing platforms to limit attack surfaces and minimize propagation of malware when on unsecured networks.

  5. MANAGEMENT: Only manage the firewall itself from within your network, disable external management services unless it’s part of a secure managed firewall infrastructure.


Merchants often setup flat networks, meaning everything inside the network can connect to everything else. They may have one firewall at the edge of their network, but that’s it. There’s no internal segmentation, making it a “flat network.”

Flat networks make security difficult because if an attacker gets inside, they have access to everything.

Initial intrusion in many of 2018’s investigated data breaches began in areas of an organization’s network that shouldn’t have given the attacker access to the CDE. For example, since the organization’s network was configured as a flat network, it was not difficult for the attacker(s) to migrate from the point of entry (e.g., employee laptop, workstation) to the CDE or other sensitive systems.

Firewalls can be used to segment an organization’s network. When businesses create a secure payment zone – firewalled off from the rest of the day-to-day business traffic – they can better ensure their CDE only communicates with known and trusted sources. This limits the size of the CDE and potentially lowers your PCI scope.

For example, you install and configure a multi-interface firewall at the edge of your network. From there, you create one interface on the firewall dedicated just to the systems that store, process, and transmit cardholder data. If that interface doesn’t allow any other traffic in or out of any other zones, this is proper network segmentation.

Segmentation is not necessarily required in order to be compliant with PCI DSS 3.2.1. However, if you’re looking for one of the easiest ways to reduce cost, effort, and time getting in-scope systems compliant, you may want to consider segmentation.

Segmentation can be tricky, especially for those without a technical security background. Consider having a security professional double check all your segmentation work by performing regular segmentation checks.



No matter your organizational size, rules and environments change over time. Firewall rules should be reviewed (and revised when necessary) over the course of a few months and at least every six months.

Have an Upcoming PCI Audit Deadline?

Request a Quote Here



Large environments typically have firewalls in place, at least at the network’s perimeter. Make sure to choose firewalls that support the necessary configuration options to protect critical systems and provide segmentation between the CDE and other internal and external networks.

Smaller organizations sometimes struggle to understand firewalls, not having the necessary in-house expertise to configure and manage them correctly and securely. If this is the case, contract a PCI-validated third- party service provider to provide assistance, rather than simply deploying a firewall’s default configuration and hoping for the best.

It may seem obvious, but leave as few holes as possible in your firewall.

It’s best to start by having a block everything mentality, and then add exceptions as needed. PCI DSS requires you to document a valid business justification for any communication allowed to or from the CDE. Spend the time to identify specific source and destination addresses your systems need to communicate with for a given service or protocol. Don’t just allow all access to the Internet because it’s easier. Along the same line, if you or any third parties remotely support your environment, limit that inbound access to specific sources and protocols.

Firewalls are a first line of defense, so pay special attention to the logs and alerts firewalls generate. Often, the volume of log data can be overwhelming, so some merchants turn logging off or send alert messages directly to the junk bin. It’s important (and required) to review firewall logs daily to identify patterns and activity that indicate attempts to breach security. There are many good software packages available to help you deal with the volume of log data and automate alerts. This will help you pick out the important data that requires your action.

For requirement 1, remember the following:

  • Start with a “block everything” mentality, then work backwards from there.

  • Pay attention to what logs tell you.

  • Review firewall configurations frequently and adjust as necessary.






Out-of-the-box devices, such as routers or POS systems, come with factory settings like default usernames and passwords. Defaults make device installation and support easier, but also mean every model originates with the same username and password. Default passwords are easy to guess, especially since most are published online.

Businesses are often unaware that default settings are used in their environment, due to third-party installation.

In one SecurityMetrics forensic investigation, it was discovered that a third-party IT vendor purposely left POS system default passwords in place to facilitate easier future system maintenance. Default passwords might make it easier for IT vendors to support a system without learning new passwords each time; however, convenience is never a valid reason to forego security, nor will it reduce liability.

When defaults aren’t changed, it provides attackers an easy gateway into a system, which is why changing vendor defaults on every system with exposure to your CDE is so vital.

Passwords must be changed every 90 days and contain at least seven characters – including both numbers and letters.

Passwords that fall short of these criteria can usually be broken using a password-cracking tool.


Any system used in your CDE needs to be hardened before it’s placed in production. The goal of hardening a system is to remove unnecessary functionality and configure what is left in a secure manner. Every application, service, driver, feature, and setting installed on a system introduces vulnerabilities.

According to requirement 2.2, you must “address all known security vulnerabilities and [be] consistent with industry-accepted system hardening standards.”

Here are recommended resources for system hardening:

  • Center for Internet Security (CIS)

  • International Organization for Standardization (ISO)

  • SysAdmin Audit Network Security (SANS) Institute

  • National Institute of Standards Technology (NIST)


Consistency is key when trying to maintain a secure environment. Once system hardening standards and settings have been defined and documented, it is critical that they are applied to all systems in the environment in a consistent manner. Once each system and device in the environment has been appropriately configured, you still have work to do.

Make sure someone is responsible for keeping the inventory current and based on what is actually in use.

This way, applications and systems that are not approved for use in the CDE can be discovered and addressed.

Many organizations, especially larger ones, turn to one of the many system management software packages on the market to assist in gathering and maintaining this inventory. These applications are capable of scanning and reporting on hardware and software used in a network and also detecting when new devices are brought online. These tools are often able to enforce configuration and hardening options, alerting administrators when a system isn’t compliant with your internal standard.

Download the latest guide to PCI compliance

Download Now



You are required to use industry accepted configuration and hardening standards when setting up systems that are part of your PCI scope.

Configuration and hardening requirements apply to all computer systems, network devices, and applications used to process or secure cardholder data. This may include things like web servers, database software, firewalls, point-of-sale systems, or workstations used to process credit card transactions.

Examples of system hardening practices include:

  • Disabling services and features you don’t use

  • Uninstalling applications you don’t need

  • Limiting systems to perform a single role

  • Removing or disabling default accounts, changing default passwords

  • Configuring other security settings

Permitting anything unnecessary to remain on a system opens you up to additional risk and possible vulnerability.

Often, organizations get overwhelmed trying to understand how and where to begin implementing system configuration standards, especially in an environment that has expanded and changed over time.

The first step in securing your environment to meet PCI standards is to understand where credit card data is stored, processed, and transmitted. Begin by documenting the flow of CHD through your environment, making a list of each system, device, and application it touches along the way. Next, look at the systems and applications that, while not directly touching the data, can affect the security of those that do. Add this information to your list.

The key to effective system configuration and hardening is consistency. Once you have identified the systems and applications that need attention and documented a standard that meets your environment’s requirements, make sure processes are in place to follow this standard as time goes on. Keep your standard and process up to date as your business changes and as you discover new threats and vulnerabilities.

Automated tools can simplify the task of enforcing configuration standards, allowing administrators to quickly discover systems that are out of compliance.






According to requirement 3, stored card data must be encrypted using industry-accepted algorithms (e.g., AES-256). The problem is many organizations don’t know that they store unencrypted primary account numbers (PAN).

Not only must card data be encrypted, but the encryption keys must also be protected. Not protecting the encryption key location using a solid PCI DSS encryption key management process is like storing your house key in your front door lock.

Assign the responsibility of keeping unencrypted card data off your systems to an individual or team. Have this person or team define, document, and follow a process of periodic data discovery cycles to recheck and ensure systems remain clean of unencrypted card data.



Storage of unencrypted payment card data increases an organization’s risk and liability in the event of a data breach.

Since 2010, SecurityMetrics PANscan® has discovered over 2 billion unencrypted PANs on business networks. In 2018, users scanned over 3,600 computers and 7,000,000 GBs. Here are some key statistics:

  • 85% of PANscan® users discovered unencrypted PAN data

  • 5% stored track data (i.e., data inside magnetic stripe)

  • Over 330 million PANs were found

In the latest study by SecurityMetrics, 85% of PANscan® users found unencrypted PAN data on their network.

Discover Your Unencrypted Card Data

Start Here


An essential part of eliminating stored card data is using a valid card data discovery tool and methodology. Remember, payment card data can easily leak due to poor processes or misconfigured software, start by looking where you think the data is, and then look where it shouldn’t be.

You should create and document a current cardholder flow diagram for all card data flows in your organization. A CHD flow diagram is a graphical representation of how card data moves through an organization. As you define your environment, it’s important to ask all organizations and departments if they receive cardholder information, and then define how their answers may change CHD flows.

To accurately craft your CHD flow diagram, ask yourself:

  • What device(s) am I using for transactions? A virtual terminal? POS system?

  • What happens to the card data after a transaction?

  • When is data encrypted? Is it even encrypted at all?

  • Do I store card data before it’s sent to the processor for approval?

  • How does settlement occur? Real time or end of day?

  • How is data authorized and returned by the processor?

  • Is card data backed up on my system? Are backups encrypted? Is my backup server at a different data location?

  • Where might card data be going or moved in processes not part of authorization and settlement?

In addition, you should regularly run a cardholder data discovery tool. These tools help identify the location of unencrypted PAN so you can securely delete or encrypt it. They also help identify which processes or flows might need to be fixed.

Once you identify new processes, you can begin to determine how to either fix the process or add it into your normal environment flow.





Cardholder Data


Sensitive Authentication Data

Primary account number (PAN)



Cardholder name
Service code
Expiration date

Full track data


Not allowed to store

Not allowed to store
PIN/PIN block
Not allowed to store




Some of the biggest data issues organizations face are: having a data retention policy, understanding their policy, and following their policy.

IT security should work with the legal team and executives to decide what data the company holds onto, why they need it, and the length of time it’s held. However, this communication often doesn’t happen. Security staff will often draft data security policies to meet PCI DSS compliance, but if it isn’t adopted and enforced from the executives down, company processes will never change.

Policy enforcement must include requirements to encrypt data once it is received, time frames to keep data, and a documented procedure to delete unnecessary payment card data that does not meet policy specifications.

Next, it’s imperative to understand what data you actually have. Map out all the flows to understand where data moves in your organization.

For example, you may not know that the accounting department captures card data from a database and stores it in spreadsheets or that cardholder data is being saved in log files.

The best practice to find unencrypted data is through a card data discovery tool.

Once all card data is found, make sure you consult your security policies and PCI DSS to determine what you are allowed to keep. For example, PCI DSS prohibits storage of track data.

Make sure to limit exposure to systems that handle card data by keeping all networks segmented and limiting the amount of card data stored.





For requirement 4, you need to identify where you send cardholder data. The following are common places PAN are sent:

  • Processors

  • Backup servers

  • Third parties that store or handle PAN

  • Outsourced management of systems or infrastructure

  • Corporate offices

You need to use encryption and have security policies in place when you transmit cardholder data over open, public networks.



Based on vulnerabilities in web encryption, if your organization has existing implementations of SSL and early TLS not necessary for regular business operations, immediately remove or discontinue all instances. The only acceptable use of these outdated protocols is if your POS/POI hardware currently in use does not support later versions of secure TLS.

SSL and early TLS may still be used, so you should contact your terminal providers, gateways, service providers, vendors, and acquiring bank to determine if the applications and devices you use have this encryption protocol.

Examples of applications that may still use SSL/early TLS include:

  • POS/POI hardware terminals

  • Virtual payment terminals

  • Back-office servers

  • Web/application servers

The PCI Council believes that SSL and early TLS will no longer protect cardholder data.

Please note that organizations using POS/POI terminals with existing implementations of SSL and early TLS must ensure that the devices in use are not susceptible to any known exploits for those insecure protocols. Check with your merchant bank or POS/POI supplier if you have questions on that.

Service providers that support older POS/POI terminals that still use the insecure SSL/TLS protocols still should have a Risk Mitigation and Migration Plan in place. According to the PCI Council, this document will “detail [your] plans for migrating to a secure protocol, and also describe controls [you have] in place to reduce the risk associated with SSL/early TLS until the migration is complete.”



To begin with, you need to know exactly how and where you are sending cardholder information so that you can know what needs to be encrypted during transmission.

It’s important to have a good understanding of technologies (e.g., SSL, TLS) and where your organization stands regarding your security processes. If you’ve already eliminated outdated processes, great. If not, the only accepted use of these older protocols are for POS/POI hardware and service providers that support them.

You must transition away from these older technologies as quickly as possible to be compliant to the PCI DSS. You might be worried about losing business with customers using older browsers (e.g., SSL, early TLS). In reality, there will likely be a limited negative impact on customers, if at all.

If I were you, I would eliminate using these outdated technologies because it’s better to be safe than to risk a security breach.



Download the latest guide to PCI compliance

Download Now




Anti-virus software needs to be installed on all systems commonly affected those commonly affected by malware, regardless of its location. Make sure anti-virus or anti-malware programs are updated on a regular basis to detect known malware. Maintaining an up-to-date anti-malware program will prevent known malware from infecting systems.

Depending on your relationship with your POS vendor, they may or may not maintain your anti-virus scanning. If your vendor doesn’t handle your anti-virus, it’s up to you to ensure regular scanning is conducted.

Using outside sources such as the United States Computer Emergency Readiness Team (US-CERT), SANS Institute, and vendor/anti-virus threat feeds, merchants can identify emerging malware and attacks on systems. They should then configure systems to alert and report on suspicious activity, such as new files added to known malware directories or unauthorized access attempts.

Vigilant vulnerability management is the most effective way for you to proactively reduce the window of compromise, greatly narrowing the opportunity for hackers to successfully attack your systems and steal valuable data. As part of your vulnerability management strategy, make sure to include updated anti-virus software.



Anti-virus software offers an additional layer of security to any system within a network. System administrators have the responsibility of making sure their anti-virus software, including the signatures, are up to date.

This applies to either a master anti-virus server client-based configuration or single server/workstation installations. Additionally, PCI DSS requires AV scanning to occur on a regular basis.

PCI DSS requires anti-virus to be installed on all systems that are commonly affected by malware (e.g., Windows). For example, Linux servers are often considered systems not commonly affected by malware.

However, if a Linux server is web facing, it’s highly recommended that anti-virus be installed for any web-facing Linux server. Malicious coders still target Linux systems as well as Windows. The risk is too great not to run anti-virus on web-facing Linux systems.

When system administrators understand that anti-virus adds another line of defense for their environment, they have an advantage when it comes to securing the sensitive data it contains.






Application developers will never be perfect, which is why updates to patch security holes are frequently released. Once a hacker knows they can get through a security hole, they pass that knowledge on to the hacker community. They could then exploit this weakness until the patch has been updated.

Quickly implementing security updates is crucial to your security posture. Patch all critical components in the card flow pathway, including:

  • Internet browsers

  • Firewalls

  • Application software

  • Databases

  • POS terminals

  • Operating systems

Older Windows systems can make it difficult for merchants to remain secure, especially when the manufacturer no longer supports a particular operating system or version (e.g., Windows XP, Windows Server 2003).

Operating system updates often contain essential security enhancements that are specifically intended to correct recently exposed vulnerabilities. When using an unsupported OS that doesn’t receive such updates and patches, the vulnerability potential increases exponentially. 

Be vigilant about consistently updating software associated with your system. Requirement 6.2 states that organizations must “install critical patches within a month of release” to maintain compliance. Don’t forget about critical software installations like credit card payment applications and mobile devices. To stay up to date, ask your software vendors to put you on their patch and upgrade notification list. 

Keep in mind that the more systems, computers, and apps your company has, the more potential vulnerabilities it may be exposed to.

Another way to stay on top of vulnerabilities is through vulnerability scanning, which is arguably the easiest way to discover software patch holes that cybercriminals would use to exploit, gain access to, and compromise an organization.



If you develop payment applications in-house (e.g., e-commerce websites, POS applications), you must use strict development processes and secure coding guidelines as outlined in the PCI DSS. Don’t forget to develop and test applications according to industry accepted standards like the Open Web Application Security Project (OWASP).

Be vigilant about consistently updating the software associated with your system.


In addition to updating and securing applications, you should implement web application firewalls (WAFs) in front of public-facing web applications to monitor, detect, and prevent web-based attacks. Even though these solutions can’t perform the many functions of an all-purpose network firewall (e.g., network segmentation), they specialize in one specific area: monitoring and blocking web-based traffic.

A WAF can protect web applications that are visible or accessible from the Internet. Your web application firewall must be up to date, generate audit logs, and either block cyber-attacks or generate a cyber security alert if it detects attack patterns.




Immediate response to web application security flaws

Requires more effort to set up

Protection for third-party modules used in web applications
Possibly break critical business functions (if not careful)

Deployed as reverse proxies

May require some network re-configurations



System administrators have the responsibility to ensure that all system components (e.g., servers, firewalls, routers, workstations) and software are updated with critical security patches within 30 days of public release. If not, these components and software are vulnerable to malware and security exploits.

Quickly implementing security updates is crucial to your security postures.

Systems or software might be excluded from updates because they weren’t able to communicate with the update server (e.g., WSUS, Puppet). This broken communication could have resulted from a network or system configuration change. It’s imperative that system administrators are alerted when security updates fail.

Another important sub-section of requirement 6 is the need to have proper change control processes and procedures. Change control processes should include at least the following:

  • Development/test environments must be separate from production with proper access control in place to enforce access rights.

  • Separation of duties must be implemented between personnel assigned to development/test environments and those assigned to production.

  • Production data (e.g., live credit card numbers, live personally identifiable information) must never be used in test/development environments.

  • All test data and accounts must be removed before a production environment becomes active.

  • Change control procedures related to implementing security patches and software modifications must be documented.

Companies need to embrace the idea of change control for their software development and system patching/updating. There are four requirements detailed by the PCI Council of what a proper change control procedure must contain:

  1. Changes must have a documented explanation of what will be impacted by the change.

  2. Changes must have documented approval by authorized parties.

  3. Changes to an organization's production environment must undergo proper iterations of testing and QA before being released into production.

  4. Change control procedures must always include a back-out or roll-back procedure in case the updates go awry.

When developing software (e.g., web applications), it’s crucial that organizations adopt industry-accepted standard or best practices for coding, such as OWASP. This will guide them in enforcing secure coding practices in their application development process and keep software code safe from malicious vulnerabilities (e.g., cross-site scripting, SQL injection, insecure communications, CSRF).

Insecure communications, for example, have recently been in the spotlight since SSL and TLS 1.0 are no longer considered acceptable forms of encryption when data is being transmitted over open, public networks. Confirm that no software or web servers you host support these outdated protocols.



Have an Upcoming PCI Audit Deadline?

Request a Quote Here




You should have a role-based access control (RBAC) system, which grants access to card data and systems on a need-to-know basis. Configuring administrator and user accounts helps prevent exposing sensitive data to those who don’t have a need to know this information.

PCI DSS 3.2.1 requires a defined and up-to-date list of the roles with access to the card data environment. On this list, you should include: each role, the definition of each role, access to data resources, current privilege level, and what privilege level is necessary for each person to their perform normal business responsibilities. Users must fit into one of the roles you outline.

Have a defined and up-to-date list of roles with access to the card data environment.

User access isn’t limited to your normal office staff. It applies to anyone needing access to your systems behind the desk, such as an IT group or maintenance professionals. You need to define and document what kind of user permissions they have.



This requirement is one of the oldest and most basic parts of the PCI DSS.

Things haven’t really changed for this requirement. There’s no new trend or solution. But not all organizations have accurately complied with this requirement or have even tried role-based access at all.

This is all you need to know: don’t give access to people who don’t need it. Card data and card systems should only be accessible to those that need that information to do their jobs. Document which permissions have been granted to those persons.






If a username and password aren’t sufficiently complex, it will be that much easier for an attacker to gain access to your environment. An attacker may try a brute-force attack against a system by entering multiple passwords (via an automated tool entering thousands of password options within a matter of seconds) until a password works.

Secure passwords should be changed every 90 days and have at least seven characters of both numbers and letters. Passwords that fall short of these criteria can easily be broken using a password-cracking tool. In practice, the longer the password and more character formats, the more difficult it will be for an attacker to crack that password.

Instead of common usernames (i.e., admin, administrator, the organization's name, or a combination of the two), businesses should have unique usernames.


  • USERNAMES: admin, administrator, username, test, admin1, office, sysadmin, default, guest, public, 123456, user
  • PASSWORDS: 123456, passw0rd, password1, admin1234, monkey!, test1234, changeme!, letmein1234, qwerty, login

PCI requires an account lock be set to six consecutive failed login attempts within a 30-minute period. Requiring an administrator to manually unlock accounts will prevent attackers from guessing hundreds of passwords consecutively. If an attacker only has six chances to guess the correct password, their attempts will likely fail. Once locked out, they will move on to an easier target.


System security should not be based solely on the complexity of a single password. No password should be considered uncrackable. That’s why multi-factor authentication (MFA) is the most effective solution to secure remote access and is a requirement under the PCI DSS.

Unfortunately, smaller merchants often fail to properly implement multi-factor authentication.

Configuring multi-factor authentication requires at least two of the following three factors:

  • Something you know (e.g., a username and password, PIN number)

  • Something you have (e.g., hardware token, smartcard)

  • Something you are (e.g., a fingerprint, ocular scan, voiceprint)

A few examples of effective multi-factor authentication for remote access could include:

  • The remote user enters their username and password, and then must enter an authentication code that is available to them through an RSA token in their possession.

  • The remote user enters a password and biometric to log in to a smartphone or laptop. The individual then provides a single authentication factor (e.g., another password, digital certificate, signed challenge response) to connect to the corporate network.

Your authentication mechanisms should be independent of each other. Or in other terms, there’s a physical separation between mechanisms, so that access to one factor does not grant access to another, and if one factor is compromised, it does not affect the integrity and confidentiality of any other factor.

Additionally, make sure that you “incorporate multi-factor authentication for all remote network access (both user and administrator, and including third-party access for support or maintenance) originating from outside the entity’s network.” 

If a remote access application configuration only requires a username and password, the application has been configured insecurely.

Download the latest guide to PCI compliance

Download Now



Requirement 8 is all about having unique ID information. For example, you must have your own unique ID credentials and account on your mobile devices, with strong password cryptography.

Do not use generic accounts, shared group passwords, or generic passwords.

As a system administrator, it’s a best practice to have a regular account that is used for day-to-day work on your laptop and a different administrative account when performing administrative functions on the systems you manage.

All non-console administrative access to in-scope systems requires multi-factor authentication.

Security professionals recognize that passwords are no longer sufficient to secure data. Passwords are still required, but simply not secure enough. You must set strong, long passwords. To meet PCI requirements, a password must contain at least seven characters and be complex, with both alphabetic and numeric characters.

An easy way to remember complex passwords is by using pass phrases. Pass phrases are groups of words with spaces in between (e.g., “We Never Drove Toward Vancouver?”). A pass phrase can contain symbols and upper- and lower-case letters. It doesn’t have to make sense grammatically. Pass phrases are generally easier to remember but harder to crack than shorter passwords.

In addition to strong pass phrases, password manager software can help you use different passwords for all of your accounts. Some password managers can even work across multiple devices through use of a cloud-based service.

You really need different passwords for different services, so that if one service gets compromised, it doesn’t bleed into other sites’ passwords.

For example, if your email account password is compromised and you use the same password across several devices and websites, you have a major security problem on your hands.






Employees may think physical security only applies after hours. However, most data thefts (e.g., social engineering attacks) occur in the middle of the day, when your staff is too busy with various assignments to notice someone walking out of the office with a server, company laptop, or other mobile device.

The best way to control physical threats is through a physical security policy that includes all policies and procedures involved in preserving onsite business security. For example, if you keep confidential information, products, or equipment in the workplace, keep these items secured in a locked area. If possible, limit outsider access to one monitored entrance, and (if applicable) require non-employees to wear visitor badges.

Don’t store sensitive information in the open. For example, many hotels keep binders full of credit card numbers behind the front desk or piled on the fax machine for easy reservation access. While this collection of files makes life easier for employee, it puts criminals within reach of this sensitive information.

Employee access to sensitive areas should be controlled and must be related to an individual’s job function.

To comply with this requirement, you must document:

  • Who has access to secure environments and why they need this access

  • What, when, where, and why devices are used

  • A list of authorized device users

  • Locations where the device is and is not allowed

  • What applications can be accessed on the device

Access documentation must be kept up to date, especially when individuals are terminated or their job role changes.

Best practice is not to allow these removable devices leave the office, but if they do, consider attaching external GPS tracking technology and remote wipe on all laptops, tablets, external hard drives, flash drives, and mobile devices.

The majority of physical data thefts take only minutes to plan and execute.

In addition, make sure all workstations have an automated timeout/logout on computers and devices (e.g., a password-protected screensaver pops up on a computer after a set amount of time). This makes it more difficult for thieves to access data from these workstations when employees aren’t there.



Organizations that use POS systems, PIN pads, and mobile devices are required to do three new things:

  1. Maintain an up-to-date list of all devices (9.9.1) including physical location, serial numbers, make, and model.

  2. Periodically inspect devices (9.9.2). You should ensure device surfaces haven’t been tampered with, make sure serial numbers match, and check that seals haven’t been broken. This could be a very large task depending on the size of your organization. Whether you inspect devices every day or every month is based on your tampering risk level (e.g., publically accessible 24/7 gas station terminals vs. a behind-the-counter card swipe device). Document your findings.

  3. Provide staff awareness training (9.9.3) for staff who interact with card-present devices on a day-to-day basis (e.g., cashiers), and record the who, what, and when for future reference. Ideally, training will help staff detect suspicious activity around a payment device. Training should include how to report suspicious behavior and what to do when third parties claim they need to work on your system. For example, rather than assuming IT came in last night to install a new device on the side of a terminal, staff should question if it’s supposed to be there, and then notify appropriate persons.

Have an Upcoming PCI Audit Deadline?

Request a Quote Here


While you may understand how to protect customer card information, your employees may not. That’s why regular security trainings are so important.

For example, social engineering is a serious threat to both small and large businesses. A social engineer uses social interaction to gain access to private areas, steal information, or perform malicious behavior. Employees fall for their tricks more often than you may think.

For example, if someone walked into your storefront and said they were there to work on your network and needed you to lead them to the server room, would your employees think twice to further identify them and verify their presence?

Train your employees to question everything. It’s better to be safe than sorry. Establish a communication and response policy in case of suspicious behavior. Train employees to stop and question anyone who does not work for the company, especially if the person tries to enter the back office or network areas.


Most physical security risks can be prevented with little effort. Here are a few suggestions to improve your physical security:

  • While working on your risk assessment, look for physical security risks.

  • Lock all office doors and applicable equipment (e.g., mobile devices) when not in use day and night.

  • Require passwords to access computers and mobile devices.

  • Encrypt your data or don’t store data on these devices.

  • Use screensavers and privacy monitors on computers.

  • Install and use blinds in all office windows.

  • Keep logs of who enters and leaves.

  • Keep track of devices that go in and out.

  • Have policies in place for stolen equipment (e.g., a good incident response plan).

  • Train staff against social engineering.

  • Limit access to CHD through role-based access.

  • Have staff report suspicious people and devices.

  • Monitor sensitive areas with video cameras and store the video logs for appropriate durations.



Having electronic access on doors, using cameras to monitor all entries and exits to secure areas, implementing multiple levels of access based on a business need, and approving visitor/employee access are standard for basic security.

Once you know what systems you need to protect, put controls in place that restrict access to them (e.g., badge readers).

Today, you see more organizations hosting their systems in outsourced data centers. Data centers generally have great physical security because they pay attention to the basics. They use cameras to monitor all entries and exits, have multiple levels of access (e.g., lobby, mantrap, hallways, data floors, and cages) to segment areas and limit access only to individuals with approved access. They also use different levels of authentication requiring both badge and biometrics (e.g., fingerprint, retina) for access.

Digital IP-based cameras are becoming more common, making it easier and more cost effective to deploy and monitor camera systems. These cameras can take snapshots of people and then send those snapshots to security supervisors for verification.

It’s also necessary to protect card-swipe devices. Merchants must monitor these devices for tampering or complete replacement. Make sure attackers don’t substitute, bypass, or steal your terminal. You and your employees must know what the tamper properties are (e.g., seals, appearance, weight) and test them often. Security best practice is to mount devices with tamper-resistant stands and screws.






System event logs are recorded tidbits of information regarding the actions taken on computer systems like firewalls, office computers, or printers.

Log monitoring systems (e.g., Security Information and Event Management [SIEM] tools) oversee network activity, inspect system events, alert you to suspicious activity, and store user actions that occur inside your systems. They’re your watchtower lookouts and can provide the warning data that could alert you to a data breach. The raw log files are also known as audit records, audit trails, or event logs.

Most systems and software generate logs including operating systems, Internet browsers, POS systems, workstations, anti-malware, firewalls, and IDS. Some systems with logging capabilities do not automatically enable logging, so it’s important to ensure all systems are creating and collecting logs. Some systems generate logs but don’t provide event log management solutions. Be aware of your system capabilities and install third-party log monitoring and management software as needed.



Businesses should review their logs daily to search for errors, anomalies, or suspicious activities that deviate from the norm.

From a security perspective, the purpose of a log alert is to act as a red flag when something bad is happening. Reviewing logs regularly helps identify malicious attacks on your system. Given the large amount of log data generated by systems, it’s impractical to manually review all logs each day. Log monitoring software takes care of this task by using rules to automate log review and only alert on events that might be real problems. Often this is done using real-time reporting software that alerts you via email or text when suspicious actions are detected.

Often, log monitoring software comes with default alerting templates to optimize monitoring and alerting functions immediately. However, not everyone’s network and system designs are the same, and it’s critical to take time to correctly configure your alerting rules at the beginning.

Logs are only useful if they are regularly reviewed.

Download the latest guide to PCI compliance

Download Now


Here are some event actions to consider when setting up your log management system rules:

  • Password changes

  • Unauthorized logins

  • Login failures

  • New login events

  • Malware detection

  • Malware attacks seen by IDS

  • Denial of service attacks

  • Errors on network devices

  • File name changes

  • File integrity changes

  • Data exported

  • Shared access events

  • Disconnected events

  • File auditing

  • New service installation

  • New user accounts

  • New processes started or running processes stopped

  • Modified registry values

  • Scans on your firewall’s open and closed ports

To take advantage of log management, look at your security strategy and make sure the following steps are taken care of:

  • Decide how and when to generate logs.

  • Secure your stored logs so they aren’t maliciously altered by cybercriminals or accidentally altered by well-intentioned employees.

  • Assign an employee you trust to review logs daily.

  • Set up a team to review suspicious alerts.

  • Spend time to create rules for alert generation (don’t just rely on a template).

  • Store logs for at least one year, with three months readily available.

  • Frequently check log collection to identify necessary adjustments.

Regular log monitoring means a quicker response time to security events and better security program effectiveness. Not only will log analysis and daily monitoring demonstrate your willingness to comply with PCI DSS requirements, it will also help defend against insider and outsider threats.

Organizations should review their logs daily to search for errors, anomalies, or suspicious activity that deviates from the norm.



Given the large amount of log data generated by systems, it’s virtually impossible to manually analyze logs beyond one or two systems.

You likely need SIEM tools to sift through logs and drill down into problems. In the past, SIEM systems were mainly utilized by large corporations, but smaller companies now realize system monitoring can help identify attacks.

Organizations often struggle with good log review processes. Using SIEM tools can enable you to have real-time alerting to help you recognize a current attack. If you really do have an incident, you can initiate your incident response plan (IRP).

Regular log monitoring means a quicker response time to security events and improved security program effectiveness.

To correlate events over multiple systems you must synchronize system times. All systems should get their system time from one or two internal time servers, which in turn receive time from a trusted external source.

PCI DSS 3.2.1 requires service providers to implement a process to detect and respond to failures of critical security controls in a timely manner. You need to be able to detect these failures and have defined incident responses in place. Your response plans not only need to address the response to fix the problem but also identify risks created by the failure, identify root causes, document lessons learned, and implement any necessary changes to prevent failures from happening again.






A business’s IT environment influences the kind of attacks to which they’re susceptible; therefore, every security plan should be tailored to each individual network environment.

Defects in web browsers, email clients, POS software, operating systems, and server interfaces can allow attackers to gain access to an environment. Installing security updates and patches for systems in the cardholder or sensitive data environments can help correct many of the newly found defects and vulnerabilities before attackers have the opportunity to leverage them.

In the case of custom in-house applications, code testing and independent internal penetration testing can expose many of the weaknesses commonly found in application code (especially home-grown varieties).

These types of testing are the best course of defense in identifying weaknesses before deployment.



A vulnerability scan is an automated, high-level test that looks for and reports potential vulnerabilities. All external IPs and domains exposed in the CDE are required to be scanned by a PCI Approved Scanning Vendor (ASV) at least quarterly.

PCI DSS requires two independent methods of PCI scanning: internal and external scanning. An external vulnerability scan is performed outside of your network; it identifies known weaknesses in network structures. An internal vulnerability scan is performed within your network, and it looks at other hosts on the same network to identify internal vulnerabilities.

Think of your environment as a house. External vulnerability scanning is like checking to see if doors and windows are locked, while internal vulnerability scanning is like testing to see if bedroom and bathroom doors are locked.

Vulnerability scanning identifies potential harmful vulnerabilities, so you can remediate processes to ensure network security.

Typically, vulnerability scans will generate an extensive list or report of vulnerabilities found and references for further research on these vulnerabilities. Some reports even offer further directions for how to fix the problems.

Despite what many businesses believe, scanning is not enough. You can’t just scan and sit on the report. Act quickly on any vulnerabilities discovered to ensure security holes are plugged and then re-scan to validate that the vulnerabilities have been successfully addressed.



Quick, high-level look at possible vulnerabilities

False positives

Very affordable compared to penetration testing
Businesses must manually check each vulnerability before testing again

Automatic (can be automated to run weekly, monthly, quarterly)

Does not confirm a vulnerability is possible to exploit



  1. TLS Version 1.0 Protocol Detection: Exists if the remote service accepts connections using TLS 1.0 encryption.
  2. SSL Medium Strength Cipher Suites Supported: Occurs when a remote host supports the use of SSL ciphers that offer medium strength encryption.
  3. SSL 64-bit Block Size Cipher Suites Supported (Sweet32): Exists if a remote host supports the use of a block cipher with 64-bit blocks in one or more cipher suites.
  4. SSL Certificate with Wrong Hostname: Happens when an SSL certificate for the tested service is for a different host.
  5. SSL Self-Signed Certificate: Occurs when organizations use an identity certificate that they create, sign, and certify rather than a trusted certificate authority (CA).


For many organizations, external scans must be performed by a PCI ASV to validate PCI compliance.

An ASV is required to go through a rigorous yearly re-certification process, during which each ASV runs their PCI scanning tool on PCI Council-approved sites planted with vulnerabilities to test which vulnerabilities the tool finds and misses.

But just because an ASV runs your external vulnerability scan, this doesn’t mean your organization is secure. After receiving your scan report, you’re responsible for fixing any discovered vulnerabilities and then rescan your environment until vulnerabilities have been properly addressed.

PCI Approved Vulnerability (ASV) Scans

Learn More


People often assume that if an ASV handles their PCI scans, it means they’re compliant. However, if your ASV currently performs your external quarterly scans, understand they’re not likely handling your internal quarterly vulnerability scanning. 

Your ASV may have set up an internal vulnerability scanning tool or appliance, but chances are, they’re not handling or monitoring your internal vulnerability scanning requirements. Make sure that your internal vulnerability scans are actually being routinely performed.

There are a variety of tools to help you comply with internal vulnerability scan requirements. For example, you can:

  • Purchase an internal vulnerability scanning tool from your ASV or another service provider.

  • Download an open source internal vulnerability scanning tool.

Keep in mind that the scanning tool you use still needs to be configured by a security expert after you purchase or download it.

Typically, if you purchase a vulnerability scanning tool or appliance, IT support service is included. But if you download scanning tools, take time to research and implement configuration best practices.

Remember, your organization is in charge of internal vulnerability scanning from initial download or purchase, configuration, actual scanning, and alert analysis through vulnerability management.

On average, it took SecurityMetrics customers 1.68 scans to achieve a passing status.



Similar to a hacker, penetration testers analyze network environments, identify potential vulnerabilities, and try to exploit those vulnerabilities (or coding errors). In simple terms, penetration testing analysts attempt to break into your company’s network to find security holes and let you know about discovered vulnerabilities.

A penetration test is a thorough, live examination designed to exploit weaknesses in your system. 

Depending on your SAQ, PCI DSS requirement 11.3may require an internal and external penetration test. But penetration testing isn’t limited to the PCI DSS. Any company can request a penetration test whenever they wish to measure their business security.

The time it takes to conduct a penetration test varies based on network size, network complexity, and the individual penetration test staff members assigned. A small environment can be completed in a few days, but a large environment can take several weeks.

Typically, penetration test reports contain a long, detailed description of attacks used, testing methodologies, and suggestions for remediation.

In addition to annual penetration tests, perform a penetration test whenever large infrastructure changes occur to see if these changes add any new vulnerabilities.



Live, manual tests mean more accurate and thorough results

Time (1 day to 3 weeks)

Rules out false positives
Cost (around $15,000 to $30,000)

Do You Need a Penetration Test?

Find out Here



The objective of a network penetration test is to identify security issues with the design, implementation, and maintenance of servers, workstations, and network services.

Commonly identified security issues include:

  • Misconfigured software, firewalls, and operating systems

  • Outdated software and operating systems

  • Insecure protocols



The objective of a segmentation check is to identify whether there is access into a secure network because of a misconfigured firewall.

Basically, segmentation checks confirm if network segmentation was set up properly.

For service providers that use segmentation, you’re required to conduct penetration tests on segmentation controls every six months and after any significant change to segmentation controls/methods.

Commonly identified security issues include:

  • TCP access is allowed where it should not be

  • ICMP (ping) access is allowed where it should not be


The objective of an application penetration test is to identify security issues resulting from insecure development practices in the design, coding, and publishing of the software.

Commonly identified security issues include:

  • Injection vulnerabilities (e.g., SQL injection, cross-site scripting, remote code execution)

  • Broken authentication (i.e., the log-in panel can be bypassed)

  • Broken authorization (i.e., low-level accounts can access high- level functionality)

  • Improper error handling


The objective of a wireless penetration test is to identify misconfigurations of authorized wireless infrastructure and the presence of unauthorized access points.

Commonly identified security issues include:

  • Insecure wireless encryption standards

  • Weak encryption passphrase

  • Unsupported wireless technology

  • Rogue and open access points


The objective of a social engineering assessment is to identify employees that do not properly authenticate individuals, follow processes, or validate potentially dangerous technologies. Any of these methods could allow an attacker to take advantage of the employee and trick them into doing something they shouldn’t.

Commonly identified security issues include:

  • Employee(s) clicked on malicious emails

  • Employee(s) allowed unauthorized individuals onto the premises

  • Employee(s) connected a randomly discarded or discovered USB to their workstation



Some mistakenly believe vulnerability scanning are the same as a professional penetration test.

Here are the two biggest differences:

  • A vulnerability scan is automated, while a penetration test includes a live person actually digging into the complexities of your network.

  • A vulnerability scan only identifies vulnerabilities, while a penetration tester digs deeper to identify the root cause of the vulnerability that allows access to secure systems or stored sensitive data.

Vulnerability scans and penetration tests work together to encourage optimal network security.

Vulnerability scans are great weekly, monthly, or quarterly insight into your network security, while penetration tests are a more thorough way to examine your security.

Do You Need a Penetration Test?

Find out Here



Whenever large infrastructure changes occur, PCI DSS requires a formal penetration test to see if these changes added any new vulnerabilities.

Even though the necessity for an annual penetration test is apparent, organizations often claim no significant infrastructure changes have been made because the cost and time of a full-blown penetration test can seem overwhelming.

My advice is this: first establish what your organization considers a major change. What might be a major change to a smaller organization is only a minor change in a large environment. For either size organization, if you bring in new hardware or start accepting payments in a different way, this constitutes a major change.

Perform a penetration test at least yearly and after major network changes.

The next step is to establish an assessment policy. Some organizations designate a department separate from the infrastructure team to conduct self-assessments. Others hire penetration testers to conduct these types of assessments.






Not only do you need policies and procedures to be in place, you also need to have them documented. Policies should be written down and easily accessible by all employees.

Documentation may also help protect your business from potential liability in the event of a breach. Thorough and accurate documented security policies and procedures helps forensic investigators see what security measures your company has in place.

Service providers must have executive management create a PCI DSS Charter. This Charter must establish responsibility for the protection of cardholder data and a PCI DSS compliance program, including overall accountability for maintaining PCI DSS compliance. It must also define how the person responsible for PCI DSS compliance and executive management will communicate.

To fulfill requirement 12.8.5, you must have a list of all third-party service providers you use, the PCI requirements these service providers handle, and the PCI requirements you are required to meet.

Documents you’ll want to include in your security policy:

  • Employee manuals

  • Policies and procedures

  • Third-party vendor agreements

  • Incident response plans

For PCI compliance, regularly updated documentation of all security measures and actions is vital.


Requirement 12.2requires all entities annually perform a formal risk assessment that identifies critical assets, threats, vulnerabilities, and risks. This requirement helps organizations identify, prioritize, and manage information security risks.

Organizations that take a proactive approach to security will use internal and external resources to identify critical assets, assess vulnerability threats against those assets, and implement a risk management plan to mitigate those threats.

A risk assessment should occur at least annually and after significant changes in your network. This will help provide direction on what vulnerabilities you should address first. Addressing vulnerabilities decreases the time an attacker can compromise the system (i.e., window of compromise).

Remember, just because a system is vulnerable, it doesn’t mean a system is exploitable or even likely to be exploited. Some vulnerabilities may require so many preconditions that the chance of a successful attack is virtually none.

Identifying the differing levels of exploitability should help an organization prioritize the actions it should take to enhance its IT security based on each identified vulnerability’s perceived threat and risk level.

The purpose of the risk assessment is to help organizations document potential security vulnerabilities, threats, and risks.

Need Security Training for Your Team?

Start Here


If you think your employees know how to secure cardholder data and what they’re required to do, you’re sadly mistaken. In fact, most breaches originate from employees. Although most workers aren’t malicious, they often either forget security best practices or don’t know exactly what they’re required to do.

Unfortunately, many hackers will take advantage of human error to gain access to sensitive data. For example, when workforce members leave mobile devices in plain sight and unattended. Hackers may access networks because workforce members set up easy-to-guess passwords. And the list goes on.

By holding employees accountable, you can protect your business and customers more effectively. 

To help protect sensitive data, employees need to be given specific rules and regular training. Regular training (e.g., brief monthly training) will remind them of the importance of security, especially keeping them up to date with current security policies and practices. Here are some tips to help employees protect your sensitive data:

  • Set monthly training meetings: Focus each month on a different aspect of data security, such as passwords, social engineering, or email phishing.

  • Give frequent reminders: These security best practices could be sent out in an email, newsletter, during standup meetings, and PCI DSS security webinars that include tips for employees.

  • Train employees on new policies ASAP: Newly hired employees should be trained on security and PCI policies as quickly as possible.

  • Make training materials easily available: Intranet sites are a great way to provide access to training and policy information.

  • Create incentives: Reward your employees for being proactive.

  • Regularly test employees: Create an environment where employees aren’t afraid to report suspicious behavior. 



First, make PCI compliance a regular business practice. If you view compliance as a once-a-year task, you’ll probably struggle and slip in

and out of compliance regularly. Your PCI compliance efforts should encourage a cultural shift to common corporate culture practices. You can’t bypass the process.

Second, document everything, including all processes, policies, roles, and responsibilities. Additionally, make sure all service providers sign PCI DSS compliance business agreements. For each service provider you use, document their PCI DSS responsibilities. Ensure your service providers are PCI compliant at least on a yearly basis.

Your security policies and procedures should be living documents.

Finally, conduct a risk assessment. Your environment may require going beyond PCI requirements to secure your payment data. That’s why you need an annual process review, documentation of the review, regular risk assessments, and updated policies.

When conducting your risk assessment, look at what’s happening in your industry and analyze common breaches. Build your policy around what you discover.


Download the latest guide to PCI compliance

Download Now



The cost of PCI compliance depends entirely on your organization. Here are a few variables that will factor in to the cost of your overall compliance to the PCI DSS:

  • Your business type (e.g., franchise, service provider, mom-and-pop shop): Each business type will have varying amounts of transactions, cardholder data, environment structure, risk levels, and merchant or service provider levels, meaning that each business will have different security requirements.

  • Your organization size: Typically, the larger the organization, the more potential vulnerabilities it has. More staff members, more programs, more processes, more computers, more cardholder data, and more departments mean more cost.

  • Your organization’s environment: The type of processing systems, the brand of computers, the kind of firewalls, and the model of back-end servers can all affect your PCI cost.

  • Your organization’s dedicated PCI staff and outside help: Even with a dedicated team, organizations usually require outside assistance or consulting to help them meet PCI requirements.

The following are estimated annual PCI budgets:


Self-assessment questionnaire (SAQ)


Vulnerability scan
$100-$150 per IP address
Training and policy development
$70 per employee





Onsite audit


Vulnerability scan
Penetration testing
Training and policy development



Keep in mind this budget doesn’t include remediation security measures, such as firewalls, encryption, updating systems and equipment.



File integrity monitoring (FIM) software is a great companion for your malware prevention controls. New malware comes out so frequently you can’t just rely on anti-virus software to protect your systems. It often takes many months for a signature of newly detected malware to make it into the malware signature files, which allows it to be detected by anti-virus software.

Configure FIM software to watch critical file directories for changes. FIM software is typically configured to monitor areas of a computer’s file system where critical files are located. FIM tools will generate an alert that can be monitored when a file is changed.

Malware is software that consists of files that are copied to a target computer. Even if your AV software cannot recognize the malware files signatures, FIM software will detect that files have been written to your computer and will alert you to check and make sure you know what those files are. If the change was known (like a system update), then you are fine. If not, chances are you have new malware added that could not be detected and can now be dealt with.

Here are some places where FIM should be set up to monitor:

  • OS critical directories

  • Critical installed application directories

  • Web server and/or web application directories

  • User areas (if an employee facing computer)

FIM can also be set up to check if web application code or files are modified by an attacker.


One of the reasons data breaches are so prevalent is a lack of proactive, comprehensive security dedicated to monitoring system irregularities, such as intrusion detection systems (IDS) and intrusion prevention systems (IPS).

Using these systems can help identify a suspected attack and help you locate security holes in your network that attackers used. Without the knowledge derived from IDS logs, it can be very difficult to find system vulnerabilities and determine if cardholder data was accessed or stolen.

By setting up alerts on an IDS, you can be warned as soon as suspicious activity is identified and be able to significantly minimize compromise risk within your organization. You may even stop a breach in its tracks.

From a legal standpoint, organizations could also use information stored by their IDS in a breach court case to show that they did as much as possible to contain the breach.

Forensic investigators (like the SecurityMetrics PFI team) can use information gleaned from client IDS tools, as well as all system audit logs, to investigate breaches.

An IDS could help you detect a security breach as it’s happening in real time.

Keep in mind that an IDS isn’t preventive. Similar to a private investigator, an intrusion detection system doesn’t interfere with what it observes. It simply follows the action, takes pictures, records conversations, and alerts their client.

For more preventive measures, you might consider an intrusion prevention system (IPS), which also monitors network activity for malicious activities, logs this information, and reports it; but it can prevent and block many intrusions that are detected. Intrusion prevention systems can drop malicious packets, block traffic from the malicious source address, and resetting connections.

In addition to these, you should have data loss prevention (DLP) software in place. DLP software watches outgoing data streams for sensitive or critical data formats that should not be sent through a firewall, and it blocks this data from leaving your system.

Make sure to properly implement it, so that your DLP knows where data is allowed to go, since if it’s too restrictive, it might block critical transmissions to third party organizations.


Unless someone oversees PCI on management’s side (not just IT), PCI compliance won’t happen. We often see companies with various groups (e.g., networking, IT, HR, Risk) expecting other departments to take charge of PCI compliance. Other times, organizations expect a QSA to be the PCI project manager, which is not feasible.

Security is not a bottom-up process. Management often says or implies that IT should “just get their organization secure.” However, those placed in charge of PCI compliance and security may not have the means necessary to reach their goals.

For example, IT may not have budget to implement adequate security policies and technologies (e.g., firewalls, FIM). Some may try to look for free software to fill in security gaps, but this process can be expensive due to the time it takes to implement and manage. In some instances, we have seen that the IT department wanted their PCI auditor to purposely fail their compliance evaluations so they could prove their higher security budget needs. Obviously, it would have been better to focus on security from the top level down beforehand.

Keep in mind that checkbox attitudes lead to breaches. C-Level management should support the PCI process. If you are a C-level executive, you should be involved with budgeting, assisting, and establishing a security culture from the top-down.


If you’re having problems communicating budgetary needs to management, conduct a risk assessment before starting the PCI process. NIST 800-30 is a good risk assessment protocol to follow. At the end of your assessment, you’ll have an idea of your compromise probability, how much a compromise would cost, and the impact a breach might have on your organization (including brand damage).

Simply put, find a way to show how much weak security will cost the organization. For example, “if someone gains access to the system through X, this is how much it will cost and damage our brand.” Consider asking marketing or accounting teams for help delivering the message in more bottom-line terms. 

If possible, work with a QSA to come up with security controls to address what tools you may need to implement.

Have an Upcoming PCI Audit Deadline?

Request a Quote Here



The PCI DSS does not change based on the size of the company or their cardholder data environment, but PCI challenges can vary significantly.

It has been my experience that small merchants and service providers tend to struggle with documenting and following policies and procedures. During a PCI DSS assessment, a QSA will verify that required policies and procedures are in place and being followed.

Smaller merchants and service providers whose CDE consists of only a few machines often feel that they don’t have the time to document procedures. Unfortunately, it’s not uncommon to perform a renewal assessment where they neglected to maintain compliance due to employee turnover and lack of documentation.

At a minimum, small merchants should set up a PCI email user or active directory account and add reminders in their calendar to perform security processes throughout the year (e.g., quarterly vulnerability assessment scans, semi-annual firewall reviews). The evidence collected from these tasks can then be sent to that PCI account for storage. This is a low cost solution that can help key personnel keep PCI DSS compliance on their minds throughout the year. It will also help document necessary evidence for their annual self-assessment (or to their assessor).

Large enterprise organizations are usually sufficient at documenting their policies and procedures. They generally have very specific and thorough change control processes, and they typically follow documented approval processes prior to implementing changes to their CDE. Unfortunately, due to their size and the different entities involved in their CDE management, their reaction time tends to be much slower, with different stakeholders often making contradictory decisions. When vulnerability scans or penetration tests identify weaknesses that may place their CDE at risk, it’s not always apparent which group should be responsible for addressing these vulnerability.

To help address some of these concerns, requirement 12.4.1 requires service providers to define a charter for the organization’s compliance program, involving executive management. While this is only required for service providers, it’s recommended that larger merchants follow this requirement as well.

Large organizations and service providers should establish an official PCI Charter that describes the management and accountability of the organizations compliance program (requirement 12.4.1). Additionally, they should implement internal audit procedures to ensure security practices are properly in place throughout the year (requirement 10.8 and 12.11). 

PCI compliance cannot just be an annual audit event.

Often, organizations are not leveraging many of the PCI requirements in a way that actually increases security for their CDE.

For instance, PCI requires log centralization and daily reviews. PCI also requires change detection or FIM on CDE systems to detect unauthorized changes to key files and directories. To achieve compliance, organizations might set up log monitoring and FIM, but then ignore every alert coming their way. They may technically have FIM and log monitoring in place, but these systems alone are not making their environments more secure. 

If organizations do not take the necessary time and effort to respond to genuine alerts, the only thing they will gain are checkmarks on their SAQ.




Advanced Encryption Standard (AES): A government encryption standard to secure sensitive electronic information.

Approved Scanning Vendor (ASV): A company approved by the PCI SSC to conduct vulnerability scanning tests.

Captured: Data is being recorded, gathered, and/or stored from an unauthorized source.

Card Verification Value (CVV/CSC/CVC/CAV): Element on a payment card that protects information on the magnetic stripe. Specific acronyms depend on the card brand.

Cardholder Data Environment (CDE): Any individual, software, system, or process that processes, stores, or transmits cardholder data.

Cardholder Data (CHD): Sensitive data found on payment cards, such as an account holder name or PAN data.

Data Loss Prevention (DLP): A piece of software or strategy used to catch unencrypted data sent outside the network.

Domain Name Server (DNS): A way to translate URLs to IP addresses.

Exfiltrated: Unauthorized data is transferred from a system.

File Integrity Monitoring (FIM): A method to watch for changes in software, systems, and applications to detect potential malicious activity.

File Transfer Protocol (FTP): An insecure way to transfer computer files between computers using the Internet. (See SFTP)

Firewall (FW): A system designed to screen incoming and outgoing network traffic.

Hypertext Transfer Protocol (HTTP): A method of communication between servers and browsers. (See HTTPS)

Hypertext Transfer Protocol Over Secure Socket Layer (HTTPS): A secure method of communication between servers and browsers. (See HTTP)

Incident Response Plan (IRP): Policies and procedures to effectively limit the effects of a security breach.

Information Technology (IT): Anything relating to networks, computers, and programming, and the people that work with those technologies.

Internet Protocol (IP): Defines how computers send packets of data to each other.

Intrusion Detection System/Intrusion Prevention System (IDS/IPS): Types of systems that are used to monitor network traffic and report potential malicious activity.

Multi-factor Authentication (MFA): Two out of three independent methods of authentication are required to verify a computer or network user. The three possible factors are:

  • Something you know (such as a username and password)

  • Something you have (such as an RSA token or one-time password token)

  • Something you are (such as fingerprint or iris scans)

National Institute of Standards and Technology (NIST): Federal agency that measures standards and maintains the National Vulnerability Database (NVD).

National Vulnerability Database (NVD): A repository of all known vulnerabilities, maintained by NIST.

Network Access Control (NAC): Restricts data that users, apps, and programs can access on a computer network.

Open Web Application Security Project (OWASP): A non-profit organization focused on software security improvement. Often heard in the context of “OWASP Top 10,” a list of top threatening vulnerabilities.

Payment Application Data Security Standard (PA DSS): Validation standard for software applications that store, process, or transmit cardholder data.

Payment Application Qualified Security Assessor (PA QSA): Individual or organization qualified by the PCI SSC to conduct PA DSS audits.

Payment Card Industry Data Security Standard (PCI DSS): Requirements put together by the PCI SSC, required of all businesses that process, store, or transmit payment card data to help prevent cardholder data theft.

Payment Card Industry Security Standards Council (PCI SSC): An organization established in 2006 by Visa, MasterCard, American Express, Discover Financial Services, and JCB International to regulate cardholder data security.

Point-To-Point Encryption (P2PE): Payment card data encryption from the point of interaction to a merchant solution provider.

Primary Account Number (PAN): The 14 or 16 digits that identify a payment card. Also called a bank card number.

Qualified Integrator or Reseller (QIR): A third party qualified by the PCI SSC to use security best practices while installing or maintaining payment systems.

Qualified Security Assessor (QSA): Individuals and firms certified by the PCI SSC to perform PCI compliance assessments.

Role-Based Access Control (RBAC): The act of restricting users’ access to systems based on their role within an organization.

Secure File Transfer Protocol (SFTP): A secure way to encrypt data that is in transit.

Secure Socket Layer (SSL): An outdated Internet security standard for encrypting the link between a website and a browser to enable transmission of sensitive information (predecessor to TLS).

Self-Assessment Questionnaire (SAQ): A collection of questions used to document an entity’s PCI DSS assessment results, based on their processing environment.

Transport Layer Security (TLS): A more secure Internet security standard for encrypting the link between a website and a browser to enable transmission of sensitive information (See SSL)

Virtual Private Network (VPN): A strategy of connecting remote computers to send and receive data securely over the Internet as if they were directly connected to the private network. 

Vulnerable: A system, environment, software, and/or website can be exploited by an attacker.

Web Application Firewall (WAF): An application firewall that monitors, filters, and blocks HTTP traffic to and from a web application.

Wi-Fi Protected Access (WPA): A security protocol designed to secure wireless computer networks.

Wi-Fi Protected Access II (WPA2): A more secure version of WPA. (See WPA)

Wired Equivalent Privacy (WEP): An outdated and weak security algorithm for wireless networks.

Wireless Local Area Network (WLAN): A network that links to two or more devices wirelessly.

Download the latest guide to PCI compliance

Download Now





We help customers close data security and compliance gaps to avoid data breaches. We provide managed data security services and are certified to help you achieve the highest data security and compliance standards.

We are a PCI certified Approved Scanning Vendor (ASV), Qualified Security Assessor (QSA), Certified Forensic Investigator (PFI), and Managed Security provider with 18 years of data security experience. From local shops to some of the world’s largest brands, we help all businesses achieve data security through managed services and compliance mandates (PCI, HIPAA, GDPR). We have tested over 1 million systems for data security and compliance. We are privately held and are headquartered in Orem, Utah, where we maintain a Security Operations Center (SOC) and 24/7 multilingual technical support.

Have an Upcoming PCI Audit Deadline?

Request a Quote Here