PCI DSS v4.0.1
Payment Card Industry Data Security Standard
PCI DSS is copyrighted by the PCI Security Standards Council. This tool provides requirement text for reference purposes. For official documentation and assessment guidance, visit the PCI SSC Document Library.
204 All
1 — Install and Maintain Network Security Controls (19 requirements)
1.1.1All security policies and operational procedures that are identified in Requirement 1 are: Documented.
1.1.2Roles and responsibilities for performing activities in Requirement 1 are documented, assigned, and understood.
1.2.1Configuration standards for NSC rulesets are: Defined.
1.2.2All changes to network connections and to configurations of NSCs are approved and managed in accordance with the change control process defined at Requirement 6.
1.2.3An accurate network diagram(s) is maintained that shows all connections between the CDE and other networks, including any wireless networks.
1.2.4An accurate data-flow diagram(s) is maintained that meets the following: Shows all account data flows across systems and networks.
1.2.5All services, protocols and ports allowed are identified, approved, and have a defined business need.
1.2.6Security features are defined and implemented for all services, protocols, and ports that are in use and considered to be insecure, such that the risk is mitigated.
1.2.7Configurations of NSCs are reviewed at least once every six months to confirm they are relevant and effective.
1.2.8Configuration files for NSCs are: Secured from unauthorized access.
1.3.1Inbound traffic to the CDE is restricted as follows: To only traffic that is necessary, All other traffic is specifically denied.
1.3.2Outbound traffic from the CDE is restricted as follows: To only traffic that is necessary.
1.3.3NSCs are installed between all wireless networks and the CDE, regardless of whether the wireless network is a CDE, such that: All wireless traffic from wireless networks into the CDE is denied by default.
1.4.1NSCs are implemented between trusted and untrusted networks.
1.4.2Inbound traffic from untrusted networks to trusted networks is restricted to: Communications with system components that are authorized to provide publicly accessible services, protocols, and ports.
1.4.3Anti-spoofing measures are implemented to detect and block forged source IP addresses from entering the trusted network.
1.4.4System components that store cardholder data are not directly accessible from untrusted networks.
1.4.5The disclosure of internal IP addresses and routing information is limited to only authorized parties.
1.5.1Security controls are implemented on any computing devices, including company- and employee-owned devices, that connect to both untrusted networks (including the Internet) and the CDE as follows.
2 — Apply Secure Configurations to All System Components (11 requirements)
2.1.1All security policies and operational procedures that are identified in Requirement 2 are: Documented.
2.1.2Roles and responsibilities for performing activities in Requirement 2 are documented, assigned, and understood.
2.2.1Configuration standards are developed, implemented, and maintained to: Cover all system components.
2.2.2Vendor default accounts are managed as follows: If the vendor default account(s) will be used, the default password is changed per Requirement 8.
2.2.3Primary functions requiring different security levels are managed as follows: Only one primary function exists on a system component, OR Primary functions with differing security levels that exist on the same system component are isolated from each other, OR Primary functions with differing security levels on the same system component are all secured to the level required by the function with the highest security need.
2.2.4Only necessary services, protocols, daemons, and functions are enabled, and all unnecessary functionality is removed or disabled.
2.2.5If any insecure services, protocols, or daemons are present: Business justification is documented.
2.2.6System security parameters are configured to prevent misuse.
2.2.7All non-console administrative access is encrypted using strong cryptography.
2.3.1For wireless environments connected to the CDE or transmitting account data, all wireless vendor defaults are changed at installation or are confirmed to be secure, including but not limited to: Default wireless encryption keys.
2.3.2For wireless environments connected to the CDE or transmitting account data, wireless encryption keys are changed as follows: Whenever personnel with knowledge of the key leave the company or the role for which the knowledge was necessary.
3 — Protect Stored Account Data (19 requirements)
3.1.1All security policies and operational procedures that are identified in Requirement 3 are: Documented.
3.1.2Roles and responsibilities for performing activities in Requirement 3 are documented, assigned, and understood.
3.2.1Account data storage is kept to a minimum through implementation of data retention and disposal policies, procedures, and processes that include at least the following: Coverage for all locations of stored account data.
3.3.1SAD is not stored after authorization, even if encrypted.
3.3.2SAD that is stored electronically prior to completion of authorization is encrypted using strong cryptography.
3.3.3Additional requirement for issuers and companies that support issuing services and store sensitive authentication data: Any storage of sensitive authentication data is: Limited to that which is needed for a legitimate issuing business need and is secured.
3.4.1PAN is masked when displayed (the BIN and last four digits are the maximum number of digits to be displayed), such that only personnel with a legitimate business need can see more than the BIN and last four digits of the PAN.
3.4.2When using remote-access technologies, technical controls prevent copy and/or relocation of PAN for all personnel, except for those with documented, explicit authorization and a legitimate, defined business need.
3.5.1PAN is rendered unreadable anywhere it is stored by using any of the following approaches: One-way hashes based on strong cryptography of the entire PAN.
3.6.1Procedures are defined and implemented to protect cryptographic keys used to protect stored account data against disclosure and misuse that include: Access to keys is restricted to the fewest number of custodians necessary.
3.7.1Key-management policies and procedures are implemented to include generation of strong cryptographic keys used to protect stored account data.
3.7.2Key-management policies and procedures are implemented to include secure distribution of cryptographic keys used to protect stored account data.
3.7.3Key-management policies and procedures are implemented to include secure storage of cryptographic keys used to protect stored account data.
3.7.4Key management policies and procedures are implemented for cryptographic key changes for keys that have reached the end of their cryptoperiod, as defined by the associated application vendor or key owner, and based on industry best practices and guidelines, including the following: A defined cryptoperiod for each key type in use.
3.7.5Key management policies procedures are implemented to include the retirement, replacement, or destruction of keys used to protect stored account data, as deemed necessary when: The key has reached the end of its defined cryptoperiod.
3.7.6Where manual cleartext cryptographic key-management operations are performed by personnel, key-management policies and procedures are implemented including managing these operations using split knowledge and dual control.
3.7.7Key management policies and procedures are implemented to include the prevention of unauthorized substitution of cryptographic keys.
3.7.8Key management policies and procedures are implemented to include that cryptographic key custodians formally acknowledge (in writing or electronically) that they understand and accept their key-custodian responsibilities.
3.7.9Additional requirement for service providers only: Where a service provider shares cryptographic keys with its customers for transmission or storage of account data, guidance on secure transmission, storage and updating of such keys is documented and distributed to the service provider's customers.
4 — Protect Cardholder Data with Strong Cryptography During Transmission (4 requirements)
4.1.1All security policies and operational procedures that are identified in Requirement 4 are: Documented. Kept up to date. In use. Known to all affected parties.
4.1.2Roles and responsibilities for performing activities in Requirement 4 are documented, assigned, and understood.
4.2.1Strong cryptography and security protocols are implemented as follows to safeguard PAN during transmission over open, public networks: Only trusted keys and certificates are accepted.
4.2.2PAN is secured with strong cryptography whenever it is sent via end-user messaging technologies.
5 — Protect All Systems and Networks from Malicious Software (11 requirements)
5.1.1All security policies and operational procedures that are identified in Requirement 5 are: Documented. Kept up to date. In use. Known to all affected parties.
5.1.2Roles and responsibilities for performing activities in Requirement 5 are documented, assigned, and understood.
5.2.1An anti-malware solution(s) is deployed on all system components, except for those system components identified in periodic evaluations per Requirement 5.
5.2.2The deployed anti-malware solution(s): Detects all known types of malware.
5.2.3Any system components that are not at risk for malware are evaluated periodically to include the following: A documented list of all system components not at risk for malware.
5.3.1The anti-malware solution(s) is kept current via automatic updates.
5.3.2The anti-malware solution(s): Performs periodic scans and active or real-time scans OR Performs continuous behavioral analysis of systems or processes.
5.3.3For removable electronic media, the anti-malware solution(s): Performs automatic scans of when the media is inserted, connected, or logically mounted, OR Performs continuous behavioral analysis of systems or processes when the media is inserted, connected, or logically mounted.
5.3.4Audit logs for the anti-malware solution(s) are enabled and retained in accordance with Requirement 10.
5.3.5Anti-malware mechanisms cannot be disabled or altered by users, unless specifically documented, and authorized by management on a case-by-case basis for a limited time period.
5.4.1Processes and automated mechanisms are in place to detect and protect personnel against phishing attacks.
6 — Develop and Maintain Secure Systems and Software (18 requirements)
6.1.1All security policies and operational procedures that are identified in Requirement 6 are: Documented.
6.1.2Roles and responsibilities for performing activities in Requirement 6 are documented, assigned, and understood.
6.2.1Bespoke and custom software are developed securely, as follows: Based on industry standards and/or best practices for secure development.
6.2.2Software development personnel working on bespoke and custom software are trained at least once every 12 months as follows: On software security relevant to their job function and development languages.
6.2.3Bespoke and custom software is reviewed prior to being released into production or to customers, to identify and correct potential coding vulnerabilities, as follows: Code reviews ensure code is developed according to secure coding guidelines.
6.2.4Software engineering techniques or other methods are defined and in use by software development personnel to prevent or mitigate common software attacks and related vulnerabilities for bespoke and custom software, including but not limited to the following: Injection attacks, including SQL, LDAP, XPath, or other command, parameter, object, fault, or injection-type flaws.
6.3.1Security vulnerabilities are identified and managed as follows: New security vulnerabilities are identified using industry-recognized sources for security vulnerability information, including alerts from international and national computer emergency response teams (CERTs).
6.3.2An inventory of bespoke and custom software, and third-party software components incorporated into bespoke and custom software is maintained to facilitate vulnerability and patch management.
6.3.3All system components are protected from known vulnerabilities by installing applicable security patches/updates as follows: Patches/updates for critical vulnerabilities (identified according to the risk ranking process at Requirement 6.
6.4.1For public-facing web applications, new threats and vulnerabilities are addressed on an ongoing basis and these applications are protected against known attacks as follows: Reviewing public-facing web applications via manual or automated application vulnerability security assessment tools or methods as follows: At least once every 12 months and after significant changes.
6.4.2For public-facing web applications, an automated technical solution is deployed that continually detects and prevents web-based attacks, with at least the following: Is installed in front of public-facing web applications and is configured to detect and prevent web-based attacks.
6.4.3All payment page scripts that are loaded and executed in the consumer’s browser are managed as follows: A method is implemented to confirm that each script is authorized.
6.5.1Changes to all system components in the production environment are made according to established procedures that include: Reason for, and description of, the change.
6.5.2Upon completion of a significant change, all applicable PCI DSS requirements are confirmed to be in place on all new or changed systems and networks, and documentation is updated as applicable.
6.5.3Pre-production environments are separated from production environments and the separation is enforced with access controls.
6.5.4Roles and functions are separated between production and pre-production environments to provide accountability such that only reviewed and approved changes are deployed.
6.5.5Live PANs are not used in pre-production environments, except where those environments are included in the CDE and protected in accordance with all applicable PCI DSS requirements.
6.5.6Test data and test accounts are removed from system components before the system goes into production.
7 — Restrict Access to System Components and Cardholder Data by Business Need to Know (11 requirements)
7.1.1All security policies and operational procedures that are identified in Requirement 7 are: Documented, Kept up to date In use Known to all affected parties.
7.1.2Roles and responsibilities for performing activities in Requirement 7 are documented, assigned, and understood.
7.2.1An access control model is defined and includes granting access as follows: Appropriate access depending on the entity’s business and access needs.
7.2.2Access is assigned to users, including privileged users, based on: Job classification and function.
7.2.3Required privileges are approved by authorized personnel.
7.2.4All user accounts and related access privileges, including third-party/vendor accounts, are reviewed as follows: At least once every six months To ensure user accounts and access remain appropriate based on job function.
7.2.5All application and system accounts and related access privileges are assigned and managed as follows: Based on the least privileges necessary for the operability of the system or application.
7.2.6All user access to query repositories of stored cardholder data is restricted as follows: Via applications or other programmatic methods, with access and allowed actions based on user roles and least privileges.
7.3.1An access control system(s) is in place that restricts access based on a user’s need to know and covers all system components.
7.3.2The access control system(s) is configured to enforce privileges assigned to individuals, applications, and systems based on job classification and function.
7.3.3The access control system(s) is set to “deny all” by default.
8 — Identify Users and Authenticate Access to System Components (28 requirements)
8.1.1All security policies and operational procedures that are identified in Requirement 8 are: Documented.
8.1.2Roles and responsibilities for performing activities in Requirement 8 are documented, assigned, and understood.
8.2.1All users are assigned a unique ID before access to system components or cardholder data is allowed.
8.2.2Group, shared, or generic IDs, or other shared authentication credentials are only used when necessary on an exception basis, and are managed as follows: ID use is prevented unless needed for an exceptional circumstance.
8.2.3Additional requirement for service providers only: Service providers with remote access to customer premises use unique authentication factors for each customer premises.
8.2.4Addition, deletion, and modification of user IDs, authentication factors, and other identifier objects are managed as follows: Authorized with the appropriate approval.
8.2.5Access for terminated users is immediately revoked
8.2.6Inactive user accounts are removed or disabled within 90 days of inactivity.
8.2.7Accounts used by third parties to access, support, or maintain system components via remote access are managed as follows: Enabled only during the time period needed and disabled when not in use.
8.2.8If a user session has been idle for more than 15 minutes, the user is required to re-authenticate to re-activate the terminal or session.
8.3.1All user access to system components for users and administrators is authenticated via at least one of the following authentication factors: Something you know, such as a password or passphrase.
8.3.2Strong cryptography is used to render all authentication factors unreadable during transmission and storage on all system components.
8.3.3User identity is verified before modifying any authentication factor.
8.3.4Invalid authentication attempts are limited by: Locking out the user ID after not more than 10 attempts.
8.3.5If passwords/passphrases are used as authentication factors to meet Requirement 8.
8.3.6If passwords/passphrases are used as authentication factors to meet Requirement 8.
8.3.7Individuals are not allowed to submit a new password/passphrase that is the same as any of the last four passwords/passphrases used.
8.3.8Authentication policies and procedures are documented and communicated to all users including: Guidance on selecting strong authentication factors.
8.3.9If passwords/passphrases are used as the only authentication factor for user access (i.
8.3.10Additional requirement for service providers only: If passwords/passphrases are used as the only authentication factor for customer user access to cardholder data (i.
8.3.11Where authentication factors such as physical or logical security tokens, smart cards, or certificates are used: Factors are assigned to an individual user and not shared among multiple users.
8.4.1MFA is implemented for all non-console access into the CDE for personnel with administrative access.
8.4.2MFA is implemented for all non-console access into the CDE.
8.4.3MFA is implemented for all remote network access originating from outside the entity’s network that could access or impact the CDE.
8.5.1MFA systems are implemented as follows: The MFA system is not susceptible to replay attacks.
8.6.1If accounts used by systems or applications can be used for interactive login, they are managed as follows: Interactive use is prevented unless needed for an exceptional circumstance.
8.6.2Passwords/passphrases for any application and system accounts that can be used for interactive login are not hard coded in scripts, configuration/property files, or bespoke and custom source code.
8.6.3Passwords/passphrases for any application and system accounts are protected against misuse as follows: Passwords/passphrases are changed periodically (at the frequency defined in the entity’s targeted risk analysis, which is performed according to all elements specified in Requirement 12.
9 — Restrict Physical Access to Cardholder Data (18 requirements)
9.1.1All security policies and operational procedures that are identified in Requirement 9 are: Documented.
9.1.2Roles and responsibilities for performing activities in Requirement 9 are documented, assigned, and understood.
9.2.1Appropriate facility entry controls are in place to restrict physical access to systems in the CDE.
9.2.2Physical and/or logical controls are implemented to restrict use of publicly accessible network jacks within the facility.
9.2.3Physical access to wireless access points, gateways, networking/communications hardware, and telecommunication lines within the facility is restricted.
9.2.4Access to consoles in sensitive areas is restricted via locking when not in use.
9.3.1Procedures are implemented for authorizing and managing physical access of personnel to the CDE, including: Identifying personnel.
9.3.2Procedures are implemented for authorizing and managing visitor access to the CDE, including: Visitors are authorized before entering.
9.3.3Visitor badges or identification are surrendered or deactivated before visitors leave the facility or at the date of expiration.
9.3.4Visitor logs are used to maintain a physical record of visitor activity both within the facility and within sensitive areas, including: The visitor’s name and the organization represented.
9.4.1All media with cardholder data is physically secured.
9.4.2All media with cardholder data is classified in accordance with the sensitivity of the data.
9.4.3Media with cardholder data sent outside the facility is secured as follows: Media sent outside the facility is logged.
9.4.4Management approves all media with cardholder data that is moved outside the facility (including when media is distributed to individuals).
9.4.5Inventory logs of all electronic media with cardholder data are maintained.
9.4.6Hard-copy materials with cardholder data are destroyed when no longer needed for business or legal reasons, as follows: Materials are cross-cut shredded, incinerated, or pulped so that cardholder data cannot be reconstructed.
9.4.7Electronic media with cardholder data is destroyed when no longer needed for business or legal reasons via one of the following: The electronic media is destroyed.
9.5.1POI devices that capture payment card data via direct physical interaction with the payment card form factor are protected from tampering and unauthorized substitution, including the following: Maintaining a list of POI devices.
10 — Log and Monitor All Access to System Components and Cardholder Data (18 requirements)
10.1.1All security policies and operational procedures that are identified in Requirement 10 are: Documented.
10.1.2Roles and responsibilities for performing activities in Requirement 10 are documented, assigned, and understood.
10.2.1Audit logs are enabled and active for all system components and cardholder data.
10.2.2Audit logs record the following details for each auditable event: User identification.
10.3.1Read access to audit logs files is limited to those with a job-related need.
10.3.2Audit log files are protected to prevent modifications by individuals.
10.3.3Audit log files, including those for external-facing technologies, are promptly backed up to a secure, central, internal log server(s) or other media that is difficult to modify.
10.3.4File integrity monitoring or change-detection mechanisms is used on audit logs to ensure that existing log data cannot be changed without generating alerts.
10.4.1The following audit logs are reviewed at least once daily: All security events.
10.4.2Logs of all other system components (those not specified in Requirement 10.
10.4.3Exceptions and anomalies identified during the review process are addressed.
10.5.1Retain audit log history for at least 12 months, with at least the most recent three months immediately available for analysis.
10.6.1System clocks and time are synchronized using time-synchronization technology.
10.6.2Systems are configured to the correct and consistent time as follows: One or more designated time servers are in use.
10.6.3Time synchronization settings and data are protected as follows: Access to time data is restricted to only personnel with a business need.
10.7.1Additional requirement for service providers only: Failures of critical security control systems are detected, alerted, and addressed promptly, including but not limited to failure of the following critical security control systems: Network security controls IDS/IPS FIM Anti-malware solutions Physical access controls Logical access controls Audit logging mechanisms Segmentation controls (if used) Applicability Notes This requirement applies only when the entity being assessed is a service provider.
10.7.2Failures of critical security control systems are detected, alerted, and addressed promptly, including but not limited to failure of the following critical security control systems: Network security controls.
10.7.3Failures of any critical security control systems are responded to promptly, including but not limited to: Restoring security functions.
11 — Test Security of Systems and Networks Regularly (15 requirements)
11.1.1All security policies and operational procedures that are identified in Requirement 11 are: Documented.
11.1.2Roles and responsibilities for performing activities in Requirement 11 are documented, assigned, and understood.
11.2.1Authorized and unauthorized wireless access points are managed as follows: The presence of wireless (Wi-Fi) access points is tested for, All authorized and unauthorized wireless access points are detected and identified, Testing, detection, and identification occurs at least once every three months.
11.3.1Internal vulnerability scans are performed as follows: At least once every three months.
11.3.2External vulnerability scans are performed as follows: At least once every three months.
11.4.1A penetration testing methodology is defined, documented, and implemented by the entity, and includes: Industry-accepted penetration testing approaches.
11.4.2Internal penetration testing is performed: Per the entity’s defined methodology At least once every 12 months After any significant infrastructure or application upgrade or change By a qualified internal resource or qualified external third-party Organizational independence of the tester exists (not required to be a QSA or ASV).
11.4.3External penetration testing is performed: Per the entity’s defined methodology At least once every 12 months After any significant infrastructure or application upgrade or change By a qualified internal resource or qualified external third party Organizational independence of the tester exists (not required to be a QSA or ASV).
11.4.4Exploitable vulnerabilities and security weaknesses found during penetration testing are corrected as follows: In accordance with the entity’s assessment of the risk posed by the security issue as defined in Require ment 6.
11.4.5If segmentation is used to isolate the CDE from other networks, penetration tests are performed on segmentation controls as follows: At least once every 12 months and after any changes to segmentation controls/methods Covering all segmentation controls/methods in use.
11.4.6Additional requirement for service providers only: If segmentation is used to isolate the CDE from other networks, penetration tests are performed on segmentation controls as follows: At least once every six months and after any changes to segmentation controls/methods.
11.4.7Additional requirement for third-party hosted/cloud service providers only: Third-party hosted/cloud service providers support to their customers for external penetration testing per Requirement 11.
11.5.1Intrusion-detection and/or intrusion-prevention techniques are used to detect and/or prevent intrusions into the network as follows: All traffic is monitored at the perimeter of the CDE.
11.5.2A change-detection mechanism (for example, file integrity monitoring tools) is deployed as follows: To alert personnel to unauthorized modification (including changes, additions, and deletions) of critical files To perform critical file comparisons at least once weekly.
11.6.1A change- and tamper-detection mechanism is deployed as follows: To alert personnel to unauthorized modification (including indicators of compromise, changes, additions, and deletions) to the security-impacting HTTP headers and the script contents of payment pages as received by the consumer browser.
12 — Support information security with organizational policies and programs (32 requirements)
12.1.1An overall information security policy is: Established.
12.1.2The information security policy is: Reviewed at least once every 12 months.
12.1.3The security policy clearly defines information security roles and responsibilities for all personnel, and all personnel are aware and acknowledge their information security responsibilities.
12.1.4Responsibility for information security is formally assigned to a Chief Information Security Officer or other information security knowledgeable member of executive management.
12.2.1Acceptable use policies for end-user technologies are documented and implemented, including: Explicit approval by authorized parties.
12.3.1For each PCI DSS requirement that specifies completion of a targeted risk analysis, the analysis is documented and includes: Identification of the assets being protected.
12.3.2A targeted risk analysis is performed for each PCI DSS requirement that the entity meets with the customized approach, to include: Documented evidence detailing each element specified in Appendix B: Guidance and Instructions for Using Customized Approach (including, at a minimum, a controls matrix and risk analysis).
12.3.3Cryptographic cipher suites and protocols in use are documented and reviewed at least once every 12 months, including at least the following: An up-to-date inventory of all cryptographic cipher suites and protocols in use, including purpose and where used.
12.3.4Hardware and software technologies in use are reviewed at least once every 12 months, including at least the following: Analysis that the technologies continue to receive security fixes from vendors promptly.
12.4.1Additional requirement for service providers only: Responsibility is established by executive management for the protection of cardholder data and a PCI DSS compliance program to include: Overall accountability for maintaining PCI DSS compliance.
12.4.2Additional requirement for service providers only: Reviews are performed at least once every three months to confirm personnel are performing their tasks in accordance with all security policies and all operational procedures.
12.5.1An inventory of system components that are in scope for PCI DSS, including a description of function/use, is maintained and kept current.
12.5.2PCI DSS scope is documented and confirmed by the entity at least once every 12 months and upon significant change to the in-scope environment.
12.5.3Additional requirement for service providers only: Significant changes to organizational structure result in a documented (internal) review of the impact to PCI DSS scope and applicability of controls, with results communicated to executive management.
12.6.1A formal security awareness program is implemented to make all personnel aware of the entity’s information security policy and procedures and their role in protecting the cardholder data.
12.6.2The security awareness program is: Reviewed at least once every 12 months, and Updated as needed to address any new threats and vulnerabilities that may impact the security of the entity’s cardholder data and/or sensitive authentication data, or the information provided to personnel about their role in protecting cardholder data.
12.6.3Personnel receive security awareness training as follows: Upon hire and at least once every 12 months.
12.7.1Potential personnel who will have access to the CDE are screened, within the constraints of local laws, prior to hire to minimize the risk of attacks from internal sources.
12.8.1A list of all third-party service providers (TPSPs) with which account data is shared or that could affect the security of account data is maintained, including a description for each of the services provided.
12.8.2Written agreements with TPSPs are maintained as follows: Written agreements are maintained with all TPSPs with which account data is shared or that could affect the security of the CDE.
12.8.3An established process is implemented for engaging TPSPs, including proper due diligence prior to engagement.
12.8.4A program is implemented to monitor TPSPs’ PCI DSS compliance status at least once every 12 months.
12.8.5Information is maintained about which PCI DSS requirements are managed by each TPSP, which are managed by the entity, and any that are shared between the TPSP and the entity.
12.9.1Additional requirement for service providers only: TPSPs provide written agreements to customers that include acknowledgments that TPSPs are responsible for the security of account data the TPSP possesses or otherwise stores, processes, or transmits on behalf of the customer, or to the extent that the TPSP could impact the security of the customer’s cardholder data and/or sensitive authentication data.
12.9.2Additional requirement for service providers only: TPSPs support their customers’ requests for information to meet Requirements 12.
12.10.1An incident response plan exists and is ready to be activated in the event of a suspected or confirmed security incident.
12.10.2At least once every 12 months, the security incident response plan is: Reviewed and the content is updated as needed.
12.10.3Specific personnel are designated to be available on a 24/7 basis to respond to suspected or confirmed security incidents.
12.10.4Personnel responsible for responding to suspected and confirmed security incidents are appropriately and periodically trained on their incident response responsibilities.
12.10.5The security incident response plan includes monitoring and responding to alerts from security monitoring systems, including but not limited to: Intrusion-detection and intrusion-prevention systems.
12.10.6The security incident response plan is modified and evolved according to lessons learned and to incorporate industry developments.
12.10.7Incident response procedures are in place, to be initiated upon the detection of stored PAN anywhere it is not expected, and include: Determining what to do if PAN is discovered outside the CDE, including its retrieval, secure deletion, and/or migration into the currently defined CDE, as applicable.