PCI DSS Requirement 12: explained

Requirement 12: Support information security with organizational policies and programs

This PCI DSS requirement is divided into 12.1, 12.2, 12.3, 12.4, 12.5, 12.6, 12.7, 12.8, 12.9, 12.10. Let's delve further into these.

PCI DSS Requirement 12.1: A comprehensive information security policy that governs and provides direction for protection of the entity’s information assets is known and current

This PCI DSS requirement is further divided into PCI DSS requirement 12.1.1, 12.1.2, 12.1.3, and 12.1.4. Let's explore these in detail.

PCI DSS Requirement 12.1.1: Information security policy

This requirement mandates the establishment, publication, maintenance, and dissemination of a comprehensive information security policy.

• Information security policy: This is a formal document outlining your organization's commitment to information security and its approach to protecting cardholder data. It defines the overall direction and sets expectations for information security practices within your environment.
• Policy elements: The policy should address:
  • Purpose and scope: Explains the policy's objectives and the data it applies to (including CHD).
  • Management commitment: Demonstrates management's support for information security.
  • Accountability: Defines roles and responsibilities for information security within the organization.
  • Security requirements: Outlines specific controls and procedures for information security.
  • Compliance with regulations: References relevant regulations like the PCI DSS.
• Dissemination: The policy should be distributed to all relevant personnel within your organization, including employees, contractors, and anyone with access to cardholder data. Additionally, relevant vendors and business partners who handle your cardholder data should be informed of the policy.

Business implication

• Reduced risk of data breaches: A well-defined and communicated information security policy sets clear expectations for information handling practices and helps employees understand their role in protecting cardholder data. This reduces the risk of accidental or intentional security breaches.

Best practices to meet this requirement

• Develop a comprehensive policy: Develop a policy document that addresses all the required elements mentioned above.
• Obtain approval from management: Ensure management endorses the information security policy.
• Distribute and communicate: Distribute the policy to all relevant personnel, vendors, and business partners. Consider providing training or awareness sessions to ensure everyone understands the policy's content and their information security responsibilities.
• Maintain and update: Review and update the policy periodically to reflect changes in your environment, regulations, or security practices.

How to comply with this requirement

PCI DSS Requirement 12.1.2: Information security policy review and update

This requirement mandates the regular review and updating of your organization's information security policy.

• Review frequency: The policy must be reviewed at least once every 12 months.
• Purpose of review: The review aims to ensure the policy remains relevant and reflects any changes in your business environment or security landscape.
• Updates: Based on the review, the policy should be updated as needed to address new security threats, business objectives, or risk assessments. This may involve incorporating new security controls or revising existing ones.

Business implication

• Maintaining effective security controls: A regularly reviewed and updated information security policy ensures your security controls remain relevant and effective against evolving threats. This helps minimize the risk of data breaches and protects your cardholder data.

Best practices to meet this requirement

• Schedule periodic reviews: Set a recurring schedule for reviewing your information security policy, at least annually.
• Involve relevant stakeholders: Include personnel from different departments (IT, Security, Risk Management) in the review process to gain a comprehensive perspective.
• Consider changes: During the review, assess recent security incidents, risk assessments, and changes in your business environment. Identify any gaps in the policy or areas that need updating.
• Update and re-disseminate: Based on the review, revise the information security policy to reflect any necessary changes. Communicate the updated policy to all relevant personnel, vendors, and business partners.

How to comply with this requirement

PCI DSS Requirement 12.1.3: Information security roles and responsibilities

This requirement mandates that your information security policy clearly defines information security roles and responsibilities for all personnel. Additionally, all personnel must be aware of and acknowledge their responsibilities for protecting cardholder data.

• Information security roles: The policy should define clear roles and responsibilities for information security within your organization. This may include roles like:
  • Information security officer (ISO): Oversees the overall information security program.
  • System administrators: Responsible for securing systems and data.
  • Application developers: Develop secure applications that handle cardholder data.
  • End users: Follow security policies and procedures for handling cardholder data.
• Responsibilities: The policy should outline the specific responsibilities associated with each information security role. These responsibilities should be clear, concise, and easy to understand.
• Awareness and acknowledgement: All personnel, regardless of role, should be aware of the information security policy and understand their individual responsibilities for protecting cardholder data. This may involve providing security awareness training or requiring personnel to acknowledge their understanding of the policy through electronic signatures or written confirmation.

Business implication

• Reduced risk of human error: Clearly defined information security roles and responsibilities help ensure everyone understands their part in protecting cardholder data. This minimizes the risk of human errors that could lead to security incidents and data breaches.

Best practices to meet this requirement

• Define roles and responsibilities: In your information security policy, clearly define information security roles and outline the associated responsibilities for each role.
• Develop training programs: Develop and deliver security awareness training programs to educate personnel about information security best practices and their specific responsibilities.
• Implement acknowledgement process: Establish a process for personnel to acknowledge their understanding of the information security policy and their information security responsibilities. This can be achieved through electronic signatures or written confirmations.

How to comply with this requirement

PCI DSS Requirement 12.1.4: Information security management responsibility

This requirement mandates the formal assignment of information security responsibility to a designated member of executive management.

• Information security responsibility: The responsibility for managing and overseeing the organization's information security program is formally assigned to a specific individual within the executive management team.
• Qualified individual: This individual should have a strong understanding of information security principles and possess the authority to make necessary decisions and allocate resources for the security program. Common titles for this role include:
  • Chief information security officer (CISO)
  • Chief security officer (CSO) - Important note: In this case, the CSO's role must specifically include information security.
• Executive Management Level: The designated individual should hold a position within the executive management team, typically reporting to the CEO or the Board of Directors. This ensures information security receives appropriate attention and resources at the highest levels of the organization.

Business implication

• Stronger Information Security Program: Having a designated individual at the executive level championing information security fosters a culture of security within the organization. This leads to a more robust information security program and better protection of cardholder data.

Best practices to meet this requirement

• Assign responsibility: Formally assign information security responsibility to a qualified individual within your executive management team. This can be done through a documented policy or appointment letter.
• Consider qualifications: Ensure the designated individual possesses the necessary knowledge and experience in information security to effectively manage the program.
• Provide authority and resources: Grant the designated individual the authority to make decisions and allocate resources necessary for implementing and maintaining the information security program.

How to comply with this requirement

PCI DSS Requirement 12.2: Acceptable use policies for end-user technologies are defined and implemented

PCI DSS Requirement 12.2.1: Acceptable use policy for end-user technologies

This requirement mandates the establishment and implementation of documented acceptable use policies for all end-user technologies within your organization. These policies define the expected behavior and authorized uses of company-provided technologies by your employees.

• End-user technologies: These are any devices or software used by your employees to access or process information, including:
  • Laptops, tablets, smartphones
  • Removable media (USB drives, CDs)
  • Remote access tools
  • Wireless technologies
  • Email and internet access
• Acceptable use policy: This is a formal document outlining the acceptable and unacceptable uses of your organization's technology resources. It should address the following aspects:
  • Explicit approval: Certain technologies may require explicit approval from authorized personnel before use (e.g., personal devices for work purposes).
  • Acceptable uses: The policy should clearly define the authorized uses of company technology for work purposes.
  • Approved products: The policy may specify a list of approved hardware and software products that employees can use for work.
• Benefits: Implementing an acceptable use policy helps:
  • Manage and control the use of company technology resources.
  • Reduce the risk of unauthorized access, data breaches, and malware infections.
  • Define user responsibilities for protecting cardholder data.
  • Provide legal recourse in case of policy violations.

Business implication

• Reduced risk of security incidents: A well-defined and enforced acceptable use policy reduces the risk of security incidents caused by employee misuse of technology. This helps protect your organization's data and reputation.

Best practices to meet this requirement

• Develop clear and concise policy: Create a clear and concise policy that outlines acceptable and unacceptable uses of technology resources.
• Define specifics: Clearly define the types of technologies covered, approval processes, acceptable uses, and prohibited activities.
• Incorporate risk tolerance: Consider your organization's risk tolerance when defining acceptable uses. For instance, you may restrict personal device usage for work purposes if the risk is high.
• Communicate and train employees: Distribute the acceptable use policy to all employees and conduct training sessions to ensure everyone understands their responsibilities.
• Enforce policies: Establish mechanisms to enforce the acceptable use policy and address any violations.

How to comply with this requirement

PCI DSS Requirement 12.3: Risks to the cardholder data environment are formally identified, evaluated, and managed

PCI DSS Requirement 12.3.1: Targeted risk analysis for flexible frequency PCI DSS requirements

This requirement (becoming mandatory after March 31, 2025) mandates performing targeted risk analyses for PCI DSS requirements that allow flexibility in how often they are performed. These analyses justify the chosen frequency for each requirement based on your specific risk environment.

• Flexible frequency requirements: Certain PCI DSS requirements allow organizations to define the frequency of activities based on their risk assessment.
• Targeted risk analysis: For each flexible frequency requirement, you need to perform a targeted risk analysis to determine the appropriate frequency for your organization. This analysis should be documented and include the following elements:
  • Protected assets: Identify the specific assets (systems, data) the requirement protects (e.g., log files, cardholder data).
  • Threats: Identify the threats the requirement safeguards against (e.g., unauthorized access, malware).
  • Likelihood and impact factors: Consider factors that influence the likelihood and impact of threats occurring (e.g., network security, staff turnover, data sensitivity).
  • Frequency determination: Based on the analysis, determine the appropriate frequency for performing the PCI DSS requirement to minimize the risk. This includes justifying your chosen frequency.
• Annual review: Review each targeted risk analysis at least annually to ensure the results remain valid. Update the analysis if necessary based on changes in your environment.

Business implication

• Optimized security measures: Performing targeted risk analyses helps tailor your PCI DSS controls to your specific risk profile. This allows you to focus resources on areas with higher risk and avoid unnecessary activities for lower-risk areas.

Best practices to meet this requirement

• Develop a risk analysis process: Establish a formal process for conducting targeted risk analyses for flexible frequency PCI DSS requirements.
• Identify relevant requirements: List all PCI DSS requirements that allow flexibility in frequency.
• Analyze each requirement: For each flexible frequency requirement, conduct a targeted risk analysis considering the factors mentioned above.
• Document and justify: Document your risk analysis findings and justify the chosen frequency for each requirement.
• Schedule annual reviews: Set a recurring schedule to review your targeted risk analyses at least annually.

How to comply with this requirement

PCI DSS Requirement 12.3.2: Targeted Risk Analysis for Customized PCI DSS Requirements (Customized Approach Only)

This requirement applies only to organizations using the PCI DSS Customized Approach. It mandates performing targeted risk analyses for each PCI DSS requirement they choose to meet using a customized approach.

• Customized approach: The PCI DSS allows organizations to define alternative controls for certain requirements if they can demonstrate these controls achieve the same or better security outcomes. This is called the "Customized Approach."
• Targeted risk analysis: For each requirement addressed with a customized approach, you need to conduct a targeted risk analysis. This analysis should be documented and include the following elements (as specified in Appendix D):
  • Controls matrix: A table outlining the customized controls you are implementing to meet the requirement's objective.
  • Risk analysis: An assessment of the risks associated with your customized approach and how the controls mitigate those risks.
• Senior management approval: The documented evidence for your customized approach, including the controls matrix and risk analysis, needs to be approved by your organization's senior management.
• Annual review: Perform the targeted risk analysis for each customized requirement at least once every 12 months.

Business implication

• Demonstrated decurity effectiveness: Performing targeted risk analyses for customized controls helps ensure your alternative approach achieves the intended security objectives and maintains a strong security posture.

Best practices to meet this requirement

• Develop a risk analysis process: Establish a process for conducting targeted risk analyses specifically for customized PCI DSS requirements.
• Document controls and risks: Clearly document the customized controls you are implementing and the risks they address in a controls matrix and risk analysis document.
• Obtain senior management approval: Secure approval for your documented customized approach evidence from senior management.
• Schedule annual reviews: Set a recurring schedule to review your targeted risk analyses for customized controls at least annually.

How to comply with this requirement

PCI DSS Requirement 12.3.3: Review of cryptographic cipher suites and protocols

This requirement (becoming mandatory after March 31, 2025) mandates the documentation and annual review of all cryptographic cipher suites and protocols used within your organization. This helps ensure the continued effectiveness of your encryption methods in protecting cardholder data.

• Cryptographic cipher suites and protocols: These are algorithms and methods used to encrypt and decrypt data.
• Documentation requirement: You need to maintain documented information about your cryptographic tools, including:
  • Inventory: A current list of all cryptographic cipher suites and protocols in use, specifying their purpose and where they are used (e.g., data at rest, data in transit).
  • Monitoring: Implement processes to actively monitor industry trends and security advisories regarding the vulnerabilities of your cryptographic tools.
  • Vulnerability response strategy: Develop a documented plan for responding to identified vulnerabilities in cryptographic protocols or algorithms that could impact cardholder data security.

Business implication

• Reduced risk of data breaches: Regularly reviewing and updating your cryptographic tools helps ensure they remain effective against evolving threats. This minimizes the risk of data breaches due to weak or outdated encryption methods.

Best practices to meet this requirement

• Develop an inventory: Create and maintain a comprehensive inventory of all cryptographic cipher suites and protocols used in your environment.
• Monitor industry trends: Stay informed about industry developments and security advisories related to cryptographic vulnerabilities. Resources like NIST publications can be helpful.
• Develop a response strategy: Establish a plan outlining how you will address potential vulnerabilities in your cryptographic tools. This may involve patching systems, upgrading algorithms, or migrating to more secure alternatives.
• Schedule annual reviews: Set a recurring schedule to review your cryptographic documentation and response strategy at least once annually.

How to comply with this requirement

PCI DSS Requirement 12.3.4: Review of hardware and software technologies

This requirement (becoming mandatory after March 31, 2025) mandates the annual review of all hardware and software technologies used in your environment. This helps ensure your systems remain up-to-date, secure, and supported by the vendors.

• Hardware and software technologies: This encompasses all computer systems, operating systems, and applications used within your organization.
• Annual review: You need to conduct a review of your hardware and software technologies at least once every 12 months. This review should address the following aspects:
  • Vendor support: Analyze if the vendors supplying your technologies continue to provide timely security patches and updates. Outdated software with no ongoing support is vulnerable to known exploits.
  • PCI DSS compliance: Assess if the technologies you use still support your PCI DSS compliance efforts. New software versions or updates may introduce functionalities that conflict with your security controls.
  • Industry trends: Track industry announcements and trends related to your technologies. This may include information about a vendor reaching "end-of-life" (EOL) for a specific product. EOL products no longer receive security updates and pose a security risk.
  • Remediation plan: Develop and document a plan, approved by senior management, for addressing outdated technologies. This plan should outline the process for remediating unsupported systems, including those reaching EOL with their vendors.

Business implication

• Reduced security risks: Regularly reviewing and updating your hardware and software minimizes the risk of vulnerabilities due to outdated or unsupported technologies. This helps protect your organization from cyberattacks and potential data breaches.

Best practices to meet this requirement

• Develop a review process: Establish a formal process for conducting annual reviews of your hardware and software technologies.
• Analyze vendor support: Verify if your vendors continue to provide security updates and patches for your technologies.
• Assess PCI DSS compliance impact: Evaluate if any new software versions or updates could potentially hinder your PCI DSS compliance efforts.
• Track industry trends: Stay informed about industry announcements and trends related to your technologies, especially regarding EOL products.
• Develop a remediation plan: Create and document a plan with senior management approval for addressing outdated technologies. This plan should outline how you will replace or remediate unsupported systems.
• Schedule annual reviews: Set a recurring schedule to conduct your hardware and software technology reviews at least annually.

How to comply with this requirement

PCI DSS Requirement 12.4: PCI DSS compliance is managed

PCI DSS Requirement 12.4.1: Executive management responsibility for service providers (service providers only)

This requirement applies solely to service providers and emphasizes the importance of executive management involvement in PCI DSS compliance.

• Executive management: This refers to high-level organizational leadership, such as C-suite executives or the board of directors.
• Service provider: An organization that stores, transmits, or processes cardholder data on behalf of merchants.

This requirement mandates that service provider executive management establishes responsibility for two key aspects:

1. Protection of cardholder data: Executives must demonstrate a clear commitment to protecting cardholder data entrusted to their organization.
2. PCI DSS compliance program: Executives need to establish a formal PCI DSS compliance program that outlines the organization's approach to PCI DSS adherence. This program should include:

• Overall accountability: Executives are ultimately responsible for ensuring the organization maintains PCI DSS compliance.
• Compliance program charter: A documented charter defining the purpose, scope, and responsibilities of the PCI DSS compliance program should be created and communicated to executives.

Business implication

• Enhanced security culture: Executive involvement in PCI DSS compliance demonstrates a strong security culture within the organization. This encourages employees to prioritize data security and reinforces the importance of PCI DSS adherence.

Best practices to meet this requirement

• Develop a security policy: Establish a formal information security policy endorsed by executive management. This policy should highlight the importance of PCI DSS compliance.
• Assign a PCI DSS officer: Appoint a qualified individual to oversee the PCI DSS compliance program and report to executive management.
• Communicate regularly: Regularly communicate the status of the PCI DSS compliance program and any relevant security risks to executive management.
• Document the program: Document the PCI DSS compliance program charter, outlining its objectives, roles, and responsibilities. Ensure this document is reviewed and approved by executive management.

How to comply with this requirement

PCI DSS Requirement 12.4.2: Review of security policy and procedure implementation (service providers only)

This requirement applies specifically to service providers and mandates regular reviews to verify that personnel are following established security policies and procedures.

• Service provider: An organization that stores, transmits, or processes cardholder data on behalf of merchants.
• Security policies and procedures: Documents outlining the organization's security practices for protecting cardholder data.

This requirement emphasizes the importance of verifying that documented security controls are effectively implemented in practice. It mandates reviews to be conducted:

• Frequency: At least once every three months.
• Performed by: Personnel independent of those responsible for the specific task being reviewed. This ensures objectivity.
• Review scope: Examples (not exhaustive) of security activities reviewed include:
  • Daily log reviews (e.g., security event logs, access control logs)
  • Configuration reviews for network security controls (e.g., firewalls, intrusion detection systems)
  • Applying configuration standards to new systems
  • Responding to security alerts
  • Change management processes

Business implication

• Reduced Security Risks: Regularly verifying that security policies and procedures are followed helps identify and address any gaps in your security controls. This reduces the risk of security incidents and potential data breaches.

Best practices to meet this requirement

• Develop review procedures: Establish documented procedures for conducting periodic reviews of security policy and procedure implementation.
• Define review scope: Clearly define the specific security activities and controls to be reviewed during these assessments.
• Assign reviewers: Appoint qualified personnel independent of the tasks being reviewed to conduct the assessments.
• Maintain review records: Document the findings of each review, including any identified issues and corrective actions taken.
• Schedule reviews: Set a recurring schedule to conduct security policy and procedure implementation reviews at least quarterly.

How to comply with this requirement

PCI DSS Requirement 12.4.2.1: Documentation of Security Policy and Procedure Review Findings (service providers only)

This requirement, applicable only to service providers, builds upon the previous requirement (12.4.2) for reviewing security policy and procedure implementation. It mandates documentation of the review findings.

• Service provider: An organization that stores, transmits, or processes cardholder data on behalf of merchants.
• Security policy and procedure reviews: Reviews conducted as per requirement 12.4.2 to verify personnel are following established security controls.

This requirement specifies the information that must be documented for each security policy and procedure review:

• Review results: A summary of the review findings, including any identified deviations from established security policies or procedures.
• Remediation actions: For any non-compliant findings, the documented actions planned or taken to address them.
• Management sign-off: The documented review results must be reviewed and approved by personnel assigned responsibility for the PCI DSS compliance program. This demonstrates management oversight and accountability.

Business implication

• Improved security posture: Documenting review findings and remediation actions creates a formal record for tracking and addressing security control deficiencies. This helps ensure ongoing adherence to security policies and strengthens your overall security posture.

Best practices to meet this requirement

• Develop review templates: Create standardized templates for documenting security policy and procedure review findings.
• Include remediation plans: Ensure your review documentation clearly outlines planned or completed remediation actions for identified non-compliance issues.
• Obtain management sign-off: Have personnel responsible for the PCI DSS compliance program review and sign off on the documented review findings.
• Maintain review records: Securely store documented security policy and procedure review findings for future reference and potential PCI DSS assessments.

How to comply with this requirement

PCI DSS Requirement 12.5: PCI DSS scope is documented and validated

PCI DSS Requirement 12.5.1: Inventory of in-scope system components (all entities)

This requirement applies to all organizations (merchants and service providers) and mandates maintaining a current inventory of all system components that fall within the scope of PCI DSS.

• System component: Any hardware, software, or firmware element within your IT infrastructure.
• PCI DSS scope: The specific systems, applications, and data that PCI DSS requirements apply to within your organization.

This requirement ensures a clear understanding of your environment and helps you implement PCI DSS controls effectively. Your inventory should include:

• List of all in-scope components: A comprehensive list of all hardware, software, and firmware elements that store, process, or transmit cardholder data.
• Description of function/use: A brief description of the purpose and functionality of each in-scope system component.

Business implication

• Reduced compliance costs: A well-maintained inventory helps avoid overlooking critical systems during PCI DSS assessments. This reduces the risk of non-compliance findings and associated remediation costs.

Best practices to meet this requirement

• Develop a system inventory process: Establish a documented process for identifying and maintaining a comprehensive inventory of your system components.
• Identify in-Scope systems: Clearly define the criteria for determining which systems are considered within the scope of PCI DSS based on their interaction with cardholder data.
• Gather system information: Collect details about each in-scope system component, including its function, purpose, and location.
• Maintain inventory accuracy: Regularly update your inventory to reflect any changes in your IT infrastructure, such as adding, removing, or modifying system components.
• Assign ownership: Assign ownership of the system inventory to a specific team or individual to ensure its ongoing maintenance.

How to comply with this requirement

PCI DSS Requirement 12.5.2: PCI DSS scope validation (all entities)

This requirement applies to all organizations (merchants and service providers) and emphasizes the importance of regularly validating the scope of your PCI DSS environment.

• PCI DSS scope: The specific systems, applications, and data that PCI DSS requirements apply to within your organization.
• Cardholder data (CHD): Any data that relates to a cardholder, including the primary account number (PAN), expiration date, service code, and cardholder name.
• Card data environment (CDE): The defined physical, logical, and virtual environment where CHD is stored, processed, or transmitted.

This requirement mandates that you document and confirm your PCI DSS scope at least annually and whenever there is a significant change to your environment. The scoping validation process should involve:

• Data flow identification: Identifying all the pathways your cardholder data travels through for various payment stages (authorization, capture, settlement, etc.) and across acceptance channels (card-present, card-not-present, etc.).
• Data flow diagram update: Updating your data flow diagrams (as required by PCI DSS 1.2.4) to reflect the identified data flows.
• Account data location identification: Pinpointing all locations where your CHD is stored, processed, or transmitted. This includes:
  • Locations outside your defined CDE
  • Applications that process CHD
  • Transmissions between systems and networks
  • File backups

Business implication

• Reduced risk of non-compliance: Regularly validating your PCI DSS scope helps ensure all relevant systems and data are identified and secured according to PCI DSS requirements. This minimizes the risk of non-compliance findings during assessments.

Best practices to meet this requirement

• Develop a scoping process: Establish a documented process for defining and validating your PCI DSS scope.
• Conduct annual reviews: Schedule annual reviews of your PCI DSS scope to verify its accuracy and alignment with your current environment.
• Identify significant changes: Define what constitutes a "significant change" to your environment that would trigger a re-evaluation of your PCI DSS scope (e.g., new applications, system upgrades, changes to data flows).
• Document scope validation: Document the results of your PCI DSS scope validation activities, including identified data flows, account data locations, and any changes made.
• Utilize data discovery tools: Consider using data discovery tools to help identify all locations where your CHD may reside within your environment.

How to comply with this requirement

PCI DSS Requirement 12.5.2.1: More Frequent Scope Validation for Service Providers (service providers only)

This requirement applies specifically to service providers and builds upon the general requirement (12.5.2) for validating PCI DSS scope. It mandates more frequent scope validation for service providers compared to merchants.

• Service provider: An organization that stores, transmits, or processes cardholder data on behalf of merchants.
• PCI DSS scope: The specific systems, applications, and data that PCI DSS requirements apply to within your organization.
• Cardholder data (CHD): Any data that relates to a cardholder, including the primary account number (PAN), expiration date, service code, and cardholder name.

This requirement dictates that service providers must document and confirm their PCI DSS scope:

• Frequency: At least once every six months.
• Additional trigger: In addition to the bi-annual reviews, whenever there is a significant change to the environment.
• Scope validation activities: The validation process must include all the elements specified in the general requirement (12.5.2), such as:
  • Identifying data flows for payment stages and channels
  • Updating data flow diagrams
  • Identifying all locations where CHD resides
  • Documenting the scope validation

Business implication

• Enhanced Security Posture: More frequent scope validation for service providers helps ensure a more accurate understanding of their PCI DSS environment. This allows for timely identification and securing of any in-scope systems or data that may have been previously overlooked, ultimately strengthening your overall security posture.

Best practices to meet this requirement

• Schedule regular reviews: Establish a recurring schedule for conducting PCI DSS scope reviews at least every six months for service providers.
• Define significant changes: Clearly define what constitutes a "significant change" to your environment that would trigger an immediate re-evaluation of your PCI DSS scope.
• Maintain detailed documentation: Document the results of your PCI DSS scope validation activities comprehensively, including identified data flows, account data locations, and any changes made.
• Utilize automation tools: Consider using automated data discovery tools to assist in identifying all locations of your CHD within your environment.

How to comply with this requirement

PCI DSS Requirement 12.5.3: Review of PCI DSS scope after organizational change (service providers only)

This requirement applies specifically to service providers and emphasizes the importance of reviewing PCI DSS scope and controls following significant organizational changes.

• Service provider: An organization that stores, transmits, or processes cardholder data on behalf of merchants.
• PCI DSS scope: The specific systems, applications, and data that PCI DSS requirements apply to within your organization.
• Organizational change: A significant modification to the structure or management of your service provider organization.

This requirement mandates that service providers conduct a documented internal review whenever there is a significant organizational change. This review should assess:

• Impact on PCI DSS scope: Whether the change has introduced new systems, applications, or data that fall within the scope of PCI DSS.
• Applicability of controls: Whether existing PCI DSS controls remain adequate and effective in the new organizational structure.

The results of this review, including any identified changes to scope or control requirements, must be documented and communicated to executive management.

Business implication

• Reduced risk of security gaps: Reviewing PCI DSS scope and controls after organizational changes helps ensure your security measures remain aligned with your evolving environment. This reduces the risk of security gaps that could be exploited by attackers.

Best practices to meet this requirement

• Define significant changes: Clearly define what constitutes a "significant change" to your organizational structure that would trigger a review of PCI DSS scope and controls (e.g., mergers, acquisitions, major personnel changes).
• Develop review process: Establish a documented process for conducting reviews of PCI DSS scope and controls following significant organizational changes.
• Document review findings: Clearly document the results of your review, including the impact on scope, control applicability, and any recommended actions.
• Communicate to management: Ensure the documented review findings and recommendations are communicated to executive management for their awareness and approval.

How to comply with this requirement

PCI DSS Requirement 12.6: Security awareness education is an ongoing activity

PCI DSS Requirement 12.6.1: Security awareness program (all entities)

This requirement applies to all organizations (merchants and service providers) and mandates implementing a formal security awareness program.

• Security awareness program: A structured program designed to educate and inform personnel about information security policies, procedures, and their role in protecting cardholder data.
• Information security policy: A formal document outlining the organization's overall information security strategy and controls.
• Cardholder data (CHD): Any data that relates to a cardholder, including the primary account number (PAN), expiration date, service code, and cardholder name.

This requirement emphasizes the importance of educating your personnel about information security. Your security awareness program should:

• Target all personnel: Provide security awareness training to all personnel, regardless of their role or level within the organization.
• Cover information security policies: Educate personnel about the organization's information security policy and relevant procedures.
• Highlight role in protecting CHD: Emphasize each individual's responsibility for protecting cardholder data and adhering to security policies.

Business implication

• Reduced risk of security incidents: An effective security awareness program can significantly reduce the risk of security incidents by fostering a culture of security awareness among your personnel. Educated employees are less likely to fall victim to phishing attacks or make unintentional security mistakes.

Best practices to meet this requirement

• Develop a security awareness program: Design a comprehensive security awareness program tailored to your organization's size, industry, and security risks.
• Offer training sessions: Conduct regular training sessions covering information security policies, procedures, and best practices for protecting CHD.
• Utilize diverse training methods: Employ a variety of training methods (e.g., online modules, in-person sessions, phishing simulations) to cater to different learning styles.
• Test employee knowledge: Regularly assess employee understanding of information security concepts through quizzes or knowledge checks.
• Provide ongoing communication: Maintain ongoing communication with personnel about security threats, updates to policies, and reporting procedures.

How to comply with this requirement

PCI DSS Requirement 12.6.2: Security awareness program review and update (all entities)

This requirement applies to all organizations (merchants and service providers) and builds upon the need for a formal security awareness program (12.6.1). It emphasizes the importance of regularly reviewing and updating your program to address evolving security threats.

• Security awareness program: A structured program designed to educate and inform personnel about information security policies, procedures, and their role in protecting cardholder data.
• Cardholder data environment (CDE): The defined physical, logical, and virtual environment where CHD is stored, processed, or transmitted.
• Cardholder data (CHD): Any data that relates to a cardholder, including the primary account number (PAN), expiration date, service code, and cardholder name.

This requirement mandates that you:

• Review your program: Conduct a review of your security awareness program at least annually.
• Update program content: Based on your review, update the program content as needed to address:
  • New security threats and vulnerabilities that could impact the security of your CDE.
  • The information provided to personnel about their role in protecting cardholder data.

Business implication

• Enhanced Security Posture: Regularly updating your security awareness program with the latest threats ensures your personnel are equipped to identify and mitigate evolving security risks. This translates to a more robust overall security posture for your organization.

Best practices to meet this requirement

• Schedule annual reviews: Establish a recurring schedule for reviewing your security awareness program at least once every year.
• Monitor threat landscape: Stay informed about emerging security threats and vulnerabilities relevant to your industry and the PCI DSS environment.
• Update training materials: Incorporate information about new threats and best practices into your security awareness training materials.
• Refine role-based content: Review and update the information provided to personnel about their specific roles and responsibilities in protecting cardholder data.

How to comply with this requirement

PCI DSS Requirement 12.6.3: Security awareness training (all entities)

This requirement applies to all organizations (merchants and service providers) and details the specific requirements for security awareness training for personnel.

• Security awareness training: Educational sessions designed to inform personnel about information security policies, procedures, and their role in protecting cardholder data.
• Information security policy: A formal document outlining the organization's overall information security strategy and controls.
• Cardholder data (CHD): Any data that relates to a cardholder, including the primary account number (PAN), expiration date, service code, and cardholder name.

This requirement mandates that your security awareness program includes regular training for all personnel, covering the following aspects:

• Training frequency:
  • Upon hire (new personnel)
  • At least once every 12 months (all personnel)
• Training methods:
  • Utilize multiple communication methods to cater to different learning styles (e.g., online modules, in-person sessions, video tutorials)
• Policy acknowledgement:
  • Require personnel to acknowledge at least annually that they have read and understood the information security policy and procedures.

Business implication

• Reduced human error risk: Regular security awareness training helps reduce the risk of human error by ensuring personnel are knowledgeable about information security policies and best practices. This minimizes the chance of unintentional actions that could compromise cardholder data.

Best practices to meet this requirement

• Develop training schedule: Establish a recurring schedule for conducting security awareness training for new hires and all personnel at least annually.
• Offer diverse training methods: Employ a variety of training methods to cater to different learning styles and preferences.
• Integrate with onboarding: Consider incorporating security awareness training into your new-hire onboarding process.
• Update training content: Regularly update your training materials to reflect evolving security threats and best practices.
• Offer role-based training: Tailor training content to address the specific information security needs and responsibilities of different personnel roles.
• Implement acknowledgement system: Develop a system for personnel to acknowledge annually that they have read and understood your information security policy and procedures.

How to comply with this requirement

PCI DSS Requirement 12.6.3.1: Security awareness training on phishing and social engineering (all entities)

This requirement applies to all organizations (merchants and service providers) and emphasizes the importance of including specific security awareness training on phishing and social engineering within your broader security awareness program (12.6.3).

• Security awareness training: Educational sessions designed to inform personnel about information security policies, procedures, and their role in protecting cardholder data.
• Phishing: A fraudulent attempt to obtain sensitive information, such as usernames, passwords, or credit card details, by masquerading as a trustworthy entity in an electronic communication.
• Social engineering: The manipulation of people into divulging confidential information or performing actions that could compromise the security of information systems.
• Cardholder data environment (CDE): The defined physical, logical, and virtual environment where CHD is stored, processed, or transmitted.
• Cardholder data (CHD): Any data that relates to a cardholder, including the primary account number (PAN), expiration date, service code, and cardholder name.

This specific requirement mandates that your security awareness training program covers the following aspects of phishing and social engineering:

• Identifying techniques: Educate personnel on how to recognize phishing emails and other social engineering attempts used by attackers.
• Responding to Suspicious Activity: Train personnel on how to react if they encounter a suspected phishing attempt or social engineering tactic.
• Reporting procedures: Establish clear procedures for personnel to report suspected phishing and social engineering activities to the appropriate department.

Business implication

• Reduced risk of social engineering attacks: Training personnel to identify and report phishing and social engineering attempts significantly reduces the risk of successful attacks that could compromise your cardholder data.

Best practices to meet this requirement

• Integrate phishing training: Incorporate specific training modules on identifying, responding to, and reporting phishing and social engineering attempts into your security awareness program.
• Utilize real-world examples: Use realistic examples of phishing emails and social engineering scenarios in your training materials to enhance learning and recognition.
• Conduct phishing simulations: Periodically conduct simulated phishing attacks to test your personnel's awareness and reporting practices. This helps identify areas for improvement and reinforce training messages.
• Establish reporting mechanisms: Develop clear and accessible channels for personnel to report suspected phishing and social engineering attempts.

How to comply with this requirement

PCI DSS Requirement 12.6.3.2: Security awareness training on acceptable use (all entities)

This requirement applies to all organizations (merchants and service providers) and builds upon the need for security awareness training on phishing and social engineering (12.6.3.1). It emphasizes incorporating training on the acceptable use of end-user technologies within your broader security awareness program (12.6.3).

• Security awareness training: Educational sessions designed to inform personnel about information security policies, procedures, and their role in protecting cardholder data.
• Acceptable use policy (AUP): A formal document outlining the acceptable and prohibited uses of organizational technology resources, including computers, mobile devices, and the network.
• End-user technologies: Any technology resources used by personnel, such as computers, laptops, tablets, smartphones, and USB drives.
• Cardholder data (CHD): Any data that relates to a cardholder, including the primary account number (PAN), expiration date, service code, and cardholder name.

This requirement mandates that your security awareness training program includes information about the key points of your AUP, specifically focusing on how it relates to protecting cardholder data. By understanding the acceptable use of technology resources, personnel can avoid actions that could compromise your security posture.

Business implication

• Reduced risk of security incidents: Educating personnel about the acceptable use of technology resources helps minimize the risk of security incidents caused by misuse of technology, such as downloading unauthorized software or storing cardholder data on personal devices.

Best practices to meet this requirement

• Integrate AUP training: Incorporate training modules on the key points of your AUP into your security awareness program.
• Highlight security implications: Clearly emphasize how adhering to the AUP directly contributes to protecting cardholder data and organizational security.
• Provide easy access to AUP: Make your AUP readily available to all personnel through a central repository or your company intranet.
• Offer Q&A sessions: Consider incorporating Q&A sessions into your training to address personnel questions and concerns regarding the AUP.

How to comply with this requirement

PCI DSS Requirement 12.7: Personnel are screened to reduce risks from insider threats

PCI DSS Requirement 12.7.1 : Personnel screening (all entities)

This requirement applies to all organizations (merchants and service providers) and emphasizes the importance of screening potential personnel before granting them access to the Cardholder Data Environment (CDE).

• Personnel screening: The process of evaluating potential employees to assess their suitability for a position, including background checks and reference checks.
• Cardholder data environment (CDE): The defined physical, logical, and virtual environment where CHD is stored, processed, or transmitted.
• Cardholder data (CHD): Any data that relates to a cardholder, including the primary account number (PAN), expiration date, service code, and cardholder name.

This requirement mandates that you conduct background checks on potential personnel before granting them access to the CDE. The specific details of the screening process may vary depending on local laws.

Business implication

• Reduced risk of insider threats: By screening personnel before granting access to the CDE, you can mitigate the risk of insider threats. This helps protect your organization from potential data breaches or misuse of cardholder data by malicious actors within your workforce.

Best practices to meet this requirement

• Develop screening policy: Establish a formal policy outlining your personnel screening procedures, considering local legal restrictions.
• Tailor screening level: Adjust the level of screening based on the sensitivity of the position and the level of access to the CDE. More critical roles may require more in-depth screening.
• Consider existing personnel: Evaluate the need for screening existing personnel whenever they are transferred to roles with access to the CDE.
• Screen within legal bounds: Ensure your screening practices comply with all applicable local laws and regulations regarding background checks.

How to comply with this requirement

PCI DSS Requirement 12.8: Risk to information assets associated with third-party service provider (TPSP) relationships is managed

PCI DSS Requirement 12.8.1: Inventory of third-party service providers (TPSPs) (all entities)

This requirement applies to all organizations (merchants and service providers) and mandates maintaining a comprehensive list of all third-party service providers (TPSPs) involved in your business.

• Third-party service provider (TPSP): An external organization that stores, processes, transmits, or otherwise has access to your cardholder data (CHD) or could impact the security of your CDE.
• Cardholder data (CHD): Any data that relates to a cardholder, including the primary account number (PAN), expiration date, service code, and cardholder name.
• Cardholder data environment (CDE): The defined physical, logical, and virtual environment where CHD is stored, processed, or transmitted.

This requirement emphasizes the importance of creating and maintaining a detailed inventory of all TPSPs. This inventory should include:

• A list of all TPSPs your organization interacts with.
• A description of the specific services each TPSP provides.

Business implication

• Enhanced security visibility: Maintaining a comprehensive TPSP inventory allows you to identify and manage potential security risks associated with third-party involvement. This helps you understand your extended attack surface and vulnerabilities beyond your internal environment.

Best practices to meet this requirement

• Develop TPSP inventory process: Establish a clear process for identifying and documenting all TPSPs your organization interacts with.
• Maintain updated inventory: Regularly update your TPSP inventory to reflect changes in your vendor landscape.
• Include service descriptions: Ensure your inventory includes a clear description of the services each TPSP provides to your organization.
• Integrate with risk management: Utilize your TPSP inventory to inform your risk management program by identifying potential security risks associated with third-party relationships.

How to comply with this requirement

PCI DSS Requirement 12.8.2: Written Agreements with Third-party Service Providers (TPSPs) (all entities)

This requirement applies to all organizations (merchants and service providers) and emphasizes the importance of having formal written agreements with all TPSPs involved in your business.

• Third-party service provider (TPSP): An external organization that stores, processes, transmits, or otherwise has access to your cardholder data (CHD) or could impact the security of your CDE.
• Cardholder data (CHD): Any data that relates to a cardholder, including the primary account number (PAN), expiration date, service code, and cardholder name.
• Cardholder data environment (CDE): The defined physical, logical, and virtual environment where CHD is stored, processed, or transmitted.

This requirement mandates that you have written agreements in place with all TPSPs you work with. These agreements must include specific acknowledgements from the TPSP regarding their security responsibilities for your cardholder data.

Business implication

• Clear shared responsibility: Formal written agreements with TPSPs establish clear expectations and responsibilities for protecting cardholder data. This helps mitigate potential disputes and ensures all parties understand their obligations regarding data security.

Best practices to meet this requirement

• Develop standard TPSP agreement: Create a standardized written agreement template outlining security expectations for all TPSPs.
• Tailor agreements to specific services: Adapt the standard agreement to reflect the specific services provided by each TPSP.
• Include security acknowledgement: Ensure the agreement clearly states the TPSP's acknowledgement of their responsibility for the security of CHD they store, process, or transmit on your behalf, or that could impact your CDE security.
• Consider nested relationships: If your TPSP utilizes additional subcontractors (nested TPSPs), consider including clauses in your agreement addressing their security practices and responsibilities.

How to comply with this requirement

PCI DSS Requirement 12.8.3: Due diligence for third-party service providers (TPSPs) (all entities)

This requirement applies to all organizations (merchants and service providers) and emphasizes the importance of establishing a formal process for engaging with TPSPs. This process should include thorough due diligence procedures before entering into any formal agreements with a TPSP.

• Third-party service provider (TPSP): An external organization that stores, processes, transmits, or otherwise has access to your cardholder data (CHD) or could impact the security of your CDE.
• Cardholder data (CHD): Any data that relates to a cardholder, including the primary account number (PAN), expiration date, service code, and cardholder name.
• Cardholder data environment (CDE): The defined physical, logical, and virtual environment where CHD is stored, processed, or transmitted.

This requirement mandates that you implement a structured process for engaging TPSPs. This process should include proper due diligence activities to assess the TPSP's security posture and capabilities before entrusting them with your cardholder data.

Business implication

• Reduced risk from third-party breaches: Conducting thorough due diligence on TPSPs helps mitigate the risk of data breaches or security incidents caused by inadequate security practices within your vendor ecosystem. This protects your organization from potential reputational damage and financial losses associated with compromised cardholder data.

Best practices to meet this requirement

• Develop TPSP engagement process: Establish a formal documented process outlining the steps for evaluating and selecting TPSPs.
• Conduct due diligence assessments: Perform comprehensive due diligence assessments on potential TPSPs, including reviewing their security policies, procedures, and PCI DSS compliance status.
• Evaluate security practices: Assess the TPSP's security controls, incident response procedures, and overall risk posture.
• Consider reporting practices: Understand the TPSP's approach to security reporting and how they would communicate potential breaches or incidents.

How to comply with this requirement

PCI DSS Requirement 12.8.4 : Monitoring third-party service provider (TPSP) PCI DSS compliance (all entities)

This requirement applies to all organizations (merchants and service providers) and mandates implementing a program to monitor the PCI DSS compliance status of your TPSPs.

• Third-party service provider (TPSP): An external organization that stores, processes, transmits, or otherwise has access to your cardholder data (CHD) or could impact the security of your CDE.
• Cardholder data (CHD): Any data that relates to a cardholder, including the primary account number (PAN), expiration date, service code, and cardholder name.
• Cardholder data environment (CDE): The defined physical, logical, and virtual environment where CHD is stored, processed, or transmitted.

This requirement emphasizes the importance of regularly monitoring your TPSPs' PCI DSS compliance posture. You must have a program in place to verify their compliance status at least once every 12 months.

Business implication

• Reduced reliance on untrusted vendors: Monitoring TPSP compliance helps ensure you are not unknowingly relying on vendors with inadequate security practices. This reduces the risk of potential security breaches or vulnerabilities within your vendor ecosystem that could compromise your cardholder data.

Best practices to meet this requirement

• Develop TPSP monitoring program: Establish a formal program outlining the process for monitoring the PCI DSS compliance of your TPSPs.
• Schedule annual reviews: Set a regular cadence (at least annually) to review and verify the PCI DSS compliance status of each TPSP.
• Gather compliance evidence: Collect evidence from your TPSPs demonstrating their PCI DSS compliance, such as Attestations of Compliance (AOC) or reports on compliance controls.
• Consider service specificity: Focus your monitoring efforts on the specific services provided by each TPSP that are relevant to your PCI DSS scope.

How to comply with this requirement

PCI DSS Requirement 12.8.5: Shared responsibility matrix for PCI DSS compliance (all entities)

This requirement applies to all organizations (merchants and service providers) and emphasizes the importance of maintaining a clear understanding of PCI DSS compliance responsibilities between your organization and your TPSPs.

• Third-party service provider (TPSP): An external organization that stores, processes, transmits, or otherwise has access to your cardholder data (CHD) or could impact the security of your CDE.
• Cardholder data (CHD): Any data that relates to a cardholder, including the primary account number (PAN), expiration date, service code, and cardholder name.
• Cardholder data environment (CDE): The defined physical, logical, and virtual environment where CHD is stored, processed, or transmitted.

This requirement mandates that you maintain documented information outlining which specific PCI DSS requirements are:

• Managed by you (the entity)
• Managed by each of your TPSPs
• Shared responsibilities between you and your TPSPs

Business implication

• Clear accountability for security controls: A documented shared responsibility matrix fosters clear communication and accountability between you and your TPSPs regarding PCI DSS compliance. This helps avoid confusion and ensures all necessary security controls are implemented by the appropriate party.

Best practices to meet this requirement

• Develop shared responsibility matrix: Create a formal matrix that clearly outlines which PCI DSS requirements are the responsibility of your organization, your TPSPs, or a shared responsibility.
• Maintain up-to-date matrix: Regularly review and update your shared responsibility matrix to reflect changes in your TPSP relationships or PCI DSS revisions.
• Consider nested relationships: If your TPSP utilizes additional subcontractors (nested TPSPs), understand their role and how they contribute to overall PCI DSS compliance.

How to comply with this requirement

PCI DSS Requirement 12.9: Third-party service providers (TPSPs) support their customers’ PCI DSS compliance

PCI DSS Requirement 12.9.1: Service provider acknowledgment of cardholder data security (service providers only)

This requirement applies only to organizations that are service providers (SPs). It mandates that SPs provide a formal written acknowledgement to their customers regarding their responsibility for the security of cardholder data (CHD).

• Service provider (SP): An organization that stores, processes, transmits, or otherwise has access to a customer's cardholder data (CHD) on their behalf.
• Cardholder data (CHD): Any data that relates to a cardholder, including the primary account number (PAN), expiration date, service code, and cardholder name.
• Cardholder data environment (CDE): The defined physical, logical, and virtual environment where CHD is stored, processed, or transmitted.

This requirement emphasizes the importance of SPs formally acknowledging their commitment to securing CHD they handle for their customers. This acknowledgement should be provided in writing and clearly outline the SP's responsibility for:

• CHD they possess
• CHD they store or process on the customer's behalf
• CHD they transmit
• Any aspect that could impact the security of the customer's CDE

Business implication

• Enhanced customer trust and transparency: Formal written acknowledgements from SPs regarding CHD security fosters trust and transparency with their customers. This demonstrates the SP's commitment to data security and helps manage customer expectations.

Best practices to meet this requirement

• Develop standardized acknowledgement: Create a standardized written acknowledgement template outlining the SP's security responsibilities for CHD.
• Tailor acknowledgement to agreements: Adapt the standardized acknowledgement to reflect the specific details of each customer agreement, including the services provided and responsibilities assigned.
• Include in service agreements: Incorporate the written acknowledgement within your formal service agreements with customers.

How to comply with this requirement (service providers only):

PCI DSS Requirement 12.9.2: Service provider support for customer PCI DSS compliance (service providers only)

This requirement applies only to organizations that are service providers (SPs). It mandates that SPs support their customers' efforts to comply with PCI DSS by providing specific information upon request.

• Service provider (SP): An organization that stores, processes, transmits, or otherwise has access to a customer's cardholder data (CHD) on their behalf.
• Cardholder data (CHD): Any data that relates to a cardholder, including the primary account number (PAN), expiration date, service code, and cardholder name.

This requirement emphasizes the importance of SPs being responsive to customer requests for information related to PCI DSS compliance. Specifically, SPs must be prepared to provide the following information to their customers upon request:

• PCI DSS compliance status (requirement 12.8.4): Information regarding the SP's overall PCI DSS compliance status for any services they perform on behalf of the customer.
• Shared responsibility matrix (requirement 12.8.5): Details outlining which PCI DSS requirements are the responsibility of the SP, the customer, or a shared responsibility between both parties.

Business implication

• Reduced customer compliance burden: By readily providing PCI DSS compliance information to customers, SPs help streamline the compliance process for their clients. This fosters collaboration and reduces the burden on customers to gather necessary details for their own assessments.

Best practices to meet this requirement

• Develop information access procedures: Establish clear procedures for how customers can request and receive PCI DSS compliance information from your organization.
• Maintain compliance documentation: Keep your PCI DSS compliance documentation readily available, including AOCs (if applicable) and shared responsibility matrices.
• Respond promptly to requests: Ensure timely responses to customer requests for PCI DSS compliance information.

How to comply with this requirement (service providers only):

PCI DSS Requirement 12.10: Suspected and confirmed security incidents that could impact the CDE are responded to immediately

PCI DSS Requirement 12.10.1: Incident Response Plan and Procedures (all entities)

This requirement applies to all organizations (merchants and service providers) and mandates having a documented incident response plan (IRP) in place. This plan should be readily available for activation in the event of a suspected or confirmed security incident.

• Incident response plan (IRP): A documented plan outlining roles, responsibilities, procedures, and communication strategies for effectively responding to security incidents.
• Security incident: An event that violates your security policy and compromises the confidentiality, integrity, or availability of your assets (including cardholder data).

This requirement specifies that your IRP must include, but is not limited to, the following elements:

• Roles and responsibilities: Clearly defined roles and responsibilities for personnel involved in incident response activities.
• Communication and contact strategies: Defined communication protocols for internal and external stakeholders during a security incident, including minimum notification requirements for payment brands and acquirers.
• Incident response procedures: Detailed procedures for containing, mitigating, and recovering from various types of security incidents.
• Business recovery and continuity procedures: Processes for restoring critical business operations and data after a security incident.
• Data backup processes: Procedures for backing up data to ensure its availability in the event of a security incident.
• Legal requirements analysis: Identification and understanding of legal requirements for reporting security incidents involving cardholder data.
• Critical system response: Strategies for addressing security incidents impacting critical system components within your environment.
• Payment brand IRP reference: Inclusion of or reference to incident response procedures outlined by the relevant payment brands.

Business implication

• Reduced downtime and reputational risk: A well-defined and tested IRP helps your organization respond effectively to security incidents, minimizing downtime, data loss, and potential reputational damage.

Best practices to meet this requirement

• Develop comprehensive IRP: Create a detailed IRP document outlining all the elements specified in this requirement.
• Assign roles and responsibilities: Clearly define roles and responsibilities for personnel involved in incident response activities.
• Maintain updated contact information: Ensure your IRP includes current contact information for all internal and external stakeholders.
• Test and update IRP regularly: Conduct regular testing of your IRP to ensure its effectiveness and update it periodically to reflect changes in your environment or security posture.

How to comply with this requirement

PCI DSS Requirement 12.10.2: Incident response plan review and testing (all entities)

This requirement applies to all organizations (merchants and service providers) and emphasizes the importance of maintaining a current and effective incident response plan (IRP).

• Incident response plan (IRP): A documented plan outlining roles, responsibilities, procedures, and communication strategies for effectively responding to security incidents.
• Security incident: An event that violates your security policy and compromises the confidentiality, integrity, or availability of your assets (including cardholder data).

This requirement mandates that you conduct the following activities on your IRP at least once every 12 months:

• Review and update: Thoroughly review the content of your IRP and update it as necessary to reflect any changes in your environment, personnel, or security posture.
• Testing: Conduct a comprehensive test of your IRP, simulating a security incident and evaluating your team's ability to execute the plan effectively. This test should encompass all elements outlined in Requirement 12.10.1 (roles, communication, procedures, etc.).

Business implication

• Enhanced security preparedness: Regular review and testing of your IRP ensure it remains relevant and effective. This fosters a state of preparedness for your organization to respond swiftly and efficiently to security incidents, minimizing potential damage.

Best practices to meet this requirement

• Schedule annual review and test: Establish a recurring calendar reminder to conduct your annual IRP review and testing activities.
• Involve key stakeholders: Include personnel from various departments (IT, security, legal, communications) during your IRP review and testing to ensure all aspects are considered.
• Simulate realistic scenarios: Design your IRP test to simulate a realistic security incident scenario that could impact your organization.
• Document findings and improvements: Document the results of your IRP review and testing, including any identified issues and corrective actions planned.

How to comply with this requirement

PCI DSS Requirement 12.10.3: 24/7 Incident response availability (all entities)

This requirement applies to all organizations (merchants and service providers) and emphasizes the importance of having designated personnel available to respond to security incidents on a 24/7 basis.

• Security incident: An event that violates your security policy and compromises the confidentiality, integrity, or availability of your assets (including cardholder data).

This requirement mandates that you designate specific personnel who can be reached 24/7 to initiate a response to suspected or confirmed security incidents.

Business implication

• Faster incident response and resolution: Having designated personnel readily available to respond to security incidents minimizes delays in containment, mitigation, and recovery efforts. This helps reduce potential damage and business disruption.

Best practices to meet this requirement

• Establish security incident response team (SIRT): Create a dedicated SIRT with members who are trained and prepared to respond to security incidents.
• Implement rotating schedule: Consider a rotating schedule within your SIRT to ensure 24/7 coverage for incident response.
• Utilize on-call support: For smaller organizations, consider outsourcing on-call support to a security provider for after-hours or weekend incident response.
• Provide clear contact information: Clearly communicate the contact information for designated incident response personnel to relevant internal and external stakeholders.

How to comply with this requirement

PCI DSS Requirement 12.10.4: Incident response training (all entities)

This requirement applies to all organizations (merchants and service providers) and emphasizes the importance of providing appropriate and periodic training to personnel responsible for responding to security incidents.

• Security incident: An event that violates your security policy and compromises the confidentiality, integrity, or availability of your assets (including cardholder data).

This requirement mandates that you provide training to personnel designated for incident response. This training should cover their roles, responsibilities, and proper procedures outlined in your incident response plan (IRP). The training should be:

• Appropriate: Tailored to the specific roles and responsibilities of each individual within the incident response team.
• Periodic: Conducted regularly to ensure personnel remain knowledgeable about the latest incident response best practices and procedures outlined in your IRP.

Business implication

• Effective incident response: A well-trained incident response team can effectively contain, mitigate, and recover from security incidents, minimizing potential damage and business disruption.

Best practices to meet this requirement

• Develop incident response training program: Establish a training program specifically focused on incident response procedures outlined in your IRP.
• Conduct regular training sessions: Schedule regular training sessions for your incident response team to ensure they remain up-to-date on best practices.
• Include training on evidence management: Integrate training on managing and preserving evidence for forensic analysis and investigations during incident response activities.
• Simulate incident response scenarios: Consider incorporating simulated incident response scenarios into your training program to provide practical experience for your team.

How to comply with this requirement

PCI DSS Requirement 12.10.4.1: Frequency of incident response training (all entities) (effective after March 31, 2025)

This requirement applies to all organizations (merchants and service providers) and will become mandatory after March 31, 2025. It emphasizes defining the frequency of periodic training for personnel responsible for responding to security incidents.

• Targeted risk analysis (TRA): A comprehensive assessment that identifies security risks specific to your organization's cardholder data environment (CDE).
• Security incident: An event that violates your security policy and compromises the confidentiality, integrity, or availability of your assets (including cardholder data).

This requirement mandates that the frequency of periodic training for your incident response team is defined within your documented Targeted Risk Analysis (TRA). The TRA itself should be conducted following all elements specified in PCI DSS Requirement 12.3.1 (refer to PCI DSS documentation for details on 12.3.1).

Business implication

• Risk-based training optimization: Defining the training frequency based on your organization's specific risk profile ensures your incident response team receives the necessary training to address potential threats effectively. This avoids over-training or under-training your team.

Best practices to meet this requirement

• Conduct regular targeted risk analysis (TRA): Perform periodic TRAs to identify and assess evolving security risks within your CDE.
• Define training frequency based on risk: Based on the identified risks in your TRA, determine the appropriate frequency for training your incident response team. Higher risk environments may necessitate more frequent training sessions.
• Document training frequency in TRA: Clearly document the defined training frequency for incident response personnel within your TRA.

How to comply with this requirement (Effective After March 31, 2025):

PCI DSS Requirement 12.10.5: Monitoring and responding to security alerts (all entities)

This requirement applies to all organizations (merchants and service providers) and emphasizes the importance of including security monitoring and alert response within your incident response plan (IRP).

• Security incident response plan (IRP): A documented plan outlining roles, responsibilities, procedures, and communication strategies for effectively responding to security incidents.
• Security incident: An event that violates your security policy and compromises the confidentiality, integrity, or availability of your assets (including cardholder data).
• Security monitoring system: A system designed to detect and record security-related events within your IT environment.

This requirement mandates that your IRP explicitly addresses monitoring and responding to alerts generated by various security monitoring systems. These systems include, but are not limited to:

• Intrusion detection/prevention systems (IDS/IPS): Systems that detect and potentially prevent unauthorized attempts to access or exploit your systems.
• Network security controls: Firewalls, access control lists (ACLs), and other mechanisms that monitor and control network traffic.
• Change-detection mechanisms: Systems that monitor critical files for unauthorized modifications.

Business implication

• Proactive threat detection and response: Promptly addressing alerts from your security monitoring systems allows for earlier detection and mitigation of potential security incidents, minimizing potential damage and business disruption.

Best practices to meet this requirement

• Integrate security monitoring with IRP: Ensure your IRP includes clear procedures for handling and escalating security alerts from your monitoring systems.
• Define alert response procedures: Establish well-defined procedures for evaluating, prioritizing, and responding to different types of security alerts.
• Conduct regular review and testing: Periodically review and test your security monitoring systems and the corresponding alert response procedures within your IRP.

How to comply with this requirement

PCI DSS Requirement 12.10.6: Continuous improvement of incident response plan (all entities)

This requirement applies to all organizations (merchants and service providers) and emphasizes the importance of maintaining a continuously evolving and improved incident response plan (IRP).

• Security incident response plan (IRP): A documented plan outlining roles, responsibilities, procedures, and communication strategies for effectively responding to security incidents.
• Security incident: An event that violates your security policy and compromises the confidentiality, integrity, or availability of your assets (including cardholder data).

This requirement mandates that you establish a process for regularly reviewing, updating, and evolving your IRP based on two key factors:

• Lessons learned: Following a security incident, conduct a thorough review to identify areas for improvement within your IRP based on the incident response experience.
• Industry developments: Stay informed about emerging security threats and best practices within the industry. Integrate these learnings into your IRP to ensure it remains effective against evolving threats.

Business implication

• Enhanced security posture: A continuously improved IRP ensures your organization remains prepared to address the latest security threats and effectively respond to security incidents, minimizing potential damage and business disruption.

Best practices to meet this requirement

• Conduct post-incident reviews: Following a security incident, convene a review team to analyze the response and identify areas for improvement within your IRP.
• Track industry trends and best practices: Subscribe to security advisories and industry publications to stay updated on evolving threats and best practices for incident response.
• Schedule regular IRP reviews: Establish a recurring schedule to review your IRP and incorporate lessons learned and industry developments.
• Document changes and updates: Maintain a clear audit trail by documenting all changes and updates made to your IRP.

How to comply with this requirement

PCI DSS Requirement 12.10.7: Incident response for unexpected stored PAN (best practice Until March 31, 2025)

This requirement applies to all organizations (merchants and service providers) as a best practice until March 31, 2025. After that date, it will become a mandatory requirement. It emphasizes the importance of having documented incident response procedures specifically for situations where stored Primary Account Numbers (PAN) are discovered outside your Cardholder Data Environment (CDE).

• Primary account number (PAN): The full number printed on the front of a credit, debit, or prepaid card.
• Stored PAN: Any PAN information retained by your organization.
• Cardholder data environment (CDE): The physical or logical environment where cardholder data is processed, stored, or transmitted.
• Security incident: An event that violates your security policy and compromises the confidentiality, integrity, or availability of your assets (including cardholder data).

This requirement outlines specific procedures that should be included in your incident response plan for handling situations where stored PAN data is found outside your designated CDE. These procedures should address the following:

• Retrieval, secure deletion, or migration: Define the appropriate actions to take regarding the discovered PAN data. This could involve retrieving it securely, permanently deleting it if no longer needed, or migrating it into your defined CDE (if applicable).
• Identifying sensitive authentication data: Investigate whether any sensitive authentication data (e.g., security codes, expiration dates) is stored alongside the discovered PAN.
• Source and cause determination: Identify the origin of the PAN data and determine how it ended up outside your CDE. This helps identify potential vulnerabilities or process gaps that need to be addressed.
• Remediation: Implement corrective actions to address any data leaks or process gaps that led to the PAN data being stored outside the CDE.

Business implication

• Reduced risk of data breaches: Having a documented response plan for unexpected stored PAN allows you to quickly identify and address potential security incidents, minimizing the risk of data breaches and associated financial losses.

Best practices to meet this requirement

• Document incident response procedures: Include clear procedures within your incident response plan that outline how to respond to the discovery of stored PAN data outside the CDE.
• Perform root cause analysis: When unexpected PAN data is found, conduct a thorough investigation to identify the root cause and implement corrective actions to prevent future occurrences.
• Review business processes and user activity: Evaluate your business processes and user behavior to identify any potential contributors that led to the PAN data being stored outside the CDE.
• Address control gaps: Identify and address any control gaps in your security measures that allowed PAN data to be stored outside the designated CDE.

How to comply with this requirement (Best Practice Until March 31, 2025):