So, after a long journey, we’ve arrived at the twelfth and final requirement for PCI DSS 4.0. Last but certainly not least, this requirement emphasizes the need for creating, documenting, and implementing organization-wide security and compliance policies.
Why Is it so Important to Have Security Policies?
A security policy is a source of truth for your cybersecurity priorities. It is the official documentation of your organization’s controls, practices, and processes to combat security threats and maintain a realistic and effective security posture.
Without a clear and documented security policy, an organization sinks into ad hoc security implementation–that is, it’s a catch-as-catch-can approach where your technologies and expertise constantly respond to threats without an eye toward uniformity or prevention.
This was a reasonable but inefficient way to approach security in the past. However, in our modern digital landscape (which significantly applies to organizations handling sensitive data), ad hoc is not an option. And modern security regulations demonstrate this. PCI DSS 4.0 is no different.
At the heart of any security policy is the CIA triad. PCI DSS 4.0 defines this as the set of priorities that any organization that is developing their PCI-compliant policy
The IT security CIA triad is:
- Confidentiality: User data must remain private while stored and during transit. This includes obfuscating data with encryption and implementing procedures to avoid unauthorized disclosure of confidential information.
- Integrity: An IT system has sufficient controls to ensure that data is whole and unmodified. This includes protections against unauthorized tampering, recognition, and removal (or notification of) corrupted data.
- Availability: Data must remain accessible and usable by internal stakeholders without breaching confidentiality.
In PCI DSS 4.0, this triad refers specifically to IT systems containing, transmitting, or processing primary card numbers (PCN) or personally identifiable information (PII).
More specifically, PCI DSS 4.0 considers a solid policy to address a few specific criteria:
- Roles and Responsibilities: Responsibilities (and accountability) are paramount to an effective security policy. Such a policy should always describe primary and secondary organizational roles tied to compliance, cybersecurity technology, risk management, and administrative controls. The hierarchy of responsibilities tied to these positions should always be well-defined, with clear relationships with project ownership and what position reports to whom.
- Risk Appetite: Organizations should constantly assess risk, and as such, they should also have a logical definition of their risk appetite. Suppose an organization chooses to undergo specific types of audits or implement security controls that technically fit compliance without necessarily choosing more advanced controls. In that case, the risk associated with such decisions should be informed by a policy stating how much risk the company is willing to take.
- Framework Management: Organizations handling one or more compliance frameworks should have a policy of managing compliance (understanding requirements, tracking updates, interfacing with regulatory stakeholders, etc.).
- Data Lifecycle Management: Security policies should address the flow of data through the organization, from first creation to destruction, ensuring that all requirements are met along the way.
- Auditing and Reporting: Finally, policies should document audit, logging, and reporting requirements. This includes discussing how such data is collected, the types of information logged, and the responsibilities for incident or anomaly response based on any alerts.
What is the Twelfth Requirement of PCI DSS 4.0?
The twelfth requirement of PCI DSS 4.0 is focused almost exclusively on the obligation of regulated organizations with cardholder data environments (CDE) to maintain comprehensive security policies. To ensure that these policies address the needs of the industry, the PCI compliance board has created a series of requirements that outline effective policymaking.
12.1 – Comprehensive Information Security Policy
- Overall Information Security Policies: The organization must establish, maintain, publish, and disseminate their policy across their operations.
- Security Policy Management: This policy must be reviewed at least once every 12 months and updated based on recent business changes or risks to cardholder data.
- Roles and Responsibilities: The policy must define accurate roles and responsibilities and formally assign the position of the Chief Information Security Officer (CISO) to handle this policy.
12.2 – Defining and Implementing Acceptable Use Policies for End-User Technologies
- Acceptable Use Policy Implementation: The policy must define acceptable use policies, including those for providing authorization for users, specifying proper use of technology, and a list of products that are approved for use within the system.
12.3 – Identify, Evaluate, and Manage Risks to Cardholder Data Environments
- Flexibility and Risk Analysis: If a requirement calls for flexible, periodical performance, then the organization must have a supporting risk analysis in place (and documented) that includes the ID of protected assets and threats, how those risks and technologies inform the frequency of performance of the requirement, and a policy to review those risk assessments once every 12 months.
- Approaches to Risk Analysis: Risk analyses for each requirement under PCI DSS must include documentation and evidence, approval of that evidence by senior management, and a targeted analysis of these risks once every 12 months.
- Cryptography: The organization must document and review all cryptographic modules every 12 months. This review must include an inventory of all modules and suites, monitoring of industry trends around the effectiveness of those modules, and a documented strategy for updating cryptography based on changes to vulnerabilities.
- Hardware and Software Review: Hardware and software used in CDEs must be reviewed at least once every 12 months. This review must include documentation that these technologies are continually updated, that these technologies still contribute to PCI DSS compliance, that the company is aware of changes in the field and the viability of that technology, and the plans to remediate or replace outdated technology.
12.4 – Manage PCI Compliance
Note that this section applies exclusively to additional requirements for service providers.
- Service Provider Accountability: Service providers must conduct a review once every three months to confirm they are following the security policy. Outside parties must conduct these reviews, including daily logs, configuration, security alerts, and change management reviews.
- Service Provider Review Documentation: Providers must produce the results of their reviews, documented remediation actions, and sign-off from PCI DSS compliance personnel (most likely a CISO).
12.5 – Document and Validate PCI DSS Scope
- Inventories: Organizations must inventory technologies that fall within the scope of PCI DSS.
- Scope Documentation: Organizations document the scope of their PCI DSS compliance, including data flows for payment information, data flow diagrams, inventories of CDE storage and processing systems, connected and networked technology, and connected third-party technologies.
12.6 – Implement Security Awareness Education
- Awareness Program Implementation: The organization must implement a formal security awareness program for all personnel. This program must be updated at least once every 12 months or any time policy and security are updated.
- Training Frequency: Personnel should be trained under this program when hired and at least once every 12 months. There must be more than one form of training communication, and personnel must acknowledge their training every 12 months.
- Types of Threat and Training: Training should include awareness of social engineering and phishing attacks and acceptable end-user behavior.
12.7 – Personnel are Screened to Reduce Insider Threats
- Screening: Personnel with potential access to CDEs must be screened (limited by local law).
12.8 – Third-Party Service Provider Risk is Managed
- Access Inventories: All access accounts that could threaten data security that third-party providers hold must be inventoried.
- Written Agreements: All agreements with third-party providers must be in writing, maintained, and include acknowledgments from the vendor that they are responsible for their security and compliance when handling cardholder data or interacting with a CDE.
- Due Diligence and Monitoring: An organization must document an established process for performing due diligence before entering into a third-party agreement. This should include monitoring the vendor’s compliance status at least once every 12 months.
12.9 – Third-Party Service Providers Support PCI DSS Compliance
Note that this section applies exclusively to additional requirements for service providers.
- Responsibilities: A third-party vendor must provide a written acknowledgment that they are responsible for security.
- Requests for Information: Third parties must provide their customers with information on PCI DSS compliance (including the requirements they are addressing) when asked.
12.10 – Security Incidents Are Responded to Immediately
- Incident Response Plan: Incident response plans must include roles and responsibilities for managing and enacting this plan. This also includes a detailed outline of procedures, business recovery, backup processes, analysis of legal requirements, critical system coverage, and the relevant stakeholders included in any incident response.
- Updates: Incident response plans must be updated at least once every 12 months and include reviews, updates, and component test results.
- Personnel: There must be 24/7 coverage to maintain incidents and responses. Any personnel responsible for response must be trained regularly.
- Monitoring and Responding: Response plans must include monitoring and alerts that apply to intrusion detection and prevention, network security, change detection, change and tamper detection, and detection of unauthorized wireless access.
- Procedures and Initiation: When cardholder data is discovered outside of secure areas, the organization should have policies in place to determine what to do to secure the data and the system, identify if there was unauthorized disclosure of that information, how the information ended up where it did, and remediate data leaks or process gaps.
Prepare for PCI DSS 4.0 with Lazarus Alliance
As we dig into the requirements of PCI DSS, you will see the increasing complexity and interoperability of the different technologies, policies, and practices you’ll need to deploy to receive PCI verification and maintain compliance. These practices aren’t just to complete a checklist. However–they are tried-and-true security practices that will help support your security efforts ten years from now.
Are You Thinking Ahead for PCI DSS 4.0?
Call Lazarus Alliance at 1-888-896-7580 or fill in this form.
[wpforms id=”137574″]