diff --git a/apps/console/public/data/frameworks/FERPA.json b/apps/console/public/data/frameworks/FERPA.json new file mode 100644 index 000000000..3c1cbaf35 --- /dev/null +++ b/apps/console/public/data/frameworks/FERPA.json @@ -0,0 +1,126 @@ +{ + "id": "FERPA", + "name": "FERPA", + "logo": { + "light": "", + "dark": "" + }, + "controls":[ + { + "id": "1.1", + "description": "The provider qualifies as a 'school official' under the school official exception only if it meets all three conditions simultaneously: (1) it performs an institutional service or function for which the educational institution would otherwise use its own employees; (2) it is under the direct control of the institution with respect to the use and maintenance of education records; and (3) it is subject to the redisclosure limitations of § 99.33(a). All three conditions must be satisfied concurrently — none is optional. (34 CFR § 99.31(a)(1)(i)(B))" + }, + { + "id": "1.2", + "description": "The provider must be formally designated as a school official with legitimate educational interest in the institution's annual FERPA notification to parents and eligible students. This designation must precede any disclosure of PII from education records. The provider cannot operate as a school official unless the institution has fulfilled this notification requirement and the provider's function is included within the scope of legitimate educational interest described in that notice. (34 CFR § 99.31(a)(1)(i)(A), § 99.7(a)(3)(iii); PTAC Vendor Guidance, 2015)" + }, + { + "id": "1.3", + "description": "The provider must maintain a written agreement (contract or equivalent legal instrument) with the institution that establishes and documents the direct control requirement. The agreement must specify: the authorized purposes for which PII may be used; prohibitions on unauthorized use and redisclosure; data security and confidentiality obligations; and data return or destruction provisions upon contract termination. In the absence of a traditional contract, a Click-Wrap Terms of Service accepted by the institution may fulfill this requirement only if it contains all legally necessary provisions. (34 CFR § 99.31(a)(1)(i)(B); PTAC Online Educational Services guidance, 2014)" + }, + { + "id": "1.4", + "description": "The institution retains responsibility for compliance with FERPA at all times, even when PII from education records is disclosed to the provider under the school official exception. The institution must be able to demonstrate that it exercises direct control over the provider's use and maintenance of PII. The provider must cooperate fully with any institutional audit, inquiry, or oversight action necessary to establish this direct control. (34 CFR § 99.31(a)(1)(i)(B)(*2*); PTAC Vendor FAQ, 2015)" + }, + { + "id": "2.1", + "description": "The provider may only access, collect, process, or use the minimum amount of PII from education records strictly necessary to perform the contracted institutional function. Collection of PII beyond what is required for the specified purpose constitutes an unauthorized use of education records. This data minimization obligation applies to all forms of student data, including metadata, transactional data, and contextual data generated through student interaction with the provider's service. (34 CFR § 99.31(a)(1)(i)(B)(*1*); PTAC TOS Model, provision 5, 2016)" + }, + { + "id": "2.2", + "description": "The provider must treat as PII all information that constitutes 'personally identifiable information' under FERPA, which includes: (a) direct identifiers such as student name, student ID number, social security number, and biometric records; (b) indirect identifiers such as date of birth, place of birth, mother's maiden name; and (c) any other information that, alone or in combination with other reasonably available information, would allow a reasonable person in the school community to identify the student. Metadata linked to an identifiable student is also PII. Only data from which all direct and indirect identifiers have been removed using a documented de-identification methodology constitutes de-identified data not subject to FERPA restrictions. (34 CFR § 99.3 definition of 'personally identifiable information'; PTAC Online Educational Services guidance, 2014)" + }, + { + "id": "2.3", + "description": "The provider's contractual definition of 'data' or 'student information' subject to protection must encompass the full scope of FERPA-protected PII, including PII provided directly by the institution, PII generated by student interaction with the service, and metadata that could be linked to an identifiable student. Definitions that restrict protection to only information 'knowingly provided' or only direct identifiers are insufficient and create compliance gaps. (34 CFR § 99.3; PTAC TOS Model, provision 1, 2016)" + }, + { + "id": "3.1", + "description": "The provider must implement and maintain administrative, physical, and technical safeguards appropriate to the sensitivity of the PII held, designed to protect education records against unauthorized access, disclosure, use, modification, or destruction. The provider must conduct periodic risk assessments to identify and remediate security vulnerabilities in a timely manner. Evidence of these security controls must be available to the institution upon request. (34 CFR § 99.31(a)(1)(i)(B)(*2*) direct control requirement; PTAC TOS Model, provision 12, 2016)" + }, + { + "id": "3.2", + "description": "The provider must maintain a written incident response plan covering security breaches involving PII from education records. The plan must include: procedures for detecting and containing a breach; notification timelines and procedures for informing the institution without undue delay upon discovery of an actual or suspected breach; a description of the breach and affected data; and remediation steps. The provider must share this plan with the institution upon request. Breach notification obligations to students and parents are the institution's responsibility and must be supported by the provider. (34 CFR § 99.31(a)(1)(i)(B)(*2*); PTAC TOS Model, provision 12, 2016; PTAC Data Breach Response Checklist)" + }, + { + "id": "3.3", + "description": "The provider must restrict internal access to PII from education records on a need-to-know basis. Only personnel who require access to PII to perform their function under the contract may access such records. The provider must implement access controls and authentication mechanisms to enforce this restriction and must maintain records of which personnel have accessed education records. (34 CFR § 99.31(a)(1)(i)(B)(*2*); 34 CFR § 99.31(c) authentication requirement)" + }, + { + "id": "3.4", + "description": "The provider must notify the institution of any planned changes to its terms of service, privacy policy, or data processing practices that would affect the use or protection of PII from education records before implementing such changes. Any material modification to data use, security controls, or subprocessor arrangements requires prior notice to and consent from the institution. Unilateral amendments without notice undermine the institution's ability to demonstrate direct control and constitute a FERPA compliance risk. (34 CFR § 99.31(a)(1)(i)(B)(*2*); PTAC TOS Model, provision 4, 2016)" + }, + { + "id": "4.1", + "description": "PII from education records disclosed to the provider under the school official exception may only be used for the specific authorized purpose for which it was disclosed, as defined in the written agreement with the institution. The provider is strictly prohibited from using PII from education records for any other purpose, including but not limited to: marketing or advertising directed to students or their parents; targeted advertising; selling or licensing student data to third parties; profiling students for commercial purposes; or improving products or services unrelated to the contracted function. These prohibitions apply to the provider's officers, employees, and agents. (34 CFR § 99.33(a)(2); 34 CFR § 99.31(a)(1)(i)(B)(*3*); PTAC Online Educational Services guidance, 2014)" + }, + { + "id": "4.2", + "description": "The provider must not scan or mine PII from education records or student-generated content for the purposes of advertising, marketing, or building commercial profiles of students or their parents. Data mining or content scanning is permissible only for purposes expressly authorized in the agreement, such as spam or malware detection, service improvement within the contracted function, or personalization of the educational service. The written agreement must explicitly address permissible and impermissible uses of student data and metadata. (34 CFR § 99.33(a)(2); PTAC TOS Model, provision 7, 2016)" + }, + { + "id": "4.3", + "description": "Where the provider uses AI, machine learning, or automated processing on student data, all such processing must be limited to the authorized purpose defined in the agreement. AI systems used to process student PII must be configured to prevent training on FERPA-protected data for purposes outside the contracted function. Zero data retention policies with AI subprocessors must be documented and verified. The provider must disclose to the institution any AI subprocessors that process student PII and ensure those subprocessors are bound by the same use restrictions. (34 CFR § 99.31(a)(1)(i)(B)(*1*) and (*3*); § 99.33(a); PTAC TOS Model, provision 8, 2016)" + }, + { + "id": "5.1", + "description": "The provider must make PII from education records accessible to the institution within a timeframe that allows the institution to fulfill its obligation under FERPA to respond to parental (or eligible student) access requests within 45 days of receipt of the request, or within any shorter timeframe required by applicable state law. The provider must maintain records in a manner that enables efficient retrieval and transmission to the institution upon request. (34 CFR § 99.10(b); PTAC Online Educational Services guidance, 2014, p. 4; PTAC TOS Model, provision 11, 2016)" + }, + { + "id": "5.2", + "description": "The provider must maintain a written incident response plan and must notify the institution promptly upon discovering any actual or suspected unauthorized disclosure of PII from education records. Notification must include: the nature of the incident; the categories and approximate volume of records involved; the likely consequences of the breach; and the measures taken or proposed to address the breach. The provider must support the institution in meeting any applicable breach notification obligations to students, parents, or regulators. (34 CFR § 99.31(a)(1)(i)(B)(*2*); PTAC TOS Model, provision 12, 2016)" + }, + { + "id": "5.3", + "description": "The provider must maintain a documented log or record of all disclosures of PII from education records to third parties, including subprocessors, sufficient to allow the institution to fulfill its recordkeeping obligations and to respond to requests for an accounting of disclosures from parents or eligible students. This record must include the date, identity of the recipient, and the purpose of each disclosure. (34 CFR § 99.32(a); 34 CFR § 99.33(d))" + }, + { + "id": "6.1", + "description": "The provider must not redisclose PII from education records to any third party without the prior written consent of the institution, except where redisclosure is expressly authorized in the written agreement and consistent with FERPA. Any subprocessor or subcontractor to whom the provider discloses PII must be contractually bound by the same use restrictions and data protection obligations as the provider itself. The institution must be informed of all subprocessors with access to PII, and the provider must update this disclosure if subprocessors change. (34 CFR § 99.33(a)(1); 34 CFR § 99.31(a)(1)(i)(B)(*3*); PTAC TOS Model, provision 8, 2016)" + }, + { + "id": "6.2", + "description": "When the provider receives a court order or lawfully issued subpoena requiring disclosure of PII from education records, the provider must notify the institution in advance of compliance so the institution may seek protective action, unless the order or subpoena prohibits such notification. The provider must not comply with such orders or subpoenas without coordination with the institution, except where legally prohibited from doing so. (34 CFR § 99.31(a)(9)(ii); § 99.33(b)(2))" + }, + { + "id": "6.3", + "description": "The provider must maintain and make available to the institution upon request an up-to-date inventory of all subprocessors, sub-contractors, and agents that have access to PII from education records. This inventory must identify each party, describe their function, specify the categories of PII they process, and confirm that they are contractually bound by data protection obligations equivalent to those applicable to the provider. This transparency obligation supports the institution's ability to demonstrate direct control over the provider's data supply chain. (34 CFR § 99.31(a)(1)(i)(B)(*2*); PTAC TOS Model, provision 8, 2016)" + }, + { + "id": "7.1", + "description": "Upon expiration or termination of the agreement, or upon the institution's request, the provider must return or securely destroy all PII from education records in its possession and in the possession of any subprocessors or agents to whom it has transferred such data. Destruction must follow a documented methodology that renders the data unrecoverable. The provider must provide written certification of destruction to the institution within a reasonable period. The obligation to destroy includes all copies, backups, and derivative data that could be used to reconstruct PII. (34 CFR § 99.31(a)(1)(i)(B)(*2*); PTAC Vendor FAQ, 2015; PTAC TOS Model, provision 9, 2016)" + }, + { + "id": "7.2", + "description": "The provider must implement and document a data retention schedule that specifies the maximum period for which each category of PII from education records may be retained, limited to the duration necessary to perform the contracted function. PII must be deleted or anonymized in accordance with this schedule. Retention beyond the contractually specified period constitutes unauthorized maintenance of education records. (34 CFR § 99.31(a)(1)(i)(B)(*1*); PTAC TOS Model, provision 9, 2016)" + }, + { + "id": "7.3", + "description": "Where the provider seeks to retain de-identified data derived from education records for product improvement, research, or other purposes after contract termination, the provider must apply a documented de-identification methodology that removes all direct and indirect identifiers, including name, student ID, date of birth, geographic information at a level smaller than a state, and any other data element that alone or in combination could identify a student. The provider must contractually prohibit any downstream recipient of de-identified data from attempting re-identification. The provider must disclose its de-identification methodology to the institution upon request. (34 CFR § 99.31(b)(1); PTAC TOS Model, provision 2, 2016)" + }, + { + "id": "8.1", + "description": "The provider must maintain a written information security policy and privacy policy that govern its handling of PII from education records. These policies must be reviewed and updated at least annually or following any significant change to the provider's systems, organizational structure, or data processing practices. The provider must make these policies available to the institution upon request and must notify the institution of material policy changes. (34 CFR § 99.31(a)(1)(i)(B)(*2*); PTAC TOS Model, provision 12, 2016)" + }, + { + "id": "8.2", + "description": "The provider must ensure that all personnel, contractors, and agents with access to PII from education records are trained on FERPA requirements and the provider's data protection obligations. Training must cover: the definition and scope of education records; the authorized purposes for which PII may be used; the prohibition on unauthorized use and redisclosure; security obligations; and incident reporting procedures. Training must be conducted at onboarding and refreshed at least annually. (34 CFR § 99.31(a)(1)(i)(B)(*2*); PTAC Vendor FAQ, 2015)" + }, + { + "id": "8.3", + "description": "The provider must perform documented due diligence on all subprocessors and sub-contractors who will have access to PII from education records prior to engagement, and on a periodic basis thereafter. Due diligence must assess the subprocessor's security posture, data protection practices, and ability to comply with FERPA requirements. The provider must maintain records of this due diligence and make them available to the institution upon request. (34 CFR § 99.31(a)(1)(i)(B)(*2*); PTAC TOS Model, provision 8, 2016)" + }, + { + "id": "8.4", + "description": "The provider must conduct periodic privacy impact assessments or equivalent risk evaluations when implementing new processing activities, systems, or technologies that involve PII from education records, including the introduction of AI or automated decision-making capabilities. The assessment must identify privacy risks, evaluate their likelihood and potential impact on students' rights, and document mitigating measures implemented. Results must be available to the institution upon request. (34 CFR § 99.31(a)(1)(i)(B)(*2*); PTAC Data Security Checklist, 2015)" + }, + { + "id": "8.5", + "description": "The provider must maintain a documented business continuity and disaster recovery plan covering systems that process or store PII from education records. The plan must address: recovery time and recovery point objectives; backup procedures and tested restoration capability; and notification procedures to alert the institution of any service disruption affecting availability or integrity of education records. The plan must be tested at least annually and the results documented. (34 CFR § 99.31(a)(1)(i)(B)(*2*) direct control requirement; PTAC Data Security Checklist, 2015)" + }, + { + "id": "8.6", + "description": "The provider must cooperate with the institution's right to audit or verify the provider's compliance with FERPA obligations and the terms of the written agreement. Upon reasonable notice from the institution, the provider must make available documentation, system access, and personnel necessary to confirm that education records are being maintained and used in compliance with FERPA. This audit right must be explicitly provided for in the written agreement. (34 CFR § 99.31(a)(1)(i)(B)(*2*); 34 CFR § 99.62; PTAC Online Educational Services guidance, 2014)" + } + ] +} \ No newline at end of file diff --git a/apps/console/public/data/frameworks/PCI-DSS.json b/apps/console/public/data/frameworks/PCI-DSS.json new file mode 100644 index 000000000..2b7af1477 --- /dev/null +++ b/apps/console/public/data/frameworks/PCI-DSS.json @@ -0,0 +1,1334 @@ +{ + "id": "FERPA", + "name": "FERPA", + "logo": { + "light": "", + "dark": "" + }, + "controls":[ + { + "id": "1.1", + "description": "Processes and mechanisms for installing and maintaining network security controls are defined and understood." + }, + { + "id": "1.1.1", + "description": "All security policies and operational procedures that are identified in Requirement 1 are: documented, kept up to date, in use, and known to all affected parties." + }, + { + "id": "1.1.2", + "description": "Roles and responsibilities for performing activities in Requirement 1 are documented, assigned, and understood." + }, + { + "id": "1.2", + "description": "Network security controls (NSCs) are configured and maintained." + }, + { + "id": "1.2.1", + "description": "Configuration standards for NSC rulesets are: defined, implemented, and maintained." + }, + { + "id": "1.2.2", + "description": "All changes to network connections and to configurations of NSCs are approved and managed in accordance with the change control process defined at Requirement 6.5.1." + }, + { + "id": "1.2.3", + "description": "An accurate network diagram(s) is maintained that shows all connections between the CDE and other networks, including any wireless networks." + }, + { + "id": "1.2.4", + "description": "An accurate data-flow diagram(s) is maintained that shows all account data flows across systems and networks, and is updated as needed upon changes to the environment." + }, + { + "id": "1.2.5", + "description": "All services, protocols, and ports allowed are identified, approved, and have a defined business need." + }, + { + "id": "1.2.6", + "description": "Security 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." + }, + { + "id": "1.2.7", + "description": "Configurations of NSCs are reviewed at least once every six months to confirm they are relevant and effective." + }, + { + "id": "1.2.8", + "description": "Configuration files for NSCs are: secured from unauthorized access, and kept consistent with active network configurations." + }, + { + "id": "1.3", + "description": "Network access to and from the cardholder data environment is restricted." + }, + { + "id": "1.3.1", + "description": "Inbound traffic to the CDE is restricted as follows: to only traffic that is necessary, and all other traffic is specifically denied." + }, + { + "id": "1.3.2", + "description": "Outbound traffic from the CDE is restricted as follows: to only traffic that is necessary, and all other traffic is specifically denied." + }, + { + "id": "1.3.3", + "description": "NSCs 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, and only wireless traffic with an authorized business purpose is allowed into the CDE." + }, + { + "id": "1.4", + "description": "Network connections between trusted and untrusted networks are controlled." + }, + { + "id": "1.4.1", + "description": "NSCs are implemented between trusted and untrusted networks." + }, + { + "id": "1.4.2", + "description": "Inbound 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; stateful responses to communications initiated by system components in a trusted network; all other traffic is denied." + }, + { + "id": "1.4.3", + "description": "Anti-spoofing measures are implemented to detect and block forged source IP addresses from entering the trusted network." + }, + { + "id": "1.4.4", + "description": "System components that store cardholder data are not directly accessible from untrusted networks." + }, + { + "id": "1.4.5", + "description": "The disclosure of internal IP addresses and routing information is limited to only authorized parties." + }, + { + "id": "1.5", + "description": "Risks to the CDE from computing devices that are able to connect to both untrusted networks and the CDE are mitigated." + }, + { + "id": "1.5.1", + "description": "Security 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: specific configuration settings are defined to prevent threats being introduced into the entity's network; security controls are actively running; security controls are not alterable by users of the computing devices unless specifically documented and authorized by management on a case-by-case basis for a limited period." + }, + { + "id": "2.1", + "description": "Processes and mechanisms for applying secure configurations to all system components are defined and understood." + }, + { + "id": "2.1.1", + "description": "All security policies and operational procedures that are identified in Requirement 2 are: documented, kept up to date, in use, and known to all affected parties." + }, + { + "id": "2.1.2", + "description": "Roles and responsibilities for performing activities in Requirement 2 are documented, assigned, and understood." + }, + { + "id": "2.2", + "description": "System components are configured and managed securely." + }, + { + "id": "2.2.1", + "description": "Configuration standards are developed, implemented, and maintained to: cover all system components; address all known security vulnerabilities; be consistent with industry-accepted system hardening standards or vendor hardening recommendations; be updated as new vulnerability issues are identified, as defined in Requirement 6.3.1; be applied when new systems are configured and verified as in place before or immediately after a system component is connected to a production environment." + }, + { + "id": "2.2.2", + "description": "Vendor default accounts are managed as follows: if the vendor default account(s) will be used, the default password is changed per Requirement 8.3.6; if the vendor default account(s) will not be used, the account is removed or disabled." + }, + { + "id": "2.2.3", + "description": "Primary 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." + }, + { + "id": "2.2.4", + "description": "Only necessary services, protocols, daemons, and functions are enabled, and all unnecessary functionality is removed or disabled." + }, + { + "id": "2.2.5", + "description": "If any insecure services, protocols, or daemons are present: business justification is documented, and additional security features are documented and implemented that reduce the risk of using insecure services, protocols, or daemons." + }, + { + "id": "2.2.6", + "description": "System security parameters are configured to prevent misuse." + }, + { + "id": "2.2.7", + "description": "All non-console administrative access is encrypted using strong cryptography." + }, + { + "id": "2.3", + "description": "Wireless environments are configured and managed securely." + }, + { + "id": "2.3.1", + "description": "For 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, passwords on wireless access points, SNMP defaults, and any other security-related wireless vendor defaults." + }, + { + "id": "2.3.2", + "description": "For 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; whenever a key is suspected of or known to be compromised." + }, + { + "id": "3.1", + "description": "Processes and mechanisms for protecting stored account data are defined and understood." + }, + { + "id": "3.1.1", + "description": "All security policies and operational procedures that are identified in Requirement 3 are: documented, kept up to date, in use, and known to all affected parties." + }, + { + "id": "3.1.2", + "description": "Roles and responsibilities for performing activities in Requirement 3 are documented, assigned, and understood." + }, + { + "id": "3.2", + "description": "Storage of account data is kept to a minimum." + }, + { + "id": "3.2.1", + "description": "Account 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; coverage for any sensitive authentication data (SAD) stored prior to completion of authorization; limiting data storage amount and retention time to that which is required for legal or regulatory, and/or business requirements; specific retention requirements for stored account data that defines length of retention period and includes a documented business justification; processes for secure deletion or rendering account data unrecoverable when no longer needed per the retention policy; a process for verifying, at least once every three months, that stored account data exceeding the defined retention period has been securely deleted or rendered unrecoverable." + }, + { + "id": "3.3", + "description": "Sensitive authentication data (SAD) is not stored after authorization." + }, + { + "id": "3.3.1", + "description": "SAD is not stored after authorization, even if encrypted. All sensitive authentication data received is rendered unrecoverable upon completion of the authorization process." + }, + { + "id": "3.3.1.1", + "description": "The full contents of any track are not stored upon completion of the authorization process." + }, + { + "id": "3.3.1.2", + "description": "The card verification code is not stored upon completion of the authorization process." + }, + { + "id": "3.3.1.3", + "description": "The personal identification number (PIN) and the PIN block are not stored upon completion of the authorization process." + }, + { + "id": "3.3.2", + "description": "SAD that is stored electronically prior to completion of authorization is encrypted using strong cryptography." + }, + { + "id": "3.3.3", + "description": "Additional 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, and encrypted using strong cryptography." + }, + { + "id": "3.4", + "description": "Access to displays of full PAN and ability to copy PAN are restricted." + }, + { + "id": "3.4.1", + "description": "PAN 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." + }, + { + "id": "3.4.2", + "description": "When 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." + }, + { + "id": "3.5", + "description": "Primary account number (PAN) is secured wherever it is stored." + }, + { + "id": "3.5.1", + "description": "PAN 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; truncation (hashing cannot be used to replace the truncated segment of PAN); index tokens; strong cryptography with associated key-management processes and procedures." + }, + { + "id": "3.5.1.1", + "description": "Hashes used to render PAN unreadable (per the first bullet of Requirement 3.5.1) are keyed cryptographic hashes of the entire PAN, with associated key-management processes and procedures in accordance with Requirements 3.6 and 3.7." + }, + { + "id": "3.5.1.2", + "description": "If disk-level or partition-level encryption (rather than file-, column-, or field-level database encryption) is used to render PAN unreadable, it is implemented only as follows: on removable electronic media, OR if used for non-removable electronic media, PAN is also rendered unreadable via another mechanism that meets Requirement 3.5.1." + }, + { + "id": "3.5.1.3", + "description": "If disk-level or partition-level encryption is used (rather than file-, column-, or field-level database encryption) to render PAN unreadable, it is managed as follows: logical access is managed separately and independently of native operating system authentication and access control mechanisms; decryption keys are not associated with user accounts; authentication factors (passwords, passphrases, or cryptographic keys) that allow access to unencrypted data are stored securely." + }, + { + "id": "3.6", + "description": "Cryptographic keys used to protect stored account data are secured." + }, + { + "id": "3.6.1", + "description": "Procedures 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; key-encrypting keys are at least as strong as the data-encrypting keys they protect; key-encrypting keys are stored separately from data-encrypting keys; keys are stored securely in the fewest possible locations and forms." + }, + { + "id": "3.6.1.1", + "description": "Additional requirement for service providers only: a documented description of the cryptographic architecture is maintained that includes: details of all algorithms, protocols, and keys used for the protection of stored account data, including key strength and expiry date; preventing the use of the same cryptographic keys in production and test environments; description of the key usage for each key; inventory of any HSMs, KMS, and other SCDs used for key management." + }, + { + "id": "3.6.1.2", + "description": "Secret and private keys used to encrypt/decrypt stored account data are stored in one (or more) of the following forms at all times: encrypted with a key-encrypting key that is at least as strong as the data-encrypting key, and that is stored separately from the data-encrypting key; within a secure cryptographic device (SCD), such as a hardware security module (HSM) or PTS-approved point-of-interaction device; as at least two full-length key components or key shares, in accordance with an industry-accepted method." + }, + { + "id": "3.6.1.3", + "description": "Access to cleartext cryptographic key components is restricted to the fewest number of custodians necessary." + }, + { + "id": "3.6.1.4", + "description": "Cryptographic keys are stored in the fewest possible locations." + }, + { + "id": "3.7", + "description": "Where cryptography is used to protect stored account data, key management processes and procedures covering all aspects of the key lifecycle are defined and implemented." + }, + { + "id": "3.7.1", + "description": "Key-management policies and procedures are implemented to include generation of strong cryptographic keys used to protect stored account data." + }, + { + "id": "3.7.2", + "description": "Key-management policies and procedures are implemented to include secure distribution of cryptographic keys used to protect stored account data." + }, + { + "id": "3.7.3", + "description": "Key-management policies and procedures are implemented to include secure storage of cryptographic keys used to protect stored account data." + }, + { + "id": "3.7.4", + "description": "Key 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; a process for key changes at the end of the defined cryptoperiod." + }, + { + "id": "3.7.5", + "description": "Key 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; the integrity of the key has been weakened, including when personnel with knowledge of a cleartext key component leaves the company, or the role for which the key component was known; the key is suspected of or known to be compromised. Retired or replaced keys are not used for encryption operations." + }, + { + "id": "3.7.6", + "description": "Where 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." + }, + { + "id": "3.7.7", + "description": "Key management policies and procedures are implemented to include the prevention of unauthorized substitution of cryptographic keys." + }, + { + "id": "3.7.8", + "description": "Key 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." + }, + { + "id": "3.7.9", + "description": "Additional 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." + }, + { + "id": "4.1", + "description": "Processes and mechanisms for protecting cardholder data with strong cryptography during transmission over open, public networks are defined and understood." + }, + { + "id": "4.1.1", + "description": "All security policies and operational procedures that are identified in Requirement 4 are: documented, kept up to date, in use, and known to all affected parties." + }, + { + "id": "4.1.2", + "description": "Roles and responsibilities for performing activities in Requirement 4 are documented, assigned, and understood." + }, + { + "id": "4.2", + "description": "PAN is protected with strong cryptography during transmission." + }, + { + "id": "4.2.1", + "description": "Strong cryptography and security protocols are implemented as follows to safeguard PAN during transmission over open, public networks: only trusted keys and certificates are accepted; certificates used to safeguard PAN during transmission over open, public networks are confirmed as valid and are not expired or revoked; the protocol in use supports only secure versions or configurations and does not support fallback to, or use of insecure versions, algorithms, key sizes, or implementations; the encryption strength is appropriate for the encryption methodology in use." + }, + { + "id": "4.2.1.1", + "description": "An inventory of the entity's trusted keys and certificates used to protect PAN during transmission is maintained." + }, + { + "id": "4.2.1.2", + "description": "Wireless networks transmitting PAN or connected to the CDE use industry best practices to implement strong cryptography for authentication and transmission." + }, + { + "id": "4.2.2", + "description": "PAN is secured with strong cryptography whenever it is sent via end-user messaging technologies." + }, + { + "id": "5.1", + "description": "Processes and mechanisms for protecting all systems and networks from malicious software are defined and understood." + }, + { + "id": "5.1.1", + "description": "All security policies and operational procedures that are identified in Requirement 5 are: documented, kept up to date, in use, and known to all affected parties." + }, + { + "id": "5.1.2", + "description": "Roles and responsibilities for performing activities in Requirement 5 are documented, assigned, and understood." + }, + { + "id": "5.2", + "description": "Malicious software (malware) is prevented, or detected and addressed." + }, + { + "id": "5.2.1", + "description": "An anti-malware solution(s) is deployed on all system components, except for those system components identified in periodic evaluations per Requirement 5.2.3 that concludes the system components are not at risk from malware." + }, + { + "id": "5.2.2", + "description": "The deployed anti-malware solution(s): detects all known types of malware; removes, blocks, or contains all known types of malware." + }, + { + "id": "5.2.3", + "description": "Any 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; identification and evaluation of evolving malware threats for those system components; confirmation whether such system components continue to not require anti-malware protection." + }, + { + "id": "5.2.3.1", + "description": "The frequency of periodic evaluations of system components identified as not at risk for malware is defined in the entity's targeted risk analysis, which is performed according to all elements specified in Requirement 12.3.1." + }, + { + "id": "5.3", + "description": "Anti-malware mechanisms and processes are active, maintained, and monitored." + }, + { + "id": "5.3.1", + "description": "The anti-malware solution(s) is kept current via automatic updates." + }, + { + "id": "5.3.2", + "description": "The anti-malware solution(s): performs periodic scans and active or real-time scans, OR performs continuous behavioral analysis of systems or processes." + }, + { + "id": "5.3.2.1", + "description": "If periodic malware scans are performed to meet Requirement 5.3.2, the frequency of scans is defined in the entity's targeted risk analysis, which is performed according to all elements specified in Requirement 12.3.1." + }, + { + "id": "5.3.3", + "description": "For 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." + }, + { + "id": "5.3.4", + "description": "Audit logs for the anti-malware solution(s) are enabled and retained in accordance with Requirement 10.5.1." + }, + { + "id": "5.3.5", + "description": "Anti-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." + }, + { + "id": "5.4", + "description": "Anti-phishing mechanisms protect users against phishing attacks." + }, + { + "id": "5.4.1", + "description": "Processes and automated mechanisms are in place to detect and protect personnel against phishing attacks." + }, + { + "id": "6.1", + "description": "Processes and mechanisms for developing and maintaining secure systems and software are defined and understood." + }, + { + "id": "6.1.1", + "description": "All security policies and operational procedures that are identified in Requirement 6 are: documented, kept up to date, in use, and known to all affected parties." + }, + { + "id": "6.1.2", + "description": "Roles and responsibilities for performing activities in Requirement 6 are documented, assigned, and understood." + }, + { + "id": "6.2", + "description": "Bespoke and custom software are developed securely." + }, + { + "id": "6.2.1", + "description": "Bespoke and custom software are developed securely, as follows: based on industry standards and/or best practices for secure development; in accordance with PCI DSS (for example, secure authentication and logging); incorporating consideration of information security issues during each stage of the software development lifecycle." + }, + { + "id": "6.2.2", + "description": "Software 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; including secure software design and secure coding techniques; including, if security testing tools are used, how to use the tools for detecting vulnerabilities in software." + }, + { + "id": "6.2.3", + "description": "Bespoke 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; code reviews look for both existing and emerging software vulnerabilities; appropriate corrections are implemented prior to release." + }, + { + "id": "6.2.3.1", + "description": "If manual code reviews are performed for bespoke and custom software prior to release to production, code changes are: reviewed by individuals other than the originating code author, and who are knowledgeable about code-review techniques and secure coding practices; reviewed and approved by management prior to release." + }, + { + "id": "6.2.4", + "description": "Software engineering techniques or other methods are defined and in use by software development personnel to prevent or mitigate common software attacks and related vulnerabilities in bespoke and custom software, including but not limited to the following: injection attacks; attacks on data and data structures; attacks on cryptography usage; attacks on business logic; attacks on access control mechanisms; attacks via any high-risk vulnerabilities identified in the vulnerability identification process, as defined in Requirement 6.3.1." + }, + { + "id": "6.3", + "description": "Security vulnerabilities are identified and addressed." + }, + { + "id": "6.3.1", + "description": "Security 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); vulnerabilities are assigned a risk ranking based on industry best practices and consideration of potential impact; risk rankings identify, at a minimum, all vulnerabilities considered to be a high-risk or critical to the environment; vulnerabilities for bespoke and custom, and third-party software (for example operating systems and databases) are covered." + }, + { + "id": "6.3.2", + "description": "An 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." + }, + { + "id": "6.3.3", + "description": "All 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.3.1) are installed within one month of release; all other applicable security patches/updates are installed within an appropriate time frame as determined by the entity." + }, + { + "id": "6.4", + "description": "Public-facing web applications are protected against attacks." + }, + { + "id": "6.4.1", + "description": "For public-facing web applications, new threats and vulnerabilities are addressed on an ongoing basis and these applications are protected against known attacks." + }, + { + "id": "6.4.2", + "description": "For 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; actively running and up to date as applicable; generating audit logs; configured to either block web-based attacks or generate an alert that is immediately investigated." + }, + { + "id": "6.4.3", + "description": "All 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; a method is implemented to assure the integrity of each script; an inventory of all scripts is maintained with written business or technical justification as to why each is necessary." + }, + { + "id": "6.5", + "description": "Changes to all system components are managed securely." + }, + { + "id": "6.5.1", + "description": "Changes to all system components in the production environment are made according to established procedures that include: reason for, and description of, the change; documentation of security impact; documented change approval by authorized parties; testing to verify that the change does not adversely impact system security; for bespoke and custom software changes, all updates are tested for compliance with Requirement 6.2.4 before being deployed into production; procedures to address failures and return to a secure state." + }, + { + "id": "6.5.2", + "description": "Upon 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." + }, + { + "id": "6.5.3", + "description": "Pre-production environments are separated from production environments and the separation is enforced with access controls." + }, + { + "id": "6.5.4", + "description": "Roles and functions are separated between production and pre-production environments to provide accountability such that only reviewed and approved changes are deployed." + }, + { + "id": "6.5.5", + "description": "Live 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." + }, + { + "id": "6.5.6", + "description": "Test data and test accounts are removed from system components before the system goes into production." + }, + { + "id": "7.1", + "description": "Processes and mechanisms for restricting access to system components and cardholder data by business need to know are defined and understood." + }, + { + "id": "7.1.1", + "description": "All security policies and operational procedures that are identified in Requirement 7 are: documented, kept up to date, in use, and known to all affected parties." + }, + { + "id": "7.1.2", + "description": "Roles and responsibilities for performing activities in Requirement 7 are documented, assigned, and understood." + }, + { + "id": "7.2", + "description": "Access to system components and data is appropriately defined and assigned." + }, + { + "id": "7.2.1", + "description": "An access control model is defined and includes granting access as follows: appropriate access depending on the entity's business and access needs; access to system components and data resources that is based on users' job classification and functions; the least privileges required (for example, user, administrator) to perform a job function." + }, + { + "id": "7.2.2", + "description": "Access is assigned to users, including privileged users, based on: job classification and function; least privileges necessary to perform job responsibilities." + }, + { + "id": "7.2.3", + "description": "Required privileges are approved by authorized personnel." + }, + { + "id": "7.2.4", + "description": "All 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; any inappropriate access is addressed; management acknowledges that access remains appropriate." + }, + { + "id": "7.2.5", + "description": "All 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; access is limited to the systems, applications, or processes that specifically require their use." + }, + { + "id": "7.2.5.1", + "description": "All access by application and system accounts and related access privileges are reviewed as follows: periodically (at the frequency defined in the entity's targeted risk analysis, which is performed according to all elements specified in Requirement 12.3.1); the application/system access remains appropriate for the function being performed; any inappropriate access is addressed; management acknowledges that access remains appropriate." + }, + { + "id": "7.2.6", + "description": "All 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; only the responsible administrator(s) can directly access or query repositories of stored CHD." + }, + { + "id": "7.3", + "description": "Access to system components and data is managed via an access control system(s)." + }, + { + "id": "7.3.1", + "description": "An access control system(s) is in place that restricts access based on a user's need to know and covers all system components." + }, + { + "id": "7.3.2", + "description": "The access control system(s) is configured to enforce permissions assigned to individuals, applications, and systems based on job classification and function." + }, + { + "id": "7.3.3", + "description": "The access control system(s) is set to 'deny all' by default." + }, + { + "id": "8.1", + "description": "Processes and mechanisms for identifying users and authenticating access to system components are defined and understood." + }, + { + "id": "8.1.1", + "description": "All security policies and operational procedures that are identified in Requirement 8 are: documented, kept up to date, in use, and known to all affected parties." + }, + { + "id": "8.1.2", + "description": "Roles and responsibilities for performing activities in Requirement 8 are documented, assigned, and understood." + }, + { + "id": "8.2", + "description": "User identification and related accounts for users and administrators are strictly managed throughout an account's lifecycle." + }, + { + "id": "8.2.1", + "description": "All users are assigned a unique ID before access to system components or cardholder data is allowed." + }, + { + "id": "8.2.2", + "description": "Group, 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; use is limited to the time needed for the exceptional circumstance; business justification for use is documented; use is explicitly approved by management; individual user identity is confirmed before access to an account is granted; every action taken is attributable to an individual user." + }, + { + "id": "8.2.3", + "description": "Additional requirement for service providers only: service providers with remote access to customer premises use unique authentication factors for each customer premises." + }, + { + "id": "8.2.4", + "description": "Addition, deletion, and modification of user IDs, authentication factors, and other identifier objects are managed as follows: authorized with the appropriate approval; implemented with only the privileges specified on the documented approval." + }, + { + "id": "8.2.5", + "description": "Access for terminated users is immediately revoked." + }, + { + "id": "8.2.6", + "description": "Inactive user accounts are removed or disabled within 90 days of inactivity." + }, + { + "id": "8.2.7", + "description": "Accounts 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; use is monitored for unexpected activity." + }, + { + "id": "8.2.8", + "description": "If 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." + }, + { + "id": "8.3", + "description": "Strong authentication for users and administrators is established and managed." + }, + { + "id": "8.3.1", + "description": "All 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; something you have, such as a token device or smart card; something you are, such as a biometric element." + }, + { + "id": "8.3.2", + "description": "Strong cryptography is used to render all authentication factors unreadable during transmission and storage on all system components." + }, + { + "id": "8.3.3", + "description": "User identity is verified before modifying any authentication factor." + }, + { + "id": "8.3.4", + "description": "Invalid authentication attempts are limited by: locking out the user ID after not more than 10 attempts; setting the lockout duration to a minimum of 30 minutes or until the user's identity is confirmed." + }, + { + "id": "8.3.5", + "description": "If passwords/passphrases are used as authentication factors to meet Requirement 8.3.1, they are set and reset for each user as follows: set to a unique value for first-time use and upon reset; forced to be changed immediately after the first use." + }, + { + "id": "8.3.6", + "description": "If passwords/passphrases are used as authentication factors to meet Requirement 8.3.1, they meet the following minimum level of complexity: a minimum length of 12 characters (or IF the system does not support 12 characters, a minimum length of eight characters); contain both numeric and alphabetic characters." + }, + { + "id": "8.3.7", + "description": "Individuals are not allowed to submit a new password/passphrase that is the same as any of the last four passwords/passphrases used." + }, + { + "id": "8.3.8", + "description": "Authentication policies and procedures are documented and communicated to all users including: guidance on selecting strong authentication factors; guidance for how users should protect their authentication factors; instructions not to reuse previously used passwords/passphrases; instructions to change passwords/passphrases if there is any suspicion or knowledge that the password/passphrases have been compromised and how to report the incident." + }, + { + "id": "8.3.9", + "description": "If passwords/passphrases are used as the only authentication factor for user access (i.e., in any single-factor authentication implementation) then either: passwords/passphrases are changed at least once every 90 days, OR the security posture of accounts is dynamically analyzed, and real-time access to resources is automatically determined accordingly." + }, + { + "id": "8.3.10", + "description": "Additional requirement for service providers only: if passwords/passphrases are used as the only authentication factor for customer user access to cardholder data (i.e., in any single-factor authentication implementation), then guidance is provided to customer users including: guidance for customers to change their user passwords/passphrases periodically; guidance as to when, and under what circumstances, passwords/passphrases are to be changed." + }, + { + "id": "8.3.10.1", + "description": "Additional requirement for service providers only: if passwords/passphrases are used as the only authentication factor for customer user access (i.e., in any single-factor authentication implementation) then either: passwords/passphrases are changed at least once every 90 days, OR the security posture of accounts is dynamically analyzed, and real-time access to resources is automatically determined accordingly." + }, + { + "id": "8.3.11", + "description": "Where 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; physical and/or logical controls ensure only the intended user can use that factor to gain access." + }, + { + "id": "8.4", + "description": "Multi-factor authentication (MFA) is implemented to secure access into the CDE." + }, + { + "id": "8.4.1", + "description": "MFA is implemented for all non-console access into the CDE for personnel with administrative access." + }, + { + "id": "8.4.2", + "description": "MFA is implemented for all non-console access into the CDE." + }, + { + "id": "8.4.3", + "description": "MFA is implemented for all remote access originating from outside the entity's network that could access or impact the CDE." + }, + { + "id": "8.5", + "description": "Multi-factor authentication (MFA) systems are configured to prevent misuse." + }, + { + "id": "8.5.1", + "description": "MFA systems are implemented as follows: the MFA system is not susceptible to replay attacks; MFA systems cannot be bypassed by any users, including administrative users unless specifically documented, and authorized by management on an exception basis, for a limited time period; at least two different types of authentication factors are used; success of all authentication factors is required before access is granted." + }, + { + "id": "8.6", + "description": "Use of application and system accounts and associated authentication factors is strictly managed." + }, + { + "id": "8.6.1", + "description": "If 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; interactive use is limited to the time needed for the exceptional circumstance; business justification for interactive use is documented; interactive use is explicitly approved by management; individual user identity is confirmed before access to account is granted; every action taken is attributable to an individual user." + }, + { + "id": "8.6.2", + "description": "Passwords/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." + }, + { + "id": "8.6.3", + "description": "Passwords/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.3.1) and upon suspicion or confirmation of compromise; passwords/passphrases are constructed with sufficient complexity appropriate for how frequently the entity changes the passwords/passphrases." + }, + { + "id": "9.1", + "description": "Processes and mechanisms for restricting physical access to cardholder data are defined and understood." + }, + { + "id": "9.1.1", + "description": "All security policies and operational procedures that are identified in Requirement 9 are: documented, kept up to date, in use, and known to all affected parties." + }, + { + "id": "9.1.2", + "description": "Roles and responsibilities for performing activities in Requirement 9 are documented, assigned, and understood." + }, + { + "id": "9.2", + "description": "Physical access controls manage entry into facilities and systems containing cardholder data." + }, + { + "id": "9.2.1", + "description": "Appropriate facility entry controls are in place to restrict physical access to systems in the CDE." + }, + { + "id": "9.2.1.1", + "description": "Individual physical access to sensitive areas within the CDE is monitored with either video cameras or physical access control mechanisms (or both) as follows: entry/exit points to/from sensitive areas within the CDE are monitored; monitoring devices or mechanisms are protected from tampering or disabling; collected data is reviewed and correlated with other entries; collected data is stored for at least three months, unless otherwise restricted by law." + }, + { + "id": "9.2.2", + "description": "Physical and/or logical controls are implemented to restrict use of publicly accessible network jacks within the facility." + }, + { + "id": "9.2.3", + "description": "Physical and/or logical controls are implemented to restrict wireless access to the CDE." + }, + { + "id": "9.2.4", + "description": "Access to consoles in sensitive areas is restricted via locking when not in use." + }, + { + "id": "9.3", + "description": "Physical access for personnel and visitors is authorized and managed." + }, + { + "id": "9.3.1", + "description": "Procedures are implemented for authorizing and managing physical access of personnel to the CDE, including: identifying personnel; managing changes to an individual's physical access requirements; revoking or terminating personnel physical access; deactivating physical access mechanisms, such as keys, access cards, etc." + }, + { + "id": "9.3.1.1", + "description": "Physical access to sensitive areas within the CDE for personnel is controlled as follows: access is authorized and based on individual job function; access is revoked immediately upon termination; all physical access mechanisms, such as keys, access cards, etc., are returned or disabled upon termination." + }, + { + "id": "9.3.2", + "description": "Procedures are implemented for identifying and distinguishing between onsite personnel and visitors, as follows: onsite personnel and visitors are easily distinguishable." + }, + { + "id": "9.3.3", + "description": "Visitor access to the cardholder data environment is managed as follows: visitors are authorized before entering; visitors are escorted at all times; visitors are clearly identified and given a badge or other identification that visibly distinguishes the visitors from onsite personnel; visitor badges or identification are surrendered or deactivated before visitors leave the facility or at the date of expiration." + }, + { + "id": "9.3.4", + "description": "A visitor log is used to maintain a physical trail of visitor activity within the facility as well as computer rooms and data centers where cardholder data is stored or transmitted, including: the visitor's name and the organization represented; the date/time of visit; the name of the personnel authorizing physical access; retaining the log for at least three months, unless otherwise restricted by law." + }, + { + "id": "9.4", + "description": "Media with cardholder data is securely stored, accessed, distributed, and destroyed." + }, + { + "id": "9.4.1", + "description": "All media with cardholder data is physically secured." + }, + { + "id": "9.4.1.1", + "description": "Offline media backups with cardholder data are stored in a secure location." + }, + { + "id": "9.4.1.2", + "description": "The security of the offline media backup location(s) is reviewed at least once every 12 months." + }, + { + "id": "9.4.2", + "description": "All media with cardholder data is classified in accordance with the sensitivity of the data." + }, + { + "id": "9.4.3", + "description": "Media with cardholder data sent outside the facility is secured as follows: media sent outside the facility is logged; media is sent by secured courier or other delivery method that can be accurately tracked; offsite tracking logs include details about media location." + }, + { + "id": "9.4.4", + "description": "Management approves all media with cardholder data that is moved outside the facility (including when media is distributed to individuals)." + }, + { + "id": "9.4.5", + "description": "Inventory logs of all electronic media with cardholder data are maintained." + }, + { + "id": "9.4.5.1", + "description": "Inventories of electronic media with cardholder data are conducted at least once every 12 months." + }, + { + "id": "9.4.6", + "description": "Hard-copy materials with cardholder data are destroyed when no longer needed for business or legal reasons." + }, + { + "id": "9.4.7", + "description": "Electronic media with cardholder data is destroyed when no longer needed for business or legal reasons." + }, + { + "id": "9.5", + "description": "Point-of-interaction (POI) devices are protected from tampering and unauthorized substitution." + }, + { + "id": "9.5.1", + "description": "POI 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; periodically inspecting POI devices to look for tampering or unauthorized substitution; training personnel to be aware of suspicious behavior and to report tampering or unauthorized substitution of devices." + }, + { + "id": "9.5.1.1", + "description": "An up-to-date list of POI devices is maintained, including: make and model of the device; location of device; device serial number or other method of unique identification." + }, + { + "id": "9.5.1.2", + "description": "POI device surfaces are periodically inspected to detect tampering and unauthorized substitution." + }, + { + "id": "9.5.1.2.1", + "description": "The frequency of periodic POI device inspections and the type of inspections performed is defined in the entity's targeted risk analysis, which is performed according to all elements specified in Requirement 12.3.1." + }, + { + "id": "9.5.1.3", + "description": "Training is provided for personnel in POI environments to be aware of attempted tampering or replacement of POI devices." + }, + { + "id": "10.1", + "description": "Processes and mechanisms for logging and monitoring all access to system components and cardholder data are defined and understood." + }, + { + "id": "10.1.1", + "description": "All security policies and operational procedures that are identified in Requirement 10 are: documented, kept up to date, in use, and known to all affected parties." + }, + { + "id": "10.1.2", + "description": "Roles and responsibilities for performing activities in Requirement 10 are documented, assigned, and understood." + }, + { + "id": "10.2", + "description": "Audit logs are implemented to support the detection of anomalies and suspicious activity, and the forensic analysis of events." + }, + { + "id": "10.2.1", + "description": "Audit logs are enabled and active for all system components and cardholder data." + }, + { + "id": "10.2.1.1", + "description": "Audit logs capture all individual user access to cardholder data." + }, + { + "id": "10.2.1.2", + "description": "Audit logs capture all actions taken by any individual with administrative access, including any interactive use of application or system accounts." + }, + { + "id": "10.2.1.3", + "description": "Audit logs capture all access to audit logs." + }, + { + "id": "10.2.1.4", + "description": "Audit logs capture all invalid logical access attempts." + }, + { + "id": "10.2.1.5", + "description": "Audit logs capture all changes to identification and authentication credentials including but not limited to: creation of new accounts; elevation of privileges; all changes, additions, or deletions to accounts with administrative access." + }, + { + "id": "10.2.1.6", + "description": "Audit logs capture the following: all initialization of new audit logs and all starting, stopping, or pausing of the existing audit logs." + }, + { + "id": "10.2.1.7", + "description": "Audit logs capture all creation and deletion of system-level objects." + }, + { + "id": "10.2.2", + "description": "Audit logs record the following details for each auditable event: user identification; type of event; date and time; success and failure indication; origination of event; identity or name of affected data, system component, resource, or service (for example, name and protocol)." + }, + { + "id": "10.3", + "description": "Audit logs are protected from destruction and unauthorized modifications." + }, + { + "id": "10.3.1", + "description": "Read access to audit logs files is limited to those with a job-related need." + }, + { + "id": "10.3.2", + "description": "Audit log files are protected to prevent modifications by individuals." + }, + { + "id": "10.3.3", + "description": "Audit 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." + }, + { + "id": "10.3.4", + "description": "File integrity monitoring or change-detection mechanisms is used on audit logs to ensure that existing log data cannot be changed without generating alerts." + }, + { + "id": "10.4", + "description": "Audit logs are reviewed to identify anomalies or suspicious activity." + }, + { + "id": "10.4.1", + "description": "The following audit logs are reviewed at least once daily: all security events; logs of all system components that store, process, or transmit CHD and/or SAD; logs of all critical system components; logs of all servers and system components that perform security functions (for example, NSCs, IDS/IPS, authentication servers, e-commerce redirection servers, etc.)." + }, + { + "id": "10.4.1.1", + "description": "Automated mechanisms are used to perform audit log reviews." + }, + { + "id": "10.4.2", + "description": "Logs of all other system components (not defined in Requirement 10.4.1) are reviewed periodically." + }, + { + "id": "10.4.2.1", + "description": "The frequency of periodic log reviews for all other system components (not defined in Requirement 10.4.1) is defined in the entity's targeted risk analysis, which is performed according to all elements specified in Requirement 12.3.1." + }, + { + "id": "10.4.3", + "description": "Exceptions and anomalies identified during the review process are addressed." + }, + { + "id": "10.5", + "description": "Audit log history is retained and available for analysis." + }, + { + "id": "10.5.1", + "description": "Retain audit log history for at least 12 months, with at least the most recent three months immediately available for analysis." + }, + { + "id": "10.6", + "description": "Time-synchronization mechanisms support consistent time settings across all systems." + }, + { + "id": "10.6.1", + "description": "System clocks and time are synchronized using time-synchronization technology." + }, + { + "id": "10.6.2", + "description": "Systems are configured to the correct and consistent time as follows: one or more designated time servers are in use; only the designated central time server(s) receives time from external sources; time received from external sources is based on International Atomic Time or Coordinated Universal Time (UTC); the designated time server(s) accept time updates only from specific, industry-accepted external sources; where there is more than one designated time server, the time servers peer with one another to keep accurate time; internal systems receive time information only from designated central time server(s)." + }, + { + "id": "10.6.3", + "description": "Time synchronization settings and data are protected as follows: access to time data is restricted to only personnel with a business need; any changes to time settings on critical systems are logged, monitored, and reviewed." + }, + { + "id": "10.7", + "description": "Failures of critical security control systems are detected, reported, and responded to promptly." + }, + { + "id": "10.7.1", + "description": "Additional requirement for service providers only: failures of critical security control systems are detected, alerted, and addressed promptly, including but not limited to failure of: network security controls; IDS/IPS; change-detection mechanisms; anti-malware solutions; physical access controls; logical access controls; audit logging mechanisms; segmentation controls (if used)." + }, + { + "id": "10.7.2", + "description": "Failures of critical security control systems are detected, alerted, and addressed promptly, including but not limited to failure of: network security controls; IDS/IPS; change-detection mechanisms; anti-malware solutions; physical access controls; logical access controls; audit logging mechanisms; segmentation controls (if used); audit log review mechanisms." + }, + { + "id": "10.7.3", + "description": "Failures of any critical security control systems are responded to promptly, including but not limited to: restoring security functions; identifying and documenting the duration (date and time from start to end) of the security failure; identifying and documenting the cause(s) of failure and documenting required remediation; identifying and addressing any security issues that arose during the failure; determining whether further actions are required as a result of the security failure; implementing controls to prevent the cause of failure from recurring; resuming monitoring of security controls." + }, + { + "id": "11.1", + "description": "Processes and mechanisms for regularly testing security of systems and networks are defined and understood." + }, + { + "id": "11.1.1", + "description": "All security policies and operational procedures that are identified in Requirement 11 are: documented, kept up to date, in use, and known to all affected parties." + }, + { + "id": "11.1.2", + "description": "Roles and responsibilities for performing activities in Requirement 11 are documented, assigned, and understood." + }, + { + "id": "11.2", + "description": "Wireless access points are identified and monitored, and unauthorized wireless access points are addressed." + }, + { + "id": "11.2.1", + "description": "Authorized 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." + }, + { + "id": "11.2.2", + "description": "An inventory of authorized wireless access points is maintained, including a documented business justification." + }, + { + "id": "11.3", + "description": "External and internal vulnerabilities are regularly identified, prioritized, and addressed." + }, + { + "id": "11.3.1", + "description": "Internal vulnerability scans are performed as follows: at least once every three months; high-risk and critical vulnerabilities (per the entity's vulnerability risk rankings defined at Requirement 6.3.1) are resolved; rescans are performed that confirm all high-risk and critical vulnerabilities have been resolved; scan tool is kept up to date with latest vulnerability information; scans are performed by qualified personnel and organizational independence of the tester exists." + }, + { + "id": "11.3.1.1", + "description": "All other applicable vulnerabilities (those not ranked as high-risk or critical per the entity's vulnerability risk rankings defined at Requirement 6.3.1) are managed as follows: addressed based on the risk defined in the entity's targeted risk analysis, which is performed according to all elements specified in Requirement 12.3.1; rescans are conducted as needed." + }, + { + "id": "11.3.1.2", + "description": "Internal vulnerability scans are performed via authenticated scanning." + }, + { + "id": "11.3.1.3", + "description": "Internal vulnerability scans are performed after any significant change." + }, + { + "id": "11.3.2", + "description": "External vulnerability scans are performed as follows: at least once every three months; by a PCI SSC Approved Scanning Vendor (ASV); vulnerabilities are resolved and ASV Program Guide requirements for a passing scan are met; rescans are performed as needed to confirm that vulnerabilities are resolved per the ASV Program Guide requirements for a passing scan." + }, + { + "id": "11.3.2.1", + "description": "External vulnerability scans are performed after any significant change." + }, + { + "id": "11.4", + "description": "External and internal penetration testing is regularly performed, and exploitable vulnerabilities and security weaknesses are corrected." + }, + { + "id": "11.4.1", + "description": "A penetration testing methodology is defined, implemented, and maintained by the entity and includes: industry-accepted penetration testing approaches; coverage for the entire CDE perimeter and critical systems; testing from both inside and outside the network; testing to validate any segmentation and scope-reduction controls; application-layer penetration testing to identify, at a minimum, the vulnerabilities listed in Requirement 6.2.4; network-layer penetration tests that encompass all components that support network functions as well as operating systems; review and consideration of threats and vulnerabilities experienced in the last 12 months." + }, + { + "id": "11.4.2", + "description": "Internal 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." + }, + { + "id": "11.4.3", + "description": "External 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." + }, + { + "id": "11.4.4", + "description": "Exploitable 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 Requirement 6.3.1; penetration testing is repeated to verify the corrections." + }, + { + "id": "11.4.5", + "description": "If 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; according to the entity's defined penetration testing methodology; confirming that the segmentation controls/methods are operational and effective, and isolate the CDE from all out-of-scope systems; confirming effectiveness of any use of isolation to separate systems with differing security levels." + }, + { + "id": "11.4.6", + "description": "Additional 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; covering all segmentation controls/methods in use; according to the entity's defined penetration testing methodology; confirming that the segmentation controls/methods are operational and effective, and isolate the CDE from all out-of-scope systems; confirming effectiveness of any use of isolation to separate systems with differing security levels." + }, + { + "id": "11.4.7", + "description": "Additional requirement for multi-tenant service providers only: multi-tenant service providers support their customers for external penetration testing per Requirement 11.4.3 and 11.4.4." + }, + { + "id": "11.5", + "description": "Network intrusions and unexpected file changes are detected and responded to." + }, + { + "id": "11.5.1", + "description": "Intrusion-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; all traffic is monitored at critical points in the CDE; personnel are alerted to suspected compromises; all intrusion-detection and prevention engines, baselines, and signatures are kept up to date." + }, + { + "id": "11.5.1.1", + "description": "Additional requirement for service providers only: intrusion-detection and/or intrusion-prevention techniques detect, alert on/prevent, and address covert malware communication channels." + }, + { + "id": "11.5.2", + "description": "A 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; critical file comparisons are performed at least once weekly." + }, + { + "id": "11.6", + "description": "Unauthorized changes on payment pages are detected and responded to." + }, + { + "id": "11.6.1", + "description": "A 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 HTTP headers and the contents of payment pages as received by the consumer browser; the mechanism is configured to evaluate the received HTTP header and payment page." + }, + { + "id": "12.1", + "description": "A comprehensive information security policy that governs and provides direction for protection of the entity's information assets is known and current." + }, + { + "id": "12.1.1", + "description": "An overall information security policy is: established; published; maintained; disseminated to all relevant personnel, as well as to relevant vendors and business partners." + }, + { + "id": "12.1.2", + "description": "The information security policy is: reviewed at least once every 12 months; updated as needed to reflect changes to business objectives or risks to the environment." + }, + { + "id": "12.1.3", + "description": "The security policy clearly defines information security roles and responsibilities for all personnel, and all personnel are aware of and acknowledge their information security responsibilities." + }, + { + "id": "12.1.4", + "description": "Responsibility for information security is formally assigned to a Chief Information Security Officer or other information security knowledgeable member of executive management." + }, + { + "id": "12.2", + "description": "Acceptable use policies for end-user technologies are defined and implemented." + }, + { + "id": "12.2.1", + "description": "Acceptable use policies for end-user technologies are documented and implemented, including: explicit approval by authorized parties; acceptable uses of the technology; list of products approved by the company for employee use, including hardware and software." + }, + { + "id": "12.3", + "description": "Risks to the cardholder data environment are formally identified, evaluated, and managed." + }, + { + "id": "12.3.1", + "description": "Each PCI DSS requirement that provides flexibility for how frequently it is performed (for example, requirements to be performed periodically) is supported by a targeted risk analysis that is documented and includes: identification of the assets being protected; identification of the threat(s) that the requirement is protecting against; identification of factors that contribute to the likelihood and/or impact of a threat being realized; resulting analysis that determines, and includes justification for, how frequently the requirement must be performed to minimize the likelihood of the threat being realized." + }, + { + "id": "12.3.2", + "description": "A targeted risk analysis is performed for each PCI DSS requirement that the entity meets with the customized approach." + }, + { + "id": "12.3.3", + "description": "Cryptographic 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; active monitoring of industry trends regarding continued viability of all cryptographic cipher suites and protocols in use; a documented strategy to respond to anticipated changes in cryptographic vulnerabilities." + }, + { + "id": "12.3.4", + "description": "Hardware 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; analysis that the technologies continue to support (and do not preclude) the entity's PCI DSS compliance; documentation of any industry announcements or trends related to a technology, such as when a vendor has announced 'end of life' plans for a technology; documentation of a plan, approved by senior management, to remediate outdated technologies, including those for which vendors have announced 'end of life' plans." + }, + { + "id": "12.4", + "description": "PCI DSS compliance is managed." + }, + { + "id": "12.4.1", + "description": "Additional requirement for service providers only: responsibility is established by executive management for the protection of cardholder data and a PCI DSS compliance program." + }, + { + "id": "12.4.2", + "description": "Additional requirement for service providers only: reviews are performed at least once every three months to confirm that personnel are performing their tasks in accordance with all security policies and operational procedures." + }, + { + "id": "12.4.2.1", + "description": "Additional requirement for service providers only: reviews conducted in accordance with Requirement 12.4.2 are documented to include: results of the reviews; documented remediation actions taken for any tasks that were found to not be performed." + }, + { + "id": "12.5", + "description": "PCI DSS scope is documented and validated." + }, + { + "id": "12.5.1", + "description": "An inventory of system components that are in scope for PCI DSS, including a description of function/use for each, is maintained and kept current." + }, + { + "id": "12.5.2", + "description": "PCI DSS scope is documented and confirmed by the entity at least once every 12 months and upon significant change to the in-scope environment." + }, + { + "id": "12.5.2.1", + "description": "Additional requirement for service providers only: PCI DSS scope is documented and confirmed by the entity at least once every six months and upon significant change to the in-scope environment." + }, + { + "id": "12.5.3", + "description": "Additional 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." + }, + { + "id": "12.6", + "description": "Security awareness education is an ongoing activity." + }, + { + "id": "12.6.1", + "description": "A 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 cardholder data." + }, + { + "id": "12.6.2", + "description": "The 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 CDE, or the information provided to personnel about their role in protecting cardholder data." + }, + { + "id": "12.6.3", + "description": "Personnel receive security awareness training as follows: upon hire and at least once every 12 months; multiple methods of communication are used." + }, + { + "id": "12.6.3.1", + "description": "Security awareness training includes awareness of threats and vulnerabilities that could impact the security of the CDE, including but not limited to: phishing and related attacks; social engineering." + }, + { + "id": "12.6.3.2", + "description": "Security awareness training includes awareness about the acceptable use of end-user technologies in accordance with Requirement 12.2.1." + }, + { + "id": "12.7", + "description": "Personnel are screened to reduce risks from insider threats." + }, + { + "id": "12.7.1", + "description": "Potential 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." + }, + { + "id": "12.8", + "description": "Risk to information assets associated with third-party service provider (TPSP) relationships is managed." + }, + { + "id": "12.8.1", + "description": "A 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." + }, + { + "id": "12.8.2", + "description": "Written 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 cardholder data and/or sensitive authentication data." + }, + { + "id": "12.8.3", + "description": "An established process is implemented for engaging TPSPs, including proper due diligence prior to engagement." + }, + { + "id": "12.8.4", + "description": "A program is implemented to monitor TPSPs' PCI DSS compliance status at least once every 12 months." + }, + { + "id": "12.8.5", + "description": "Information 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." + }, + { + "id": "12.9", + "description": "Third-party service providers (TPSPs) support their customers' PCI DSS compliance." + }, + { + "id": "12.9.1", + "description": "Additional requirement for service providers only: TPSPs provide to their customers upon request: PCI DSS compliance status information for any service the TPSP performs on behalf of customers or that could impact the security of customers' cardholder data and/or sensitive authentication data; information about which PCI DSS requirements are the responsibility of the TPSP, which are the responsibility of the customer, and any that are shared between the TPSP and the customer." + }, + { + "id": "12.9.2", + "description": "TPSPs support their customers' requests for information to meet Requirements 12.8.4 and 12.8.5 by providing the following upon customer request: PCI DSS compliance status information for any service the TPSP performs on behalf of customers or that could impact the security of customers' cardholder data and/or sensitive authentication data; information about which PCI DSS requirements are the responsibility of the TPSP, which are the responsibility of the customer, and any that are shared between the TPSP and the customer." + }, + { + "id": "12.10", + "description": "Suspected and confirmed security incidents that could impact the CDE are responded to immediately." + }, + { + "id": "12.10.1", + "description": "An incident response plan exists and is ready to be activated in the event of a suspected or confirmed security incident. The plan includes, but is not limited to: roles, responsibilities, and communication and contact strategies in the event of a suspected or confirmed security incident, including notification of the payment brands and acquirers, at a minimum; incident response procedures with specific containment and mitigation activities for different types of incidents; business recovery and continuity procedures; data backup processes; analysis of legal requirements for reporting compromises; coverage and responses of all critical system components; reference or inclusion of incident response procedures from the payment brands." + }, + { + "id": "12.10.2", + "description": "At least once every 12 months, the security incident response plan is: reviewed and the content is updated as needed; tested, including all elements listed in Requirement 12.10.1." + }, + { + "id": "12.10.3", + "description": "Specific personnel are designated to be available on a 24/7 basis to respond to suspected or confirmed security incidents." + }, + { + "id": "12.10.4", + "description": "Personnel responsible for responding to suspected and confirmed security incidents are appropriately and periodically trained on their incident response responsibilities." + }, + { + "id": "12.10.4.1", + "description": "The frequency of periodic training for incident response personnel is defined in the entity's targeted risk analysis, which is performed according to all elements specified in Requirement 12.3.1." + }, + { + "id": "12.10.5", + "description": "The 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; network security controls; change-detection mechanisms for critical files; the change-and tamper-detection mechanism for payment pages." + }, + { + "id": "12.10.6", + "description": "The security incident response plan is modified and evolved according to lessons learned and to incorporate industry developments." + }, + { + "id": "12.10.7", + "description": "Incident 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; identifying whether sensitive authentication data is stored with PAN; determining where the account data came from and how it ended up where it was not expected; remediating data leaks or process gaps that resulted in the account data being where it was not expected." + }, + { + "id": "A1.1", + "description": "Multi-tenant service providers protect and separate all customer environments and data." + }, + { + "id": "A1.1.1", + "description": "Logical separation is implemented as follows such that: the provider's customers cannot access another customer's environment; a customer cannot access the service provider's environment." + }, + { + "id": "A1.1.2", + "description": "Controls are implemented such that each customer's processes can only access that customer's cardholder data environment and cardholder data." + }, + { + "id": "A1.1.3", + "description": "Controls are implemented such that each customer can only access resources allocated to them." + }, + { + "id": "A1.1.4", + "description": "The effectiveness of logical separation controls used to separate customer environments is confirmed at least once every six months via penetration testing." + }, + { + "id": "A1.2", + "description": "Multi-tenant service providers facilitate logging and incident response for all customers." + }, + { + "id": "A1.2.1", + "description": "Audit logging is enabled for each customer's environment that is consistent with PCI DSS Requirement 10, including: logs are enabled for common third-party applications; logs are active by default; logs are available for review only by the owning customer; log locations are clearly communicated to the owning customer; log data and availability is consistent with PCI DSS Requirement 10.5.1." + }, + { + "id": "A1.2.2", + "description": "Processes or mechanisms are implemented to support and/or facilitate prompt forensic investigations in the event of a suspected or confirmed security incident for any customer." + }, + { + "id": "A1.2.3", + "description": "Processes or mechanisms are implemented for reporting and addressing suspected or confirmed security incidents and vulnerabilities, including: customers can securely report security incidents and vulnerabilities to the provider; the provider addresses and remediates suspected or confirmed security incidents and vulnerabilities according to Requirement 6.3.1." + }, + { + "id": "A2.1", + "description": "POI terminals using SSL and/or early TLS are confirmed as not susceptible to known exploits, and the entity has a formal Risk Mitigation and Migration Plan in place." + }, + { + "id": "A2.1.1", + "description": "Where POS POI terminals at the point of interaction use SSL and/or early TLS, the entity confirms the devices are not susceptible to any known exploits for those protocols." + }, + { + "id": "A2.1.2", + "description": "Where POS POI terminals at the point of interaction use SSL and/or early TLS, the entity confirms the software on the terminals is not susceptible to any known exploits for those protocols." + }, + { + "id": "A2.1.3", + "description": "Where POS POI terminals at the point of interaction use SSL and/or early TLS, all other uses of SSL/early TLS within the entity's environment are in accordance with Requirements 2.2.5 and 4.2.1." + }, + { + "id": "A3.1", + "description": "A PCI DSS compliance program is implemented." + }, + { + "id": "A3.2", + "description": "PCI DSS scope is documented and validated." + }, + { + "id": "A3.3", + "description": "PCI DSS is incorporated into business-as-usual (BAU) activities." + }, + { + "id": "A3.4", + "description": "Logical access to the cardholder data environment is controlled and managed." + }, + { + "id": "A3.5", + "description": "Suspicious events are identified and responded to." + } + ] +} \ No newline at end of file