Document Comparison

PCI_DSS_V3.0_Best_Practices_for_Maintaining_PCI_DSS_Compliance.pdf PCI_DSS_V2.0_Best_Practices_for_Maintaining_PCI_DSS_Compliance.pdf
24% similar
26 → 51 Pages
9361 → 18106 Words
106 Content Changes

From Revision History

  • August 2014 1.0 Initial release

Content Changes

106 content changes. 29 administrative changes (dates, page numbers) hidden.

Added p. 1
18-Jan-2019 Error! Unknown document property name.
Added p. 1
• PCI Mobile Payment Acceptance Security Guidelines Version: 2.0 Date: January 2019 Author: Maintaining PCI DSS Compliance Special Interest Group
Added p. 2
Document Changes Date Version Description

August 2014 1.0 Initial release

January 2019 2.0 Updated by 2018 Maintaining PCI DSS Compliance SIG. Changes include:

• Restructure of the document for better flow (e.g., consolidation of Section 2, and moving Section 4.2 as to Section 3).

• New guidance on compliance program, scope and compensating control review, best practices to maintain evidence of security control effectiveness, security awareness, and monitoring compliance of third-party service providers.

• Added Appendix C to assist with identifying applicable PCI DSS requirements to asset types, and Appendix D to manage compliance monitoring activities.

• Updated guidance on responsibility for compliance, risk assessment, automated and manual control monitoring, review frequency, and sampling of controls.

• Enhanced guidance on measuring efficiency and effectiveness of security controls.

• Standardized terminology throughout the document.

• Updated references to PCI SSC and external resources.

• Minor grammatical updates.
Added p. 4
PCI DSS has steadily increased among organizations that store, process, and transmit cardholder data. The increase in PCI DSS compliance rates can likely be attributed to increased awareness of the standard, evolutions in card brand compliance programs and mandates, and an overall increase in the maturity of PCI DSS. However, despite these improvements, statistics show that most of these organizations still have yet to master ongoing PCI DSS compliance. 1 If organizations want to protect themselves and their customers from potential losses or damages resulting from a data breach, they must strive for ways to maintain a continuous state of compliance throughout the year rather than simply seeking point-in-time validation. A study conducted by Verizon from 2011 to 2017,2 on organizations that had a data breach, showed that many of the organizations that were assessed as being non-compliant at the time of their breach had successfully complied during their previous …
Added p. 5
1. Develop and Maintain a Sustainable Compliance Program

• For a compliance program to be sustainable, it should be implemented into business-as-usual activities as part of the organization’s overall security strategy. This enables the organization to monitor the effectiveness of its security controls on an ongoing basis and maintain compliance between assessments. The ongoing security of cardholder data should be the driving objective behind all PCI DSS compliance activities•not simply attaining a compliant report. (See 3.1, “Develop and Maintain a Sustainable Security Program.”)

2. Develop Program, Policy, and Procedures

• A PCI DSS compliance program that includes people, process, and technology along with supporting policies and procedures should be implemented to help drive proper behavior and to maintain repeatable business and operational processes. (See 3.2, “Program, Policy, and Procedures” for further information.)

3. Define Performance Metrics to Measure Success − An effective metrics program can provide useful data for directing the allocation of resources …
Added p. 6
7. Detect and Respond to Control Failures

• Organizations should have processes for recognizing and responding to security-control failures promptly. Any control failure could constitute a formal security incident and require a more formal incident response. At a minimum, control-failure response processes should include: minimizing the impact of the incident, restoring controls, performing root-cause analysis and remediation, implementing hardening standards, and enhancing monitoring. (See 3.7 “Detect and Respond to Security Control Failures,” for further information.)

8. Maintain Security Awareness

• Social engineering techniques are often leading to data breaches and exfiltration of critical data. Organizations should implement a formal security awareness process with content that is kept up to date with the latest trends in breaches.

(See 3.8, “Maintain Security Awareness,” for further information.)

9. Monitoring Compliance of Third-Party Service Providers

• Often, organizations will rely on third-party service providers to implement and maintain security controls required to meet

PCI DSS. Organizations should develop and implement processes …
Added p. 7
• Pressures to adapt to ever-increasing customer demands and emerging technologies and the resulting changes to an organization’s business goals, structure, and technology infrastructure.

• Organizational complacency, assuming what was good enough last year will be good enough in future years.

• Overconfidence in organizational practices, resulting in a lack of resources devoted to regular monitoring of compliance program effectiveness.

• Inability to assign the right people, tools, and processes, and lack of executive leadership commitment to maintaining compliance.

• Failure to accurately scope the organization’s cardholder data environment (CDE) as business practices evolve with the introduction of new products or services, or acquisitions.

In order to maintain a consistent level of security and compliance, organizations should have a well- designed program of security controls and monitoring practices in place to ensure that the intent of

PCI DSS is being met at all times.

Figure 1: Compliancy Curve 4 Verizon 2017 Payment Security Report Information Supplement

Too often …
Added p. 9
Any cardholder data not deemed critical to business functions should be removed from the environment in accordance with the organization’s data-retention policies. This helps reduce the complexity and costs associated with protecting this data. In addition, organizations should evaluate business and operating procedures for alternatives to retaining cardholder data.
Added p. 9
When designing a compliance program, it is important to understand the differences between these terms and concepts:

• A program typically includes strategic objectives, roles and responsibilities, and a plan to achieve business objectives. For example, a vendor-management program defines the roles and strategy to properly procure, on-board, manage, and off-board third-party service providers.

• A policy typically includes a statement of management intent or rules that must be followed⎯e.g., a password policy defining strong passwords and the frequency with which they must be changed.

• A process/procedure typically outlines the step-by-step tasks that responsible personnel must follow to properly complete tasks that align with the program and supporting policies⎯e.g., listing the steps needed to encrypt sensitive information before e-mailing it to a service provider.
Added p. 10
To facilitate ongoing and sustainable compliance with PCI DSS, implementation of a compliance program should be supported with policies and defined procedures. Once completed and approved, policies and procedures should be disseminated to all appropriate individuals and business partners to ensure consistent understanding of strategic objectives and implemented processes.
Added p. 10
The collection of metrics alone does not directly result in the ability to maintain PCI DSS compliance.
Added p. 10
• Percentage of information systems with password policies configured in accordance with policy (PCI DSS Requirements 8.1 and 8.2)

• Percentage of web servers configured in accordance with system configuration standards (PCI DSS Requirements 2.2, 2.3 and 10.4) 6 Elizabeth Chew, Marianne Swanson, Kevin Stine, Nadya Bartol, Anthony Brown, and Will Robinson, NIST Performance Measurement Guide for Information Security; SP 800-55 (revision 1) (NIST, 2008).

• Percentage of organizational personnel that have received security training (PCI DSS Requirements 6.5, 9.9.3, 12.6, and 12.10.4)
Added p. 11
- The frequency that a full inventory scan of all network assets (workstations, servers, routers, switches, access points, etc.) is run and the variability of the asset inventory over time (PCI DSS Requirement 2.4)

- Percentage of all software (including firmware) identified in the inventory that is regularly evaluated for vulnerabilities and associated risk using a consistent risk ranking (e.g., CVSS) based on vendor and industry notification (PCI DSS

- Percentage of system, application, and other changes that are scanned (or fail to be scanned) for vulnerabilities and patched prior to release into production (PCI DSS Requirements A3.2.2.1, 6.4)

- Percentage of known vulnerabilities for which patches have been applied or otherwise mitigated (PCI DSS Requirement 6.2) Information Supplement

- Percentage of security incidents that were caused by unpatched systems

- Percentage of “high” vulnerabilities that have been remediated within one month of detection (PCI DSS Requirement 6.2) 3.3.1.3 Impact Measures These measures are used …
Added p. 13
• Assigned overall responsibility for these activities,

• Qualified to perform such functions⎯e.g., have knowledge and experience managing compliance programs,

• Knowledgeable in the organization’s business structure and payment processes,

• Given adequate funding and resources (e.g., tools, education, budget, etc.), and

• Granted the proper authority to effectively organize and allocate such resources.

Note: Compliance Managers might also benefit from industry certifications⎯for example, those managed by the associations such as ISACA, the International Information Systems Security Certification Consortium ((ISC)²), and the Payment Card Industry Security Standards Council (PCI SSC).

Smaller organizations may need to look at choosing someone who is familiar with the cardholder data environment and credit card processes and may want to work with the acquiring bank (i.e., acquirer) or engage a Qualified Security Assessor for additional guidance.

The Compliance Manager should be responsible for securing management support (see 4, “Commitment to Maintaining Compliance”), coordinating the implementation and monitoring of the security controls (see …
Added p. 14
Finally, an organization should provide reasonable assurance that the goals and objectives of its compliance program are consistently achieved despite changes in program ownership (i.e., employee turnover, change of management, organization merger, re-organization, etc.). Best practices include proper knowledge transfer, documentation of existing controls and the associated responsible individual(s) or team(s), PCI DSS compliance history, etc.

PCI DSS provides a minimum set of security requirements for protecting payment card account data. PCI DSS controls alone may not be sufficient to adequately mitigate all the risks associated with other types of sensitive data organizations may possess, and should therefore not be used as a comprehensive checklist for addressing all security needs. It is likely that additional controls may be needed depending on the size, complexity, and business model of an organization.

Compliance with industry standards or regulations does not inherently equate to better security.

Organizations that focus solely on compliance often do so to …
Added p. 15
Entities should perform a risk assessment as a pragmatic process when the potential for risk arises such as in the case of a data breach, a new technology implementation under consideration, or any significant change. The risk assessment process should be aligned with organizational vulnerability-management and change-management policies and procedures.
Added p. 15
PCI DSS, is to build risk analysis into daily activities (e.g., business engagements, change management, user management, etc.) that inform management when events exceed pre-defined risk tolerances. Similarly, risk-assessment discussions should be included as part of business planning, execution, and evaluation meetings.
Added p. 17
• Be well aligned with the organization's business and security

• Cover all in-scope facilities and locations, including retail outlets, data centers, and back-office locations,

• Ensure PCI DSS requirements are in place and operating effectively,

• Consider any changes within the organization, operating environment, and implemented technologies, and

• Produce sufficient evidence to illustrate continued adherence to security requirements.
Added p. 17
• Review and confirm that all instances of cardholder data in the environment are documented and that no cardholder data exists outside of the currently defined CDE, using data-discovery techniques with manual validation.

• Review dataflow and network diagrams, system inventory, and implemented network- segmentation controls to confirm that the PCI DSS scope is accurately represented.

All types of systems and locations, including backup/recovery sites and systems, should be considered as part of the scoping process.

It is important for organizations to retain evidence (see 3.6.7, “Maintaining Evidence ,”) to demonstrate that the periodic PCI DSS scope review was conducted, as this may be required during the annual PCI DSS assessment.

For more information, refer to the Information Supplement: Guidance for PCI DSS Scoping and Network Segmentation, which is intended to provide a further understanding of scoping and segmentation principles as applicable to the PCI DSS environment.11 3.6.2 Review of Compensating Controls

PCI DSS requires …
Added p. 18
December 2016), https://www.pcisecuritystandards.org/documents/Guidance-PCI-DSS-Scoping-and- Segmentation_v1.pdf.
Added p. 19
For example, the output of automated vulnerability-management tools to satisfy internal vulnerability-scanning requirements (PCI DSS Requirement 11.2.1) can validate whether an automated patch-management solution is deploying critical security patches within the required 30-day window (PCI DSS Requirement 6.2) or when patching is performed at more frequent intervals (for example, weekly or daily). Another example is the use of file-integrity monitoring tools (PCI DSS Requirement 11.5) to confirm the effectiveness of change control procedures in

PCI DSS 6.4.5. Specifically, unauthorized changes to critical systems or applications alerted by file integrity monitoring can be an indicator that change-control procedures are not functioning as intended.

In software development, management tools such as Jenkins, GitLab, or others may include automation of various controls. For instance, if automated code review (PCI DSS Requirement 6.3.2) is built into the development process, reports from the management tools could be used to confirm the effectiveness and consistency of this control.

A …
Added p. 20
With PCI DSS, minimum monitoring frequencies are defined within specific requirements such as daily security log reviews in PCI DSS Requirement 10.6.1, quarterly vulnerability scans in PCI DSS Requirement 11.2, and quarterly reviews of operational procedures in PCI DSS

Requirement 12.11. However, the frequencies defined within PCI DSS may not be sufficient to address all risks in certain types of environments. While these frequencies provide a good baseline, organizations should evaluate their environments and implement more rigorous controls as appropriate (refer to Appendix D: PCI DSS Compliance Program Activities,” for further information).

The following factors should be considered from an organizational perspective to determine the appropriate assessment frequency for each metric or control:

• Security Control Stability

• Security control stability is a measure of how frequently a control is likely to change over time. Controls such as requirements for configuration standards (PCI DSS Requirement 2.2) and a system component inventory (PCI DSS

Requirement 2.4) …
Added p. 21
Unfortunately, employing sampling is not without risk due to the possibility that security controls may have failed on specific systems or that systems not following approved configuration standards may have been deployed and thus may go undetected.

The risks associated with sampling can be avoided when continuous control monitoring or data analysis of the entire population is available using a variety of properly configured tools. For example, when code reviews are documented in automated source-code management tools, the entire population can be evaluated for segregation of duties between the coder and the reviewer and whether code reviews and approvals are completed prior to implementation. In these cases, Information Supplement
Added p. 22
If sampling is going to be used, it is critical to gain an understanding of the population characteristics before deciding sample-selection methodology and sample size. If the population size is under 10 instances (e.g., systems, people, physical locations, etc.), it probably makes sense to examine the entire population instead of sampling since the likelihood of a valid sample is quite low. When, however, a population size exceeds 100 instances, it may be reasonable to consider a sampling methodology. With that in mind, the population size alone should not be the sole input to the sampling methodology.

Considerations for determining sample size should include the level of confidence that is necessary to ensure that any risk has been addressed by the control and the organization’s risk tolerance for sampling errors. The lower the tolerance for errors, the higher the confidence level necessary. Internal audit department or sample size calculators12 13 14 can …
Added p. 23
• If multiple standards or processes exist for a single control for different types of business facilities or system components, the sample should represent all business facilities and system components secured with each type of process. If there are no standardized processes or controls in place, each facility should be assessed individually.

While sampling may be a useful tool to help an entity review and monitor their security controls, it is not permitted for an entity to apply PCI DSS requirements to only a sample of the systems or business facilities in scope for PCI DSS.
Added p. 23
“Being compliant” is not equivalent to being able to demonstrate compliance. The process of demonstrating compliance includes the collection, storage, and protection of evidence for all controls and activities performed to meet PCI DSS requirements. For example, an organization may have an automated vulnerability scanning solution configured to perform monthly scans, but without retention of the necessary vulnerability scan reports, the organization might not be able to demonstrate that quarterly scans have been performed as required in PCI DSS Requirement 11.2.

The timing of evidence collection can also impact the efficiency of the process⎯collecting evidence immediately after the activity has occurred rather than weeks or months afterward, can provide an opportunity to review the collected evidence to ensure it is adequate to demonstrate compliance for all of the system components in scope.

The collected evidence should be directly related to the security control(s) implemented to meet a specific PCI DSS requirement, and …
Added p. 27
The evidence-retention process should include safeguards to prevent and detect the altering, tampering, or destruction of evidence. The process should also identify whether any alterations are permitted to collected evidence, including any associated metadata, while in storage. If changes are permitted, the process should identity who is permitted to make such changes and outline a method to record who, what, how, why, and when changes are made. . While an Information Security Management Solution (ISMS) can be used for this purpose, the process can also be implemented using checklists, file and folder structures, and a combination of digital signatures and hashing (see Appendix D: PCI DSS Compliance Program Activities,” for an example of a template to document the retained evidence).
Added p. 27
Detection can result from automated and/or manual controls⎯e.g., an alert from anti-malware solution or vulnerability scanning tool, or as part of a change-management process requiring analysis of all significant changes (PCI DSS Requirement 6.4.6). Formal processes can also assist in the detection and alerting of security control failures. The longer it takes to detect and respond to a failure, the higher the risk and potential cost of remediation.
Added p. 28
Additionally, automated controls need to be properly configured to avoid inaccurate results. For example, if a Data Leakage Prevention (DLP) solution consistently provides false positives, personnel tasked with reviewing the alerts may begin to ignore the notifications⎯possibly containing actual security incident alerts. This type of activity represents a weak or absent control.

Additional DLP configurations (i.e., algorithms or logic that determines events to alert against) or fine-tuning of existing settings may be needed to reduce false-positive alerts requiring review.
Added p. 29
This is where information security awareness training plays a critical role. PCI DSS Requirement 12.6 provides specifics around the need of implementing a security awareness program, defining communication methods, providing such training upon hire and at last annually, and implementing effective communication channels for security awareness.

The foundation of any mature security awareness program starts by developing adequate policies and procedures that define the different levels and content of awareness training to be provided to the different employees involved in the handling of cardholder data, including those who can incidentally come in contact with such data. It is also important to implement a formal security awareness process with defined roles and responsibilities to maintain periodic campaigns that will be updated based on the trends and vectors identified in published data breaches. Constantly updating the security awareness programs allow entities to not only keep their workforce up to speed with the latest …
Added p. 29
Moreover, as reported in several major breach studies17 18 19, breaches of TPSPs are a common target as an entry point to an entity’s valuable data.
Added p. 30
PCI SSC information resources include publication of new and updated standards, FAQs, guidance documents, blog posts, and other information that clarifies or introduces additional requirements.

Communication efforts should include but not be limited to internal e-mail notifications, scheduled conference calls and meetings with personnel involved in maintaining PCI DSS compliance, internal publications such as bulletins and blog posts, updates to supporting and program documentation, executive management reports, etc. Such communications should include a full description of the changes or threats, identification of the impacted business processes and facilities, and any resultant impact to the organization’s PCI DSS compliance efforts. All impacted training and awareness materials should also be updated accordingly.
Added p. 30
• Acquisition of an entity that is not PCI DSS compliant or that is subject to different compliance obligations.

• Detected shifts in corporate culture

•either positive or negative

•toward compliance or security.

• The addition of new payment channels or lines of business.

• New or updated third-party outsourcing agreements (e.g., the addition a new service provider or amendment to an existing agreement).

• For service provider companies, new or updated Customer Service Level Agreements (e.g., the addition of a new service or amendment to existing service offering).

After analyzing the impact organizational changes have to the risk environment and PCI DSS scope, security controls may need to be added, modified, or replaced to mitigate any additional risks or security gaps that have surfaced as a result. Policies and procedures may need to be updated; new security systems installed; key security responsibilities modified or shifted to new people; third-party agreements augmented, renewed, or terminated; and new …
Added p. 32
The new system would also need to be included in quarterly vulnerability scanning schedules and integrated into other security and monitoring processes such as centralized logging, file-integrity monitoring, antivirus, etc.
Added p. 32
As an example, organizations relying on the use of unsupported operating systems (OS) to run systems and applications within the CDE will need to consider how to ensure those systems remain secure once the OS vendor has stopped issuing security patches. One option may be to purchase extended support from the vendor or one of its partners. Other options may include upgrading operating systems and/or replacing applications dependent on outdated operating systems with updated versions.

PCI DSS Requirement 12.4.1 for service providers became effective on February 1, 2018. This requirement relates directly to executive management accountability to ensure responsibility for maintaining a PCI DSS Compliance Program is assigned. Additionally, a charter for the PCI DSS compliance program is required, to include a communication structure that ensures executive management is accountable for and aware of any compliance-impacting risks on an ongoing basis.

Although PCI DSS Requirement 12.4.1 is intended only for service providers, …
Added p. 34
• Control Objectives for Information Technology (COBIT) is a framework for information technology management and governance from the ISACA. COBIT is structured to allow managers to bridge the gap between control requirements, technical issues, and business risks. COBIT enables clear policy development and good practice for IT control throughout organizations. COBIT emphasizes regulatory compliance, helps organizations to increase the value attained from IT, and enables alignment and simplifies implementation of the COBIT framework.

• Committee of Sponsoring Organizations of the Treadway Commission (COSO) performs research and provides guidance on the topics of enterprise risk management (ERM), internal controls, and fraud deterrence. The COSO Internal Control

• Integrated Framework components of internal control⎯Control Environment, Risk Assessment, Control Activities, Information and Communication, and Monitoring Activities⎯are supported by 17 internal control principles that can assist organizations in developing and improving internal governance structures with risk-assessment processes fundamental to maintaining PCI Compliance.

• General Data Protection Regulation …
Added p. 36
Role Role Definition Access Control Administrators Personnel with responsibility for administering access control to systems, including all end-user access to systems, and administrator or privileged- user access to systems and network devices.

Compliance/Risk Management Groups Personnel responsible for risk oversight and risk assessment across the business.

Internal Audit Personnel responsible for the assessment of security controls applied across the business.

Role Role Definition Premises Access and Security Administrators Personnel with responsibility for administering security-access control to facilities, building security, alarms and alarm monitoring, CCTV monitoring, and storage. They also register holders of keys for access to sensitive areas, sensitive storage areas, and the premises.

Appendix C: Applicability of PCI DSS Requirements to Assets Type The Table 2: Applicability of PCI DSS Requirements to Assets Type below is an example of how an organization may identify assets within their environment and the related applicable controls that should be taken into consideration while maintaining PCI-DSS compliance. …
Removed p. 3
• August 2014 1 Introduction Since the inception of the Payment Card Industry Data Security Standard (PCI DSS), compliance with PCI DSS has steadily increased among organizations that store, process, and transmit cardholder data. The increase in PCI DSS compliance rates can likely be attributed to increased awareness of the standard, evolutions in card brand compliance programs and mandates, and an overall increase in the maturity of PCI DSS. However, despite these improvements, statistics show that most of these organizations still have yet to master ongoing PCI DSS compliance with only one-in-ten organizations maintaining full compliance with PCI DSS at the time of their initial re-assessment following successful validation the year prior.1 These statistics are more concerning when you look at the fact that research conducted by Verizon from 2011 through 20132 found that organizations that suffered a data breach were less likely to be compliant with PCI DSS than …
Modified p. 3 → 4
The information in this document is intended as supplemental guidance and does not supersede, replace, or extend PCI DSS requirements. While all references made in this document are to PCI DSS version 3.0, the general principles and practices offered here may be applied to any version of PCI DSS.
The information in this document is intended as supplemental guidance and does not supersede, replace, or extend requirements in any PCI SSC standards, nor does it endorse the use of any specific technologies, products, or services. While all references made in this document are to PCI DSS version 3.2.1, the general principles and practices offered here may be applied beyond the context of PCI DSS.
Removed p. 4
• August 2014 2 Compliance Validation and Security In order to be effective at maintaining PCI DSS compliance on an ongoing basis, organizations must first understand how annual assessments relate to ongoing compliance efforts and security in general. Annual PCI DSS assessments only validate an organization’s state of compliance with PCI DSS at the time the assessment is conducted. They are not necessarily good indicators of how well an organization maintains its

PCI DSS control activities and security practices between assessments. In addition, the scope of annual assessments can differ from organization to organization. Many merchants can validate PCI DSS compliance to varying degrees. For example, most large merchants and service providers are required by the payment brands to have qualified security assessors (QSAs) conduct formal assessments against the full scope of PCI DSS requirements. Smaller merchants, however, are often permitted to validate against a reduced set of PCI DSS requirements …
Modified p. 4 → 7
Organizations that focus solely on annual PCI DSS assessments to validate the quality of their cardholder data security programs are missing the intent of PCI DSS, and likely see their PCI DSS compliance state “fall off” between assessments (see Figure 1). These organizations must realize that security is not a project, it is a continuous state. In order to maintain a consistent level of security, organizations must have a well- designed program of security controls and monitoring practices in place …
Organizations that focus solely on annual PCI DSS assessments to validate the quality of their cardholder data security programs are missing the intent of PCI DSS to enhance cardholder data security, and likely see their PCI DSS compliance state “fall off” between assessments (see Figure 1).
Removed p. 5
• August 2014 3 Challenges to Maintaining Compliance Many organizations see the effectiveness of their PCI DSS security controls•and their overall state of compliance•decline after the assessment is completed.3 Reasons for the decline vary. For many organizations, the pressure to adapt to ever-increasing customer demands and emerging technologies and the resulting changes to an organization’s business goals, structure, and technology infrastructure can introduce new compliance gaps. In other cases, complacency is cause for compliance fall-off. Some organizations assume what was good enough last year will be good enough for subsequent years. Others are simply overconfident in their own practices and don’t devote the resources necessary to regularly monitor their compliance program’s effectiveness.

Failing to integrate PCI DSS security processes into daily business and operational procedures, monitor security controls on a continuous basis, and maintain compliance at all times could leave organizations more susceptible to security control failures, malicious attack, or accidental …
Removed p. 6
Note: Appropriate qualifications for a compliance manager might include certifications from the Information Systems Audit and Control Association (ISACA), the International Information Systems Security Certification Consortium ((ISC)²), the Payment Card Industry Security Standards Council (PCI SSC), or other industry- accepted certification programs.

The compliance manager would be responsible for engaging management support, coordinating monitoring and assessment activities, and engaging key personnel or functional groups5 as part of the efforts to ensure all security functions•such as patching systems (PCI DSS 6.2), security-log reviews (PCI DSS 10.6.1), wireless network scans (PCI DSS 11.1), internal/external vulnerability scans (PCI DSS 11.2) and internal/external penetration tests (PCI DSS 11.3)•are performed as required.
Removed p. 7
• August 2014 manager would be responsible for making certain the evidence is prepared, indexed, and stored in a central repository for use during assessments or internal reviews.

PCI DSS comprises a minimum set of security requirements for protecting cardholder data that apply to any organization that stores, processes, or transmits cardholder data. However, not all organizations are the same. Consequently, not all environments are the same. In some environments PCI DSS controls alone may not be sufficient to adequately mitigate all the risks associated with other types of sensitive data organizations may possess. PCI DSS provides a solid baseline of security controls, but it is merely a baseline and shouldn’t be used as a comprehensive checklist for addressing all the security needs of an organization.

Additionally, the idea that compliance inherently equates to better security is a common misconception, and one that has led organizations to focus solely on compliance, often …
Modified p. 7 → 21
PCI DSS requirements or related compensating controls. In order to achieve compliance with PCI DSS, an organization must meet all applicable PCI DSS requirements.
PCI DSS, an organization must meet all applicable PCI DSS requirements.
Removed p. 8
• August 2014 reducing both the risk to and scope of their cardholder data environment. Risk assessments are fundamental to a risk-based security strategy. Organizations need to be diligent with regards to performing risk assessments if they wish to be successful in maintaining compliance with PCI DSS.
Modified p. 8 → 15
Incorporating risk analysis into operational-level activities enables risk assessment to become a discipline within a process rather than an additional process that must be bolted on top of existing ones.
Incorporating risk analysis into operational-level activities enables risk assessment to become an integral part of a process rather than an additional overhead. Furthermore, continuous risk analysis enables organizations to respond more quickly to changing threats.
Modified p. 8 → 16
Risk is a much more effective measurement for describing how security efforts contribute to an organization’s bottom line. When risk is used to measure the impact security efforts have on the achievement of the organization’s key business objectives, it becomes much easier for business leaders to understand how security expenditures provide value. Articulating security in terms of risk reduction, particularly over time, is a more useful method for illustrating the effectiveness of an organization’s information security program. Maintaining compliance with …
Risk quantification is a much more effective measurement for describing how security efforts contribute to an organization’s bottom line. When risk is used to measure the impact that security efforts have on the achievement of the organization’s key business objectives, it becomes much easier for business leaders to understand how security expenditures provide value. Articulating security in terms of risk reduction, particularly over time, is a more useful method for illustrating the effectiveness of an organization’s information security program. Maintaining …
Removed p. 9
• August 2014 organization’s IT infrastructure. These successful organizations then integrate specific compliance- mandated controls under the umbrella of the larger security control framework, making adjustments where necessary.
Modified p. 9 → 16
Integrating PCI DSS controls into a larger, common set of security controls is often the easiest path to ongoing PCI DSS compliance. Overarching security frameworks allow security teams to focus on a single target rather than trying to accommodate multiple (and sometimes conflicting) sets of requirements. It also provides for a common set of terms and metrics that can help avoid confusion when articulating security and compliance strategies to key stakeholders. When PCI DSS is integrated into an organization’s overall …
Integrating PCI DSS controls into a larger, common set of security controls facilitates ongoing PCI DSS compliance. A single, comprehensive, security framework allows security teams to focus on a single target rather than trying to accommodate multiple (and sometimes conflicting) sets of requirements. It also provides a common set of terms and metrics that can help avoid confusion when articulating security and compliance strategies to key stakeholders. When PCI DSS is integrated into an organization’s overall risk-based security strategy, it …
Modified p. 9 → 16
Note: Some organizations may choose to develop their own security frameworks internally. However, most simply adopt existing standardized security control frameworks such as those provided by the International Organization for Standardization (ISO), the National Institute of Standards and Technology (NIST), and the Information Systems Audit and Control Association (ISACA). More information on these and other security control frameworks is provided in Annex A.
Note: Some organizations may choose to develop their security frameworks internally. However, most simply adopt existing standardized security control frameworks such as those provided by the International Organization for Standardization (ISO), the National Institute of Standards and Technology (NIST), and ISACA. (See Appendix A, “Sample of Industry-Standard Security Frameworks,” for more information on these and other security control frameworks.) 10 Ponemon Institute, The State of Risk-based Security Management (Ponemon Institute, LLC, 2012 and 2013).
Modified p. 9 → 17
To understand how an organization’s security program performs on a day-to-day basis, organizations must develop strategies to continuously monitor and document the implementation, effectiveness, adequacy, and status of all of their security controls.
To understand how an organization’s security program performs on a day-to-day basis, organizations should develop strategies to continuously monitor and document the implementation, effectiveness, efficiency, impact, and status of all of required and defined security controls.
Modified p. 9 → 17
 PCI DSS requirements continue to be in place and operating effectively, and  Personnel continue to follow appropriate security procedures.
• Ensure personnel continue to follow appropriate security procedures,
Removed p. 10
• August 2014 level requirements such as configuration standards (PCI DSS 2.2), anti-virus (PCI DSS 5), patches (PCI DSS 6.2), and audit logging (PCI DSS 10) are also in place and operating effectively.

But what does it mean to conduct “periodic” reviews of all relevant security controls? Many organizations choose to perform these types of reviews on an annual basis. However, while annual comprehensive assessments are necessary and can provide a good indication of how security controls are performing at a specific point, they do not adequately indicate performance over time and are not sufficient to demonstrate security due diligence. Well-designed review processes enable more real-time monitoring of security controls, including more frequent reviews and coverage of smaller components.
Removed p. 10
With PCI DSS, monitoring frequencies are already pre-defined within the specific requirements such as daily security log reviews in PCI DSS 10.6.1 or quarterly system vulnerability information in PCI DSS 11.2. However, the frequencies defined within PCI DSS may not be sufficient to address all the risks in certain environments. While these frequencies defined within PCI DSS provide a good baseline, organizations should evaluate their own environments and implement more rigorous controls as appropriate. In addition, certain factors must be considered to determine the appropriate assessment frequency for each individual metric or control:

 Security Control Volatility

• Security control volatility is a measure of how frequently a control is likely to change over time. Volatile security controls are assessed more frequently, whether the objective is establishing security control effectiveness or supporting calculation of a metric.

Examples of volatile controls are requirements for configuration standards (PCI DSS 2.2) and a system component inventory …
Removed p. 11
 If multiple standards or processes exist for a single control for different types of business facilities or system components, the sample must be large enough to include all business facilities and system components secured with each type of process. If there are no standardized processes or controls in place, each facility should be assessed individually.
Modified p. 11 → 21
Selecting a sample of information systems rather than performing a full inspection of all systems can be a valuable and efficient means of monitoring security control state and effectiveness, particularly in cases where security controls and monitoring mechanisms are not automated. Unfortunately, employing sampling is not without risk.
Selecting a sample of information systems rather than performing a full inspection of all systems can be a valuable and efficient means of monitoring security control state and effectiveness, particularly in cases where security controls and monitoring mechanisms are not automated.
Modified p. 11 → 21
A risk with sampling is that the sample population may fail to capture the variations in assessment results that would otherwise be obtained from assessment of the full population. This could result in an inaccurate view of the effectiveness of the security controls assessed and the overall security status of the organization. To minimize exposure, organizations should first consider the overall scope and complexity of their environment.
Another risk associated with sampling is that the sample population may fail to capture the variations in control-review results that would otherwise be obtained from a review of the full population. This variance could result in an inaccurate view of the effectiveness of the assessed security controls and ultimately the security posture of the organization. To minimize exposure, organizations should consider the overall scope and complexity of the assessed environment in order to determine an appropriate sample.
Modified p. 11 → 22
If sampling makes sense for the organization being assessed, the compliance manager should consider the following guidelines when independently selecting representative samples of business facilities and system components for use during interim evaluations of PCI DSS controls:
If sampling is appropriate for the organization, the Compliance Manager should consider the following guidelines when independently selecting representative samples of business facilities and system components for use during interim evaluations of PCI DSS controls:
Modified p. 11 → 22
Samples should be a representative selection of all types and locations of business facilities.
Samples should be a representative selection of all types and locations of business facilities.
Modified p. 11 → 22
Samples of system components should include every type and combination in use.
Samples of system components should include every type and combination in use.
Modified p. 11 → 22
Samples should also include each type of system deployed at each selected business facility.
Samples should also include each type of system deployed at each selected business facility.
Modified p. 11 → 22
Samples must be sufficiently large to provide assurance that controls are implemented as expected.
Samples must be sufficiently large to provide assurance that controls are implemented as expected.
Modified p. 11 → 22
Standardized or centralized security controls and processes that ensure consistency across all business facilities may permit smaller sample sizes.
Standardized or centralized security controls and processes that ensure consistency across all business facilities may permit smaller sample sizes.
Removed p. 12
• August 2014 4.4.2 Automated Control Monitoring The use of automation in both security management and security control monitoring can provide a tremendous benefit to organizations in terms of simplifying monitoring processes, enhancing continuous monitoring capabilities, minimizing costs, and improving the reliability of security controls and security- related information. Automated control monitoring may consist of simple scripts for monitoring-system status or include large commercial products performing a variety of monitoring functions. The use of automation may help security practitioners recognize patterns and relationships that may otherwise be difficult to detect through human analysis alone, particularly when the analysis is performed on large volumes of data.

PCI DSS 11.5) to monitor the effectiveness of change control procedures in PCI DSS 6.4.5.
Modified p. 12 → 19
Automated tools such as intrusion-detection, vulnerability-management, patch-management, asset- management, and configuration-management systems, many of which may be used as security controls themselves, also include status consoles, alerting mechanisms, and reporting engines that can be used to monitor the status and effectiveness of other security controls over time. For example, the use of automated vulnerability-management tools to satisfy internal vulnerability-scanning requirements (PCI DSS 11.2.1) can help determine whether an automated patch-management solution is deploying critical security patches within the mandated 30-day …
Automated tools such as intrusion-detection, vulnerability-management, patch-management, asset-management, and configuration-management systems⎯many of which may be used as security controls themselves⎯also include status consoles, alerting mechanisms, and reporting engines that can be used to monitor the status and effectiveness of other security controls over time. The output from these tools can be used to generate evidence of compliance, on demand.
Modified p. 12 → 19
The use of automated security tools still requires manual review and oversight to maximize their effectiveness. If individuals managing these tools do not carry out their oversight responsibilities adequately, the value of such tools

•and automation in general

•is minimized..
The use of automated security tools requires appropriate configuration, coverage (i.e., scope), as well as manual review and oversight to maximize their effectiveness. If individuals managing and operating these tools do not carry out their oversight responsibilities adequately, the value of such

•and automation in general

•is minimized. Further, violations in compliance may go undetected.
Removed p. 13
• August 2014 4.5.3 Identifying and Addressing New Issues Failures in security controls can provide attackers opportunities to launch other attacks within the environment. For example, a failure in a system’s anti-virus software could allow an attacker to install malware on that system. If intrusion-detection mechanisms reported increased activity during the window in which the anti-virus software was inoperable, the details of that activity may provide additional insight into the cause and potential impact of the original issue. Prompt detection and response is also critical to preventing loss of cardholder data in these situations.
Removed p. 13
Once the organization is satisfied the control is operating correctly and no other issues with the control exist, standard monitoring frequencies may be resumed.
Removed p. 13
As mentioned in Section 4.3.3, “Using Risk to Balance Business Priorities with Security Needs,” risk reduction is a key metric for illustrating overall security-program effectiveness•but metrics can provide meaningful indicators of security status at other levels within the security program as well.
Modified p. 13 → 10
Metrics may be used by compliance managers to prove the effectiveness of their security initiatives, allocate resources appropriately, and demonstrate the efficiency and ROSI to stakeholders. Metrics can be calculated from a combination of security-status monitoring, security control assessment data, and data collected from one or more security controls or technologies. The collection of metrics, by itself, does not directly result in the ability to maintain PCI DSS compliance. However, when these metrics are analyzed properly, they may provide mechanisms …
Metrics may be used by compliance managers to prove the effectiveness of security initiatives, allocate resources appropriately, and demonstrate the efficiency and return on security investment to stakeholders. Metrics can be calculated from a combination of security-status monitoring, security- control assessment data, and data collected from one or more security controls or technologies.
Removed p. 14
• August 2014 4.6.1.1 Implementation Measures Implementation measures are used to demonstrate progress in implementing information security programs, specific security controls, and associated policies and procedures. Implementation metrics are usually described in percentages and may include such examples as:

 Percentage of information systems with password policies configured in accordance with policy (PCI DSS Requirements 8.1 and 8.2)  Percentage of web servers configured in accordance with system configuration standards (PCI DSS Requirements 2.2, 2.3 and 10.4)  Percentage of organizational personnel that have received security training (PCI DSS Requirements 6.5, 9.9.3, 12.6, and 12.10.4)  Percentage of system-level changes documented and approved by management (PCI DSS
Modified p. 14 → 11
Requirement 6.4.5) Upon initial implementation of a particular control, implementation measures will likely be less than 100%. However, as security controls mature and results begin to approach 100%, the compliance manager may conclude that systems have fully implemented the security controls addressed by this metric, and monitoring efforts can shift to the next type of measures or to other controls.
• Percentage of system-level changes documented and approved by management (PCI DSS Requirement 6.4.5) Upon initial implementation of a particular control, implementation measures will likely be less than 100%. As security controls mature and results begin to approach 100%, the compliance manager may conclude that systems have fully implemented the security controls addressed by this metric. At that point, any change to the measure (i.e., less than 100%) can be used as a trigger to indicate a failure in security
Modified p. 14 → 11
These measures concentrate on the evidence and results of assessments and may require multiple data points quantifying the degree to which information security controls are implemented and the resulting effect(s) on the organization’s security posture. Examples of effectiveness/efficiency measures may include:
These measures concentrate on the evidence and results of assessments and may require multiple data points qualifying or quantifying the degree to which controls are implemented and the effect(s) on the organization’s security posture. Risk mitigation is also a key metric for determining the overall impact of an organization’s information security program to its business objectives. When evaluating the operating effectiveness of the vulnerability-management program, an organization could measure:
Removed p. 15
• August 2014 information security. Risk mitigation is also a key metric for determining the overall impact of an organization’s information security program to its business objectives. However, there are other valuable impact measures that may be useful in gauging security-program impact. Examples include:
Modified p. 15 → 12
 Percentage of an organization’s IT budget devoted to information security  Percentage of an organization’s customers satisfied by the organization’s information security  Return on security investments (ROSI)  Total cost of ownership (TCO) 4.6.2 Metric Reliability While the establishment and collection of metrics is a key function of determining the capabilities and effectiveness of an organization’s security program, metrics are reliable only when the collection mechanisms or controls on which they depend are implemented correctly. Collecting metrics from …
Total cost of ownership (TCO) 3.3.2 Metric Reliability While the establishment and collection of metrics is a key function of determining the capabilities and effectiveness of an organization’s security program, metrics are reliable only when the collection mechanisms or controls on which they depend are implemented correctly. Collecting metrics from poorly implemented security controls is equivalent to using a “broken or uncalibrated scale.”7 The interpretation of metrics data presumes that the controls directly or indirectly used in the metric …
Modified p. 15 → 30
Other types of organizational changes that warrant consideration include internal restructuring, corporate spin-offs, bankruptcies and liquidations, loss of key IT security personnel, and outsourcing arrangements.
Other types of organizational changes that warrant consideration can include internal restructuring, corporate spin-offs, bankruptcies and liquidations, and loss of key IT or security personnel. Organizations should build in processes for detecting and responding to such changes in a timely manner and establish manual or automated triggers to alert key personnel so any associated risks can be analyzed with due diligence. This risk analysis should evaluate the potential impact that changes may have on an organization’s business objectives, PCI DSS …
Removed p. 16
• August 2014 Organizations need to build in processes for detecting and responding to such changes in a timely manner. Organizations should establish manual or automated triggers to alert key personnel to such changes so they can analyze any associated risks. The risk analysis should determine the potential impact the changes may have on the organization’s business objectives, PCI DSS scope, and compliance status.

 The creation of potential non-compliance issues, such as the acquisition of a non-compliant entity  Shifts in corporate culture (positively or negatively) towards compliance or security  The introduction of new payment channels or impacts to existing cardholder data flows  The introduction of new third-party outsourcing agreements  Impacts to existing contracts or agreements with customers or third-party service providers  Changes to PCI DSS validation requirements (e.g., SAQ to Level 1 assessment) After analyzing the impact organizational changes have to the risk environment and …
Modified p. 16 → 30
With each type of organizational change, there will be a unique set of issues that must be considered when analyzing the scope and impact on PCI DSS compliance. However, organizations should consider the following when organizational changes occur:
With each type of organizational change, there will be a unique set of issues to be considered when analyzing the scope and impact on PCI DSS compliance. Some examples of organizational changes that may impact how an entity manages their PCI DSS compliance include:
Removed p. 17
• August 2014 the security of the CDE, such as changes to network-traffic routing rules, firewall rules, DNS configurations, or other security-related functions.
Removed p. 17
For example, organizations that continue to rely on the use of unsupported operating systems (OS) to run key systems and applications within the CDE should consider how they ensure those systems remain secure now that the OS vendor has stopped issuing security patches. One alternative may be to purchase extended support from the vendor or one of its partners. Other alternatives may include implementing plans for upgrading operating systems and/or replacing applications dependent on outdated operating systems with updated versions.
Modified p. 17 → 31
After all the impacted systems and networks have been identified, all applicable PCI DSS requirements for those systems and networks must be evaluated. For example, any new system added to the CDE would need to be configured in accordance with defined system-configuration standards (for example, password-complexity settings, access-control configurations, etc.). The new system would also need to be included in quarterly vulnerability scanning schedules.
After the impacted system components and networks have been identified, all applicable PCI DSS requirements for those systems and networks must be evaluated. For example, any new system added to the CDE would need to be configured in accordance with defined system- configuration standards⎯including password-complexity settings, access-control configurations, Information Supplement
Modified p. 17 → 32
Regardless of the approach, organizations need to carefully evaluate the impact aging IT solutions have on the security of the CDE. Compliance managers should also consider additional and/or compensating controls, and exercise extra rigor in security-review processes to ensure adequate security and oversight until replacement technologies can be implemented. Any resulting remediation strategies should have clearly defined goals and timelines.
Regardless of the approach, organizations need to carefully evaluate the impact that an aging technology solution has on the security of the CDE. Compliance managers should also consider additional and/or compensating controls, and exercise extra rigor in security-review processes to ensure adequate security and oversight until replacement technologies can be implemented. Any resulting remediation strategies should have clearly defined goals and timelines.
Removed p. 18
Executive sponsorship is critical if organizations want to be successful in implementing ongoing PCI DSS compliance programs.

Organizations that focus solely on compliance are like people who go on a crash diet.13 It may work temporarily and make people appear healthier, but it is not sustainable over the long-term and does not reflect an overall commitment to a healthier lifestyle. To improve one’s overall long-term health, healthier activities

•such as exercise and nutrition

•need to be incorporated into one’s daily life. The same concepts hold true for compliance-focused organizations. The Report on Compliance (ROC) may demonstrate that the organization is compliant at a given point in time, but it does not necessarily reflect an overall commitment to security.

 Combining security goals with other key business goals  Articulating security goals using the same terms as other business goals  Assigning responsibility for ensuring the achievement of their security goals and holding those with …
Removed p. 19
 Control Objectives for Information Technology (COBIT) is a framework for information technology management and governance from the Information Systems Audit and Control Association (ISACA).
Modified p. 19 → 34
• August 2014 Appendix A: Sample of Industry-Standard Security Frameworks There are numerous governance frameworks available that can be used to complement PCI DSS controls to enhance the overall effectiveness of an organization’s cardholder data security program. Several examples of these frameworks are outlined below.
Appendix A: Sample of Industry-Standard Security Frameworks There are numerous governance frameworks available that can be used to complement PCI DSS controls to enhance the overall effectiveness of an organization’s cardholder data security program.
Modified p. 19 → 34
International Organization of Standardization (ISO) has published numerous standards and guidance for addressing information security issues. The most relevant documents to information security and risk management are the ISO/IEC 27000-series of standards. ISO/IEC 27001:2013 Information technology
International Organization of Standardization (ISO) has published numerous standards and guidance for addressing information security issues. The most relevant documents to information security and risk management are the ISO/IEC 27000-series of standards. ISO/IEC 27001:2013 Information technology
Modified p. 19 → 34
• Requirements defines the requirements for creating an information security management system (ISMS) that brings information security, for both IT based and non-IT based security assets, under explicit management control. The standard also has an Annex A, which is a list of what is considered best-practice information security controls needed to address information security risks.
Information security management systems Requirements defines the requirements for creating an information security management system (ISMS) that brings information security, for both IT based and non-IT based security assets, under explicit management control. The standard also has an Annex A, which is a list of Information Supplement
Modified p. 19 → 35
Information Technology Infrastructure Library (ITIL) is a globally recognized collection of best practices for information technology service management. Hallmarks of ITIL are an organization-wide approach that involves a development cycle of services from preliminary concept to a full release and continuous improvement. The enterprise-wide approach involved in ITIL can help support ongoing PCI DSS compliance activities across the whole organization. ITIL also stresses the continuous monitoring of key business processes as well as formal change-management processes to minimize business …
Information Technology Infrastructure Library (ITIL) is a globally recognized collection of best practices for information technology service management. Hallmarks of ITIL are an organization-wide approach that involves a development cycle of services from preliminary concept to a full release and continuous improvement. The enterprise-wide approach involved in ITIL can help support ongoing PCI DSS compliance activities across the whole organization.
Modified p. 19 → 35
The National Institute of Standards and Technology (NIST) develops standards, metrics, tests, and validation programs to promote, measure, and validate the security in information systems and services. Guidance on the selection and implementation of information security controls is covered in NIST Special Publication 800-53 (Revision 4), Security and Privacy Controls for Federal Information Systems and Organizations.
The National Institute of Standards and Technology (NIST) develops standards, metrics, tests, and validation programs to promote, measure, and validate the security in information systems and services. Guidance on the selection and implementation of information security controls is covered in NIST Special Publication 800-53 (Revision 5), Security and Privacy Controls for Federal Information Systems and Organizations. In addition, the NIST Cybersecurity Framework provides a prioritized, flexible, and cost-effective framework for reducing cyber risks.
Modified p. 19 → 36
Information security management systems
Information Supplement
Removed p. 20
Access Control Administrators Personnel with responsibility for administering access control to systems, including all end-user access to systems, and administrator and privileged-user access to systems and network devices.
Modified p. 20 → 36
• August 2014 Appendix B: Common Assessment Roles & Responsibilities
Appendix B: Common Assessment Roles & Responsibilities
Modified p. 20 → 36
Note: These assignments are for illustration purposes only and may not be all-inclusive. Not all organizations will have these roles defined. The intent of this appendix is to aid organizations in understanding functional roles typically defined within organizations and what assessment responsibilities those roles may have during
Note: These assignments are for illustration purposes only and may not be all-inclusive. Not all organizations will have these roles defined. The intent of this appendix is to aid organizations in understanding functional roles typically defined within organizations and what assessment responsibilities those roles may have during PCI DSS assessments.
Modified p. 20 → 36
Role Role Definition Data Owners Personnel with designated data-ownership responsibilities.
Data Owners Personnel with designated data-ownership responsibilities.
Modified p. 20 → 37
Systems Administrators Personnel with system build, installation, and maintenance responsibilities. These users are responsible for the management of servers, applications, PCs, and other end user devices. They may also retain responsibility for log monitoring of administered systems.
Systems Administrators Personnel with system build, installation, and maintenance responsibilities. These users are responsible for the management of servers, applications, PCs, and other end-user devices. They may also retain responsibility for log monitoring of administered systems.
Removed p. 21
• August 2014 Role Role Definition Legal Personnel responsible for third-party supplier (service provider) contracting.

Internal Audit Personnel responsible for the oversight of all security controls applied across the business.

Compliance/Risk Management Groups Personnel responsible for risk management and risk assessment across the business.
Modified p. 21 → 37
Procurement/Vendor management Personnel responsible for third-party supplier (service provider) engagement and on- going relationship management, including pre-engagement due diligence processes.
Procurement/Vendor management Personnel responsible for third-party supplier (service provider) engagement and on-going relationship management, including pre- engagement due diligence processes.
Removed p. 22
• August 2014 Acknowledgements
Removed p. 22
Accudata Systems, Inc.

Acertigo AG American Family Insurance Assurant Inc. atsec (Beijing) Information Technology Co., Ltd Australia Post Bank of America Bank of New Zealand Basefarm AS BCD Travel Benchmark Management British Airways CAG, LLC Canadian Tire Financial Services Capita plc Capital One CenturyTel/CenturyLink Chase Paymentech Coalfire Coles Group Limited College Board Comsec Consulting Confide Ltd CONTROLCASE Convergys Corporation Crowe Horwath CVS Caremark Deli Management Inc (Jason's Deli) DST Output EFM Consulting Inc. Elavon EVO Payments International Experis Finance Fiscal Systems, Inc. Fishnet Security Florida's Turnpike Enterprise Games Workshop Great Southern Bank GuidePoint Security Hitachi-Omron Terminal Solusions, Corp.

HP Information Security HyTrust Inline technologies Integralis Ltd Internet Security Auditors IPS Networks iScan Online K3DES LLC Kilrush Consultancy Ltd Knowit Secure AB Levi Strauss & Co.
Modified p. 22 → 49
PCI SSC would like to acknowledge the contribution of the Best Practices in Maintaining PCI DSS Compliance Special Interest Group (SIG) in the preparation of this document. The Best Practices in Maintaining PCI DSS Compliance SIG consists of representatives from the following organizations:
PCI SSC would like to acknowledge the contribution of the Maintaining PCI DSS Compliance Special Interest Group (SIG) in the preparation of this document, which is a revision of the document prepared by the 2014 Best Practices in Maintaining PCI DSS Compliance SIG. The 2018 Maintaining
Removed p. 23
• August 2014 Megaplan-IT Merchant Link, LLC Merchant Preservation Services LLC. NBCUniversal NDB Advisory Nettitude Ltd NewNet Communication Technologies Nixu Ltd Overwaitea Food Group Pen Test Partners Phillips Consulting Limited PowerPay, LLC PrimeSys Privity Systems Inc Progressive Casualty Insurance SecureConnect Inc.

SecurityMetrics See's Candies, Inc.

Sense of Security Pty Ltd Shearwater Solutions SIX Payment Services Solutionary SRC Security Research & Consulting GmbH SRM Ltd.

SSH Communications Security State Farm Insurance Stratica International Pty Ltd Sunera LLC Symantec Corporation Sysnet Global Solution Terra Verde LLC Time Warner Cable Trustwave Truvantis TUI Travel U.S. Cellular UBS Card Center AG UNC Chapel Hill United States Postal Service Universal Orlando VCAG Vectra Corporation VendorSafe Technologies Verizon Business Verizon Enterprise Solutions Visa Inc.
Modified p. 24 → 50
• August 2014 Recommended References This document draws from the following additional sources of reference. These sources are recommended as additional guidance on building sustainable security and compliance programs.
Recommended References This document draws from the following additional sources of reference. These sources are recommended as additional guidance on building sustainable security and compliance programs.
Modified p. 24 → 50
Source Reference National Institute of Standards and Technology (NIST) http://csrc.nist.gov/publications/  Performance Measurement Guide for Information Security (Special Publication 800-55)  Information Security Continuous Monitoring for Federal Information Systems and Organizations (Special Publication 800-137)  Guide for Applying Risk Management Framework to Federal Information Systems
Source Reference National Institute of Standards and Technology (NIST) http://csrc.nist.gov/publications/
Modified p. 24 → 50
• A Security Lifecycle Approach (Special Publication 800-37)  Managing Information Security Risk
• A Security Lifecycle Approach (Special Publication 800-37)
Removed p. 26
• August 2014 1 Verizon 2014 Payment Card Industry Compliance Report 2 Verizon Data Breach Investigation Reports, 2011-2013 3 Verizon 2014 Payment Card Industry Compliance Report 4 Verizon Data Breach Investigation Reports (DBIRs), 2011, 2012, and 2013.