Welcome to our latest blog post where we delve into the intricacies of the Payment Card Industry Data Security Standard (PCI DSS) Requirement 12. This requirement, which focuses on maintaining an Information Security Policy, is a cornerstone of the PCI DSS framework. It outlines the need for comprehensive policies and programs that govern and provide direction for the protection of an entity’s information assets.
In this post, we will explore the changes introduced in the latest version, v4.0, and how they compare to the previous version, v3.2.1. From acceptable use policies for end-user technologies to managing risks associated with third-party service provider relationships, we will provide a detailed explanation of each section under Requirement 12. check out our comprehensive guide on the “12 requirements of PCI DSS.”
Whether you’re a full-time employee, a part-time worker, a temporary employee, a contractor, or a consultant with security responsibilities, this post will help you understand your role in protecting account data and the security implications of your actions. So, let’s dive in and unravel the changes from v3.2.1 to v4.0 in PCI DSS Requirement 12.
| Requirement | v3.2.1 (12.4) | v4.0 (12.1.3) | Changes |
|---|---|---|---|
| Core Requirement | Security policies must define information security responsibilities for everyone. | Identical core requirement. | No Changes. |
| Awareness | Implies personnel awareness of responsibilities. | It explicitly requires that personnel are aware of and acknowledge their responsibilities. | Increased emphasis on awareness and accountability. |
| Testing Procedures | Focuses on policy review and interviewing personnel to check understanding. | Maintains policy review and interviews but adds verifying documented evidence of personnel acknowledgment. | Stronger focus on formal processes and evidence. |
PCI DSS v4.0 mandates active acknowledgement of security roles and responsibilities by personnel and requires documented evidence of this acknowledgement.
| Requirement | v3.2.1 (12.5) | v4.0 (12.1.4) | Changes |
|---|---|---|---|
| Scope | Requires formal assignment of overall information security responsibility and assignment of specific information security tasks. | Focuses on the formal assignment of overall information security responsibility. | Narrowed focus. |
| Responsibility | Responsibility could be assigned to a "Chief Security Officer or other security-knowledgeable member of management". | Explicitly states responsibility must lie with a "Chief Information Security Officer or other information security knowledgeable member of executive management." | Emphasizes executive-level ownership. |
| Testing Procedures | Focuses on verifying formal assignment of various responsibilities through policy and procedure review. | Simplified testing by focusing solely on policy review for executive-level assignment. | Streamlined testing. |
PCI DSS v4.0 mandates that a CISO or equivalent executive owns overall information security, removes focus on individual tasks, and verifies executive responsibility through policy review.
| Requirement | v3.2.1 (12.3) | v4.0 (12.2.1) | Changes |
|---|---|---|---|
| Scope | Broadly focuses on usage policies for "critical technologies", which include wireless, remote access, laptops, tablets, etc. | Narrows focus specifically on "end-user technologies". | Makes scope more explicit. |
| Policy Elements | Extensive list: explicit approval, authentication, device lists, ownership tracking, acceptable use/locations, approved products, session disconnects, vendor access controls. | Streamlined list: explicit approval, acceptable uses, approved tech list (hardware/software). | Simplified policy requirements. |
| Testing Procedures | Focuses on verifying the existence and implementation of the detailed policy requirements. | Focuses on verifying that the simplified policy elements are documented and followed. | Less prescriptive testing. |
PCI DSS v4.0 refines technology usage policies by emphasizing applicability to commonly used technologies, reducing mandatory policy elements, and focusing on core element verification rather than specific details.
| Requirement | v3.2.1 (12.3.10) | v4.0 (3.4.2) | Changes |
|---|---|---|---|
| Core Concept | Limiting the possibility of cardholder data being copied/moved to local drives when accessed remotely. | Same core concept. | No Changes. |
| Policy vs Technical Focus | v3.2.1 focuses on having a documented policy prohibiting copying/moving, with an exception for authorized use. | Shifts to explicitly requiring technical controls to prevent copying/moving by default, with authorized exceptions possible. | Focus on proactive prevention. |
| Authorized Exceptions | Requires documented business need and data protection even for authorized copying/moving. | Maintains the need for authorization, business justification, and lists of approved personnel. | Similar approach for handling exceptions. |
| Testing Procedures | Focuses on policy review and verifying the policy aligns with PCI DSS requirements. | Includes policy review but focuses on verifying technical controls and interviewing personnel to confirm practice aligns with authorization. | Emphasizes real-world controls. |
PCI DSS v4.0 enhances remote access data protection by mandating technical controls as default, maintaining authorization for exceptions, and emphasizing the use of technical controls in line with authorizations.
| Requirement | v3.2.1 (12.11) | v4.0 (12.4.2) | Changes |
|---|---|---|---|
| Core Requirement | Quarterly reviews to confirm personnel follow security policies and procedures. | Increases frequency to "at least once every three months" and adds requirement for reviews to be done by someone other than the person normally performing the task. | More frequent, independent reviews. |
| Scope | Specific list of tasks to be included in the reviews. | Maintains the same list of tasks. | No changes. |
| Documentation | Requires documenting review results and sign-off by those responsible for PCI DSS compliance. | Adds the requirement to document any remediation actions taken based on review findings. | Focus on fixing issues, not just finding them. |
| Testing Procedures | Focuses on policy review, interviewing personnel, and examining review records. | Similar focus but adapted for the increased review frequency. | Minor adjustments for frequency. |
PCI DSS v4.0 enhances personnel compliance oversight in service providers by mandating tri-monthly reviews, requiring independent reviewers, and focusing on documenting required remediations.
| Requirement | v3.2.1 | v4.0 (12.5.1) | Changes |
|---|---|---|---|
| Core Requirement | Having a system components inventory was implied as part of overall documentation practices. | Explicitly requires an inventory of system components within the scope of PCI DSS, along with their function/use. | Increased clarity and specificity. |
| Location | No specific location within PCI DSS requirements. | Requirement is now placed within Section 12.5, which focuses on documenting and validating the scope of PCI DSS compliance efforts. | Better organization and context. |
| Testing Procedures | Implied you'd check this as part of general documentation review and personnel knowledge | Specific testing steps focused on verifying the inventory's existence, completeness and that it's kept up to date. | More focused testing guidance. |
PCI DSS v4.0 enhances in-scope system component inventory management by making it an explicit requirement with detailed contents, organizing it within the PCI DSS scope context, and providing specific guidance for verifying inventory accuracy and maintenance.
| Requirement | v3.2.1 (12.6) | v4.0 (12.6.1) | Changes |
|---|---|---|---|
| Core Requirement | Implement a security awareness program covering cardholder data security policies and procedures for all personnel. | Emphasizes that the program must cover the entity's broader information security policy and each person's role in protecting cardholder data. | Slightly broadened scope. |
| Terminology | Focuses on "cardholder data security" | Shifts to include awareness of protecting "cardholder data" within the context of the overall "information security policy". | Highlights broader security mindset. |
| Testing Procedures | Implies verifying the program teaches about cardholder data policies and procedures. | No changes – the focus remains on verifying that the awareness program exists and covers the core concepts. | No changes. |
PCI DSS v4.0 modifies the security awareness requirement to emphasize a holistic approach, focusing on the company’s overall information security policy and everyone’s contribution to security.
| Requirement | v3.2.1 (12.6.1 & 12.6.2) | v4.0 (12.6.3) | Changes |
|---|---|---|---|
| Core Requirements | Separate requirements for: 1. Educating personnel upon hire and annually. 2. Personnel acknowledgment of policies at least annually. | Consolidates these into a single requirement with the same core components. | Streamlined approach. |
| Training Methods | Requires using multiple methods for communicating awareness. | Maintains this requirement for diverse training approaches. | No changes. |
| Testing Procedures | Focuses on verifying the program includes the elements and that personnel comply. | Similar focus, with minor adjustments to align with the consolidated requirement. | Minor update for consistency. |
PCI DSS v4.0 consolidates security awareness training requirements into a single rule, while preserving the essentials like initial and annual training, multiple communication methods, and policy acknowledgment.
| Requirement | v3.2.1 (12.8) | v4.0 (12.8) | Changes |
|---|---|---|---|
| Terminology | Uses the term "service provider" | Shifts to "third-party service provider" (TPSP) for clarity. | More specific language. |
| List of TPSPs | Requires keeping a list with a description of services provided. | Same core requirement. | No changes. |
| Written Agreements | Requires acknowledgments within the agreement that the service provider is responsible for cardholder data security. | Maintains this requirement. | No changes. |
| Due Diligence | Requires an established process for engaging service providers with due diligence. | Maintains this requirement. | No changes. |
| Compliance Monitoring | Requires a program to monitor service providers' PCI DSS compliance annually. | Maintains this requirement but changes the frequency to at least every 12 months. | Minor change to monitoring interval. |
| Responsibility Tracking | Mandates keeping track of which PCI DSS requirements are managed by the service provider vs. the entity. | Maintains this requirement. | No changes. |
| Testing Procedures | Focuses on verifying the existence of policies, agreements, and processes that are followed. | Maintains a similar focus. | No major changes. |
PCI DSS v4.0 revises third-party relationships by replacing “service provider” with “third-party service provider” for clarity and shifting annual PCI DSS compliance monitoring of TPSPs to at least every 12 months.
| Requirement | v3.2.1 (12.10.1) | v4.0 (12.10.1) | Changes |
|---|---|---|---|
| Triggering Event | Focuses on a "system breach" or "compromise". | Shifts language to "suspected or confirmed security incident", expanding the scope of what triggers the plan. | Broadened scope. |
| Plan Elements | Lists required elements of the plan. Includes analysis of legal requirements, like regional data breach notification laws (California example provided). | Maintains the same core elements of the plan. | No changes. |
| Testing Procedures | Focus on verifying the plan has the necessary components and that past incident responses aligned with the documented plan. | Maintains a similar focus. | No major changes. |
PCI DSS v4.0 broadens the incident response plan scope to include a wider range of security incidents, not just breaches or compromises.
| Requirement | v3.2.1 (12.10.3 ) | v4.0 (12.10.3) | Changes |
|---|---|---|---|
| Core Requirement | Designate personnel for 24/7 availability to respond to alerts | Shifts focus to 24/7 availability for "suspected or confirmed security incidents". | Broadened scope. |
| Testing Procedures | Focuses on verifying the roles are designated and that they monitor for specific threats (e.g., unauthorized access points, critical alerts). | More streamlined – focuses on verifying the existence of 24/7 designated roles. | Simplified testing. |
PCI DSS v4.0 expands the 24/7 incident response staffing scope to include all “suspected or confirmed security incidents” and simplifies testing by removing the need to verify specific threat types monitored.
| Requirement | v3.2.1 (12.10.4) | v4.0 (12.10.4) | Changes |
|---|---|---|---|
| Personnel to Train | Those with "security breach response responsibilities" | Shifts to cover anyone with roles in responding to "suspected or confirmed security incidents" | Broadened scope. |
| Training Content | Implied to focus on breach response | Explicitly mandates focusing on specific incident response responsibilities. | More focused training content. |
| Testing Procedures | Focuses on verifying the training exists and happens periodically. | Maintains a similar focus. | No major changes. |
PCI DSS v4.0 enhances incident response training by expanding its scope to all security incidents and mandating role-specific training content.
| Requirement | V3.2.1 (12.10.5) | v4.0 (12.10.5) | Changes |
|---|---|---|---|
| Core Requirement | 12.10.5: Incident response plan must address alerts from security monitoring systems (IDS/IPS, firewalls, FIM implied). 11.1.2: Plan must specifically cover unauthorized wireless alerts. 11.5.1: Requires a process to respond to change-detection alerts | Consolidates these and adds new alert types to the plan. | Consolidation & expansion. |
| Monitored Systems | Implied focus on IDS/IPS, firewalls, FIM. | Explicitly includes IDS/IPS, network security controls, change-detection for critical files, unauthorized wireless, and (in the future) payment page tampering detection. | Significantly expands the scope. |
| Testing Procedures | v3.2.1 had separate testing focused on the plan and real-world responses to wireless/change-detection alerts. | Maintains the focus on verifying the plan covers the listed systems and observes practice. | Streamlined testing. |
PCI DSS v4.0 enhances incident response planning by consolidating alert response requirements, expanding the scope of security alerts, and simplifying testing to ensure practice alignment.
New Requirements:
Requirement 12.3.1:
PCI DSS v4.0 requirement 12.3.1 is about conducting a risk analysis for each flexible PCI DSS requirement. This analysis should:
- Identify the assets to protect and the threats they face.
- Determine factors that affect the likelihood or impact of these threats.
- Decide how often the requirement should be performed to minimize threat risk.
- Review and update this analysis at least annually or when necessary.
- (This requirement is a best practice until 31 March 2025.)
The organization must have documented policies and procedures for this process.
Requirement 12.3.2:
Requirement 12.3.2 in PCI DSS v4.0 is about validating your custom security methods. You need to:
- Document your custom approach and its effectiveness.
- Get approval from senior management.
- Conduct an annual review to ensure its effectiveness.
- Have an assessor verify the documentation and approval process.
- (This requirement is effective immediately for all entities undergoing a v4.0 assessment and using a customized approach.)
Requirement 12.3.3:
Requirement 12.3.3 in PCI DSS v4.0 is about maintaining up-to-date encryption. You need to:
- List all encryption methods you use.
- Stay informed about industry news for any weaknesses.
- Plan your strategy for future encryption issues.
- Review and update this information annually.
- An assessor will verify your list and process.
- (This requirement is a best practice until 31 March 2025.)
Requirement 12.3.4:
Requirement 12.3.4 in PCI DSS v4.0 is about avoiding outdated technology. You need to:
- Track your hardware and software.
- Check for updates regularly.
- Stay aware of tech news for ‘end of life’ announcements.
- Have an upgrade plan for outdated tech.
- Review this information annually.
- An assessor will verify your process and documentation.
- (This requirement is a best practice until 31 March 2025.)
Requirement 12.5.2:
Requirement 12.5.2 in PCI DSS v4.0 is about tracking your Cardholder Data Environment (CDE). You need to:
- Map CHD flow at every stage.
- List all places where CHD is stored, processed, or sent.
- Identify each component in your payment environment.
- Check connections with third parties.
- Review this information yearly and after major system changes.
- An assessor will verify your last review and the review process.
- (This requirement is effective immediately for all v4.0 assessments)
Requirement 12.5.2.1:
Requirement 12.5.2.1 in PCI DSS v4.0 for service providers involves:
- Following all steps in requirement 12.5.2.
- Reviewing security maps and system lists twice a year.
- Reviewing after major changes in data handling.
- An assessor will verify the reviews and their frequency.
- (This requirement is a best practice until 31 March 2025.)
Requirement 12.5.3:
Requirement 12.5.3 in PCI DSS v4.0 for service providers involves:
- Conducting a documented review of the impact on PCI DSS scope and controls due to significant organizational changes.
- Communicating the results to executive management.
- Examining policies and procedures to ensure they define processes for such reviews.
- Verifying that significant organizational changes resulted in documented reviews, with an assessor checking documentation and interviewing personnel.
- (This requirement is a best practice until 31 March 2025.)
Requirement 12.6.2:
Requirement 12.6.2 in PCI DSS v4.0 involves:
- Reviewing training materials annually for accuracy.
- Updating training as needed due to new threats or role changes.
- An assessor will verify the review records and training program.
- (This requirement is a best practice until 31 March 2025.)
Requirement 12.6.3.1:
Requirement 12.6.3.1 in PCI DSS v4.0 involves:
- Training employees to spot and resist phishing and social engineering tricks.
- An assessor will verify that training materials cover these threats.
- (This requirement is a best practice until 31 March 2025.)
Requirement 12.6.3.2:
Requirement 12.6.3.2 in PCI DSS v4.0 involves:
- Training employees in clear rules for using work devices.
- An assessor will verify that training materials include these rules.
- (This requirement is a best practice until 31 March 2025.)
Requirement 12.9.2:
Requirement 12.9.2 in PCI DSS v4.0 for service providers involves:
- Supporting customer requests for information to meet Requirements 12.8.4 and 12.8.5.
- Providing PCI DSS compliance status information for any service performed on behalf of customers.
- Providing information about which PCI DSS requirements are the responsibility of the service provider and which are the responsibility of the customer, including any shared responsibilities.
- Verifying that processes are defined for supporting customers’ request for information to meet Requirements 12.8.4 and 12.8.5.
- (This requirement is effective immediately for all v4.0 assessments)
Requirement 12.10.4.1:
Requirement 12.10.4.1 in PCI DSS v4.0 involves:
- Analyzing your system’s threats and their severity.
- Setting a training schedule for your incident response team based on this risk analysis.
- An assessor will verify the risk analysis and training records.
- (This requirement is a best practice until 31 March 2025.)
Requirement 12.10.7:
Requirement 12.10.7 in PCI DSS v4.0 involves:
- Having a plan for handling cardholder data (PAN) found outside the secure environment.
- The plan includes action steps, checking for passwords, finding the leak, and fixing the problem.
- An assessor verifies the plan and its implementation.
- (This requirement is a best practice until 31 March 2025.)
Conclusion:
The transition from v3.2.1 to v4.0 in PCI DSS Requirement 12 highlights the evolving landscape of cybersecurity. The updated version emphasizes risk assessments, efficient policies, and proactive technology management, forming the backbone of an effective PCI DSS compliance program. These changes reflect a commitment to data protection, fostering customer trust, and standing out in a security-conscious market. Remember, maintaining PCI DSS compliance is a continuous process. Stay updated with future changes and continue to enhance your security stance.
Also Read: PCI DSS Requirement 11
Let us help you
Need help navigating PCI DSS v4.0? We have been active in the PCI DSS space since 2008 and even certify payment brand. Our PCI DSS services provide assurance on card security controls, with offerings for both product platform and backend services attestation.
We have a dedicated team of auditors and a separate team for consulting/advisory assignments to even help our esteemed clients to define processes and achieve compliance.
We have completed multiple PCI DSS 4.0 certifications too right from scoping to Readiness Assessment, Advisory and Final Certification.
We are vendor neutral and have a strict no-outsourcing policy. We can also assist you with the technical assessments needed for PCI DSS Compliance – Vulnerability Assessment, Penetration Testing, Network Segmentation Testing, Network Architecture Review, Firewall Assessment, Secure Configuration Assessment, Web and Mobile Application Security Assessment, and Secure Code Review.
