searchclear
Try Searching For
close
Responsibility Matrix - Google Drive
Responsibility Matrix : Inbox Health
Responsibility Matrix - Google Drive
| 1 | Index | Requirement | Defined Approach | Customer | Inbox Health | Notes |
| 2 | 1 | 1.1.1 | All security policies and operational procedures that are identified in Requirement 1 are: • Documented. • Kept up to date. • In use. • Known to all affected parties. |
Shared | Shared | Inbox Health is responsible for ensuring that their policies and procedures are documented, up to date and made known to all affected parties. Inbox Health customers are responsible for ensuring that their policies and procedures are documented, up to date and made known to all affected parties. |
| 3 | 2 | 1.1.2 | Roles and responsibilities for performing activities in Requirement 1 are documented, assigned, and understood. | Shared | Shared | Inbox Health is responsible for establishing defined roles and responsibilities to oversee network components supporting the CDE. Inbox Health customers are responsible for establishing defined roles and responsibilities to oversee network components supporting their own CDE. |
| 4 | 3 | 1.2.1 | Configuration standards for NSC rulesets are: • Defined. • Implemented. • Maintained. |
Shared | Shared | Inbox Health is responsible for establishing and implementing firewall and router configuration standards for the devices that are present in the CDE. Inbox Health customers are responsible for establishing and implementing firewall and router configuration standards for the devices that are present in their own CDE. |
| 5 | 4 | 1.2.2 | 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. | Shared | Shared | Inbox Health is responsible for establishing and implementing a process for testing and approval of all network connections and changes to the CDE. Inbox Health customers are responsible for establishing and implementing a process for testing and approval of all network connections and changes to their in-scope environment. |
| 6 | 5 | 1.2.3 | An accurate network diagram(s) is maintained that shows all connections between the CDE and other networks, including any wireless networks. | Shared | Shared | Inbox Health is responsible for establishing and maintaining network diagrams that identifies all networks, network devices, and system components, with all connections between the CDE and other networks. Inbox Health customers are responsible for establishing and maintaining network diagrams that identifies all networks, network devices, and system components, with all connections between their CDE and other networks. |
| 7 | 6 | 1.2.4 | An accurate data-flow diagram(s) is maintained that meets the following: • Shows all account data flows across systems and networks. • Updated as needed upon changes to the environment. |
Shared | Shared | Inbox Health is responsible for establishing and maintaining data flow diagrams that identifies all cardholder data flows across systems and networks. Inbox Health customers are responsible for establishing and maintaining data flow diagrams that identifies all cardholder data flows across systems and networks. |
| 8 | 7 | 1.2.5 | All services, protocols, and ports allowed are identified, approved, and have a defined business need. | Shared | Shared | Inbox Health is responsible for documenting business justification for use of all services, protocols, and ports allowed within the CDE. Inbox Health customers are responsible for documenting business justification for use of all services, protocols, and ports allowed within their CDE. |
| 9 | 8 | 1.2.6 | 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. | Shared | Shared | Inbox Health is responsible for identifying insecure services and implementing appropriate controls and security features to limit the risk of the protocols from being used. Inbox Health customers are responsible for identifying insecure services and implementing appropriate controls and security features to limit the risk of the protocols from being used. |
| 10 | 9 | 1.2.7 | Configurations of NSCs are reviewed at least once every six months to confirm they are relevant and effective. | Shared | Shared | Inbox Health is responsible for performing semi-annual reviews of their firewalls and other network technology and services that are used to filter traffic into the CDE. Inbox Health customers are responsible for performing semi-annual reviews of their firewalls and other network technology and services that are used to filter traffic into their CDE. |
| 11 | 10 | 1.2.8 | Configuration files for NSCs are: • Secured from unauthorized access. • Kept consistent with active network configurations. |
Shared | Shared | Inbox Health is responsible for synchronizing and securing network technologies supporting their CDE. Inbox Health customers are responsible for synchronizing and securing network technologies supporting their own CDE. |
| 12 | 11 | 1.3.1 | Inbound traffic to the CDE is restricted as follows: • To only traffic that is necessary. • All other traffic is specifically denied. |
Shared | Shared | Inbox Health is responsible for developing appropriate firewall rules or using additional firewall technologies to allow only necessary inbound traffic to the CDE. All other traffic not explicitly required is denied. Inbox Health customers are responsible for developing appropriate firewall rules or using additional firewall technologies to allow only necessary inbound traffic to the CDE. Customers must define expclit deny rules for unnecessary traffic. |
| 13 | 12 | 1.3.2 | Outbound traffic from the CDE is restricted as follows: • To only traffic that is necessary. • All other traffic is specifically denied. |
Shared | Shared | Inbox Health is responsible for developing appropriate firewall rules or using additional firewall technologies to allow only necessary outbound traffic from the CDE. All other traffic not explicitly required is denied. Inbox Health customers are responsible for developing appropriate firewall rules or using additional firewall technologies to allow only necessary outbound traffic to the CDE. Customers must define expclit deny rules for unnecessary traffic. |
| 14 | 13 | 1.3.3 | 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. • Only wireless traffic with an authorized business purpose is allowed into the CDE. |
Shared | Shared | Inbox Health does not allow wireless connections to the CDE. Inbox Health customers that use wireless networks are responsible for isolating their cardholder data environment from those wireless networks. |
| 15 | 14 | 1.4.1 | NSCs are implemented between trusted and untrusted networks. | Shared | Shared | Inbox Health is responsible to maintain firewall and network technologies that prohibit direct public access between the Internet and system compoenents in their CDE. Inbox Health customers are responsible to maintain firewall and network technologies that prohibit direct public access between the Internet and system compoenents in their own CDE. |
| 16 | 15a | 1.4.2 | 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. |
Shared | Shared | Inbox Health is responsible for implementing appropriate firewall rules or using additional firewall technologies to develop DMZ network for the CDE and ensuring only authorized services, ports and protocols are accessible, stateful connections are established and all other traffic is denied. Inbox Health customers are responsible for implementing appropriate firewall rules or using additional firewall technologies to develop DMZ network for the CDE and ensuring only authorized services, ports and protocols are accessible, stateful connections are established and all other traffic is denied. |
| 17 | 16 | 1.4.3 | Anti-spoofing measures are implemented to detect and block forged source IP addresses from entering the trusted network. | Shared | Shared | Inbox Health is responsible for implementing appropriate anti-spoofing measures to restrict incoming and outgoing traffic to trusted platform components in their CDE. Inbox Health customers are responsible for implementing appropriate anti-spoofing measures to restrict incoming and outgoing traffic to trusted platform components in their CDE. |
| 18 | 17 | 1.4.4 | System components that store cardholder data are not directly accessible from untrusted networks. | Shared | Shared | Inbox Health is responsible for implementing proper network configurations towards placement of any systems that store cardholder data within the CDE. Inbox Health customers are responsible for implementing proper network configurations towards placement of any systems that store cardholder data within their own CDE. |
| 19 | 18 | 1.4.5 | The disclosure of internal IP addresses and routing information is limited to only authorized parties. | Shared | Shared | Inbox Health is responsible for network and firewall configurations which prevent the disclosure of internal IP Addresses and routing information. Inbox Health customers are responsible for network and firewall configuration to prevent the disclosure of internal IP Addresses and routing information. |
| 20 | 19 | 1.5.1 | 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. |
Shared | Shared | Inbox Health is responsible for implementing personal firewall software on any portable devices that connect to the CDE from the Internet. Inbox Health customers are responsible for implementing personal firewall software on any portable devices that connect to their own CDE from the Internet. |
| 21 | 20 | 2.1.1 | All security policies and operational procedures that are identified in Requirement 2 are: • Documented. • Kept up to date. • In use. • Known to all affected parties. |
Shared | Shared | Inbox Health is responsible for ensuring that their policies and procedures are documented, up to date and made known to all affected parties. Inbox Health customers are responsible for ensuring that their policies and procedures are documented, up to date and made known to all affected parties. |
| 22 | 21 | 2.1.2 | Roles and responsibilities for performing activities in Requirement 2 are documented, assigned, and understood. | Shared | Shared | Inbox Health is responsible for establishing defined roles and responsibilities to oversee secure configuration of system components supporting the CDE. Inbox Health customers are responsible for establishing defined roles and responsibilities to oversee secure configuration of system components supporting their own CDE. |
| 23 | 22 | 2.2.1 | 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. |
Shared | Shared | Inbox Health is responsible for developing, implementing and maintaining configuration standards for systems in the CDE. Inbox Health customers are responsible for developing, implementing and maintaining configuration standards for systems in their CDE. |
| 24 | 23 | 2.2.2 | 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. |
Shared | Shared | Inbox Health is responsible for removing, disabling or changing default vendor accounts. Inbox Health customers are responsible for removing, disabling or changing default vendor accounts. |
| 25 | 24 | 2.2.3 | 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. |
Shared | Shared | Inbox Health is responsible for ensuring only one primary function exists per system component in the CDE. Inbox Health customers are responsible for ensuring only one primary function exists per system component in their CDE. |
| 26 | 25a | 2.2.4 | Only necessary services, protocols, daemons, and functions are enabled, and all unnecessary functionality is removed or disabled. | Shared | Shared | Inbox Health is responsible for ensuring only necessary services, protocols are enabled and all unncessary functionality is removed in the CDE. Inbox Health customers are responsible for ensuring only necessary services, protocols are enabled and and all unncessary functionality is removed in the CDE. |
| 27 | 26 | 2.2.5 | If any insecure services, protocols, or daemons are present: • Business justification is documented. • Additional security features are documented and implemented that reduce the risk of using insecure services, protocols, or daemons. |
Shared | Shared | Inbox Health is responsible for maintaining business justification and implementing additional security features for services, protocols that are considered to be insecure. Inbox Health customers are responsible for maintaining business justification and implementing additional security features for services, protocols that are considered to be insecure in their own CDE. |
| 28 | 27 | 2.2.6 | System security parameters are configured to prevent misuse. | Shared | Shared | Inbox Health is responsible for configuring system security parameters in the CDE. Inbox Health customers are responsible for configuring system security parameters in their own CDE. |
| 29 | 28 | 2.2.7 | All non-console administrative access is encrypted using strong cryptography. | Shared | Shared | Inbox Health is responsible for configuring strong cryptography for all non-console adminstrative access to systems in the CDE. Inbox Health customers are responsible for configuring strong cryptography for all non-console adminstrative access to systems in their CDE. |
| 30 | 29 | 2.3.1 | 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. • Any other security-related wireless vendor defaults. |
Shared | Shared | Inbox Health customers are responsible for management of their networks, including the wireless networks that are connected to their own CDE. |
| 31 | 30 | 2.3.2 | 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. |
Shared | Shared | Inbox Health customers are responsible for management of their networks, including the wireless networks that are connected to their own CDE. |
| 32 | 31 | 3.1.1 | All security policies and operational procedures that are identified in Requirement 3 are: • Documented. • Kept up to date. • In use. • Known to all affected parties. |
Shared | Shared | Inbox Health is responsible for ensuring that their policies and procedures are documented, up to date and made known to all affected parties. Inbox Health customers are responsible for ensuring that their policies and procedures are documented, up to date and made known to all affected parties. |
| 33 | 32 | 3.1.2 | Roles and responsibilities for performing activities in Requirement 3 are documented, assigned, and understood. | Shared | Shared | Inbox Health is responsible for establishing defined roles and responsibilities to oversee security of stored account data supporting the CDE. Inbox Health customers are responsible for establishing defined roles and responsibilities to oversee security of stored account data supporting their CDE. |
| 34 | 33 | 3.2.1 | 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. |
Shared | Shared | Inbox Health is responsible for maintaning data retention and deletion policy and procedures towards CHD transmitted or stored within the CDE. Inbox Health customers are responsible for maintaning data retention and deletion policy and procedures towards CHD transmitted or stored within their CDE. |
| 35 | 34 | 3.3.1 | SAD is not stored after authorization, even if encrypted. All sensitive authentication data received is rendered unrecoverable upon completion of the authorization process. | Shared | Shared | Inbox Health is responsible for ensuring authentication data, track data, verification codes and PINs are not stored after authorization. Inbox Health customers are responsible for ensuring authentication data, track data, verification codes and PINs are not stored after authorization, unless they are Issuers. |
| 36 | 35 | 3.3.1.1 | The full contents of any track are not stored upon completion of the authorization process. | Shared | Shared | Inbox Health is responsible for ensuring authentication data, track data is not stored after authorization. Inbox Health customers are responsible for ensuring authentication data, track data is not stored after authorization. |
| 37 | 36 | 3.3.1.2 | The card verification code is not stored upon completion of the authorization process. | Shared | Shared | Inbox Health is responsible for ensuring authentication data, verification codes are not stored after authorization. Inbox Health customers are responsible for ensuring authentication data, verification codes are not stored after authorization. |
| 38 | 37 | 3.3.1.3 | The personal identification number (PIN) and the PIN block are not stored upon completion of the authorization process. | Shared | Shared | Inbox Health is responsible for ensuring PIN data is not stored post authorization. Inbox Health customers are responsible for ensuring PIN data is not stored after authorization. |
| 39 | 38 | 3.3.2 | SAD that is stored electronically prior to completion of authorization is encrypted using strong cryptography. | Shared | Shared | Inbox Health is responsible for encrypting SAD with strong cryptography when stored electronically. Inbox Health customers are responsible for encrypting SAD with strong cryptography when stored electronically within their own CDE. |
| 40 | 39 | 3.3.3 | 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. • Encrypted using strong cryptography. |
Shared | Shared | Inbox Health is responsible for encrypting SAD with strong cryptographywhen stored electronically. Inbox Health customers are responsible for encrypting SAD with strong cryptography when stored electronically and storage of SAD within their own CDE. This bullet is a best practice until its effective date; refer to Applicability Notes below for details. |
| 41 | 40 | 3.4.1 | 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. | Shared | Shared | Inbox Health is responsible for ensuring masking PAN data and documentin all related procedures. Inbox Health customers are responsible for masking PAN data, and documenting all related procedures. |
| 42 | 41 | 3.4.2 | 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. | Shared | Shared | Inbox Health is responsible for maintaining acceptable usage policies and implementing controls to prevent relocation of PAN. Inbox Health customers are responsible to maintain acceptable usage policies. |
| 43 | 42 | 3.5.1 | 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). – If hashed and truncated versions of the same PAN, or different truncation formats of the same PAN, are present in an environment, additional controls are in place such that the different versions cannot be correlated to reconstruct the original PAN. • Index tokens. • Strong cryptography with associated key- management processes and procedures. |
Shared | Shared | Inbox Health is responsible for ensuring PAN data is rendered unreadable by hashing, truncation, index tokens or strong cryptography methods whenever stored in their CDE. Inbox Health customers are responsible for ensuring PAN data is rendered unreadable by hashing, truncation, index tokens or strong cryptography methods whenever stored in their CDE. |
| 44 | 43 | 3.5.1.1 | 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. | Shared | Shared | Inbox Health is responsible for ensuring PAN data is rendered unreadable by hashing, truncation, index tokens or strong cryptography methods whenever stored in their CDE. Inbox Health customers are responsible for ensuring keyed cryptographic hashes of the entire PAN, with associated key-management processes and procedures are maintained. This bullet is a best practice until its effective date; refer to Applicability Notes below for details. |
| 45 | 44 | 3.5.1.2 | 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. |
Shared | Shared | Inbox Health does not use disk-level encryption to render PAN unreadable, so this is not applicable to Inbox Health. Inbox Health customers are responsible for maintaining disk level encryption within their own CDE environment. This bullet is a best practice until its effective date; refer to Applicability Notes below for details. |
| 46 | 45 | 3.5.1.3 | 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. |
Responsible | Not Responsible | Inbox Health does not use disk-level encryption to render PAN unreadable, so this is not applicable to Inbox Health. Inbox Health customers are responsible for maintaining disk level encryption within their own CDE environment. |
| 47 | 46 | 3.6.1 | 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. |
Shared | Shared | Inbox Health is responsible for encryption and key management processess related to CHD stored within their CDE. Inbox Health customers are responsible for encryption and key management processess related to CHD stored within their own CDE. |
| 48 | 47 | 3.6.1.1 | 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 hardware security modules (HSMs), key management systems (KMS), and other secure cryptographic devices (SCDs) used for key management, including type and location of devices, as outlined in Requirement 12.3.4. |
Shared | Shared | Inbox Health is responsible for encryption and key management processess related to CHD stored within their CDE. Inbox Health customers are responsible for encryption and key management processess related to CHD stored within their own CDE. |
| 49 | 48 | 3.6.1.2 | 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. |
Shared | Shared | Inbox Health is responsible for encryption and key management processess related to CHD stored within their CDE. Inbox Health customers are responsible for encryption and key management processess related to CHD stored within their own CDE. |
| 50 | 49 | 3.6.1.3 | Access to cleartext cryptographic key components is restricted to the fewest number of custodians necessary. | Shared | Shared | Inbox Health is responsible for encryption and key management processess related to CHD stored within their CDE. Inbox Health customers are responsible for encryption and key management processess related to CHD stored within their own CDE. |
| 51 | 50 | 3.6.1.4 | Cryptographic keys are stored in the fewest possible locations. | Shared | Shared | Inbox Health is responsible for encryption and key management processess related to CHD stored within their CDE. Inbox Health customers are responsible for encryption and key management processess related to CHD stored within their own CDE. |
| 52 | 51 | 3.7.1 | Key-management policies and procedures are implemented to include generation of strong cryptographic keys used to protect stored account data. | Shared | Shared | Inbox Health is responsible for encryption and key management processess related to CHD stored within their CDE. Inbox Health customers are responsible for encryption and key management processess related to CHD stored within their own CDE. |
| 53 | 52 | 3.7.2 | Key-management policies and procedures are implemented to include secure distribution of cryptographic keys used to protect stored account data. | Shared | Shared | Inbox Health is responsible for encryption and key management processess related to CHD stored within their CDE. Inbox Health customers are responsible for encryption and key management processess related to CHD stored within their own CDE. |
| 54 | 53 | 3.7.3 | Key-management policies and procedures are implemented to include secure storage of cryptographic keys used to protect stored account data. | Shared | Shared | Inbox Health is responsible for encryption and key management processess related to CHD stored within their CDE. Inbox Health customers are responsible for encryption and key management processess related to CHD stored within their own CDE. |
| 55 | 54 | 3.7.4 | 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. |
Shared | Shared | Inbox Health is responsible for encryption and key management processess related to CHD stored within their CDE. Inbox Health customers are responsible for encryption and key management processess related to CHD stored within their own CDE. |
| 56 | 55 | 3.7.5 | 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. |
Shared | Shared | Inbox Health is responsible for encryption and key management processess related to CHD stored within their CDE. Inbox Health customers are responsible for encryption and key management processess related to CHD stored within their own CDE. |
| 57 | 56 | 3.7.6 | Where manual cleartext cryptographic key- management operations are performed by personnel, key-management policies and procedures are implemented include managing these operations using split knowledge and dual control. | Shared | Shared | Inbox Health is responsible for encryption and key management processess related to CHD stored within their CDE. Inbox Health customers are responsible for encryption and key management processess related to CHD stored within their own CDE. |
| 58 | 57 | 3.7.7 | Key management policies and procedures are implemented to include the prevention of unauthorized substitution of cryptographic keys. | Shared | Shared | Inbox Health is responsible for encryption and key management processess related to CHD stored within their CDE. Inbox Health customers are responsible for encryption and key management processess related to CHD stored within their own CDE. |
| 59 | 58 | 3.7.8 | 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. | Shared | Shared | Inbox Health is responsible for encryption and key management processess related to CHD stored within their CDE. Inbox Health customers are responsible for encryption and key management processess related to CHD stored within their own CDE. |
| 60 | 59 | 3.7.9 | 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. | Shared | Shared | Inbox Health does not share cryptographic keys within the CDE. Inbox Health customers are responsible for encryption and key management processess related to CHD stored within their own CDE. |
| 61 | 60 | 4.1.1 | All security policies and operational procedures that are identified in Requirement 4 are: • Documented. • Kept up to date. • In use. • Known to all affected parties. |
Shared | Shared | Inbox Health is responsible for ensuring that their policies and procedures are documented, up to date and made known to all affected parties. Inbox Health customers are responsible for ensuring that their policies and procedures are documented, up to date and made known to all affected parties. |
| 62 | 61 | 4.1.2 | Roles and responsibilities for performing activities in Requirement 4 are documented, assigned, and understood. | Shared | Shared | Inbox Health is responsible for establishing defined roles and responsibilities to oversee CHD is protected with strong cryptography during transmission over open, public networks. Inbox Health customers are responsible for establishing defined roles and responsibilities to oversee CHD is protected with strong cryptography during transmission over open, public networks. |
| 63 | 62 | 4.2.1 | 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. |
Shared | Shared | Inbox Health is responsible for ensuring strong cryptography and security protocols, certificates are deployed for connections to any storage system that is transmitting cardholder data. Inbox Health customers are responsible for ensuring strong cryptography and security protocols, certificates are deployed for connections to any storage system that is transmitting cardholder data. Inbox Health customers are responsible for ensuring the data is encrypted in transit as well as when stored. |
| 64 | 63 | 4.2.1.1 | An inventory of the entity’s trusted keys and certificates used to protect PAN during transmission is maintained. | Shared | Shared | Inbox Health is responsible for maintaining documented inventory of keys and certificates used to protect CHD transmission. Inbox Health customers are responsible for maintaining documented inventory of keys and certificates used to protect CHD transmission. |
| 65 | 64 | 4.2.1.2 | Wireless networks transmitting PAN or connected to the CDE use industry best practices to implement strong cryptography for authentication and transmission. | Shared | Shared | Inbox Health customers are responsible for management of their networks, including those with wireless connectivity. |
| 66 | 65 | 4.2.2 | PAN is secured with strong cryptography whenever it is sent via end-user messaging technologies. | Shared | Shared | Inbox Health is responsible for cryptography and network transmission security processes for the use of any end-user messaging technologies transmitting PAN. Inbox Health customers are responsible for the cryptography and network transmission security processes for the use of any end-user messaging technologies transmitting PAN. |
| 67 | 66 | 5.1.1 | All security policies and operational procedures that are identified in Requirement 5 are: • Documented. • Kept up to date. • In use. • Known to all affected parties. |
Shared | Shared | Inbox Health is responsible for ensuring that their policies and procedures are documented, up to date and made known to all affected parties. Inbox Health customers are responsible for ensuring that their policies and procedures are documented, up to date and made known to all affected parties. |
| 68 | 67 | 5.1.2 | Roles and responsibilities for performing activities in Requirement 5 are documented, assigned, and understood. | Shared | Shared | Inbox Health is responsible for establishing defined roles and responsibilities to oversee all systems and networks are protected against malicious software. Inbox Health customers are responsible for establishing defined roles and responsibilities to oversee all systems and networks are protected against malicious software. |
| 69 | 68 | 5.2.1 | 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. | Shared | Shared | Inbox Health is responsible for implementing anti-malware protection on assets supporting the CDE. Inbox Health customers are responsible for implementing anti-malware protection on their own CDE. |
| 70 | 69 | 5.2.2 | The deployed anti-malware solution(s): • Detects all known types of malware. • Removes, blocks, or contains all known types of malware. |
Shared | Shared | Inbox Health is responsible for implementing anti-malware protection on assets supporting the CDE. Inbox Health customers are responsible for implementing anti-malware protection on their own CDE. |
| 71 | 70 | 5.2.3 | 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. |
Shared | Shared | Inbox Health is responsible for implementing anti-malware protection on assets supporting the CDE. Inbox Health customers are responsible for implementing anti-malware protection on their own CDE. |
| 72 | 71 | 5.2.3.1 | 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. | Shared | Shared | Inbox Health is responsible for implementing anti-malware protection on assets supporting the CDE. Inbox Health customers are responsible for implementing anti-malware protection on their own CDE. |
| 73 | 72 | 5.3.1 | The anti-malware solution(s) is kept current via automatic updates. | Shared | Shared | Inbox Health is responsible for implementing anti-malware protection on assets supporting the CDE. Inbox Health customers are responsible for implementing anti-malware protection on their own CDE. |
| 74 | 73 | 5.3.2 | The anti-malware solution(s): • Performs periodic scans and active or real-time scans. OR • Performs continuous behavioral analysis of systems or processes. |
Shared | Shared | Inbox Health is responsible for implementing anti-malware protection on assets supporting the CDE. Inbox Health customers are responsible for implementing anti-malware protection on their own CDE. |
| 75 | 74 | 5.3.2.1 | 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. | Shared | Shared | Inbox Health is responsible for implementing anti-malware protection on assets supporting the CDE. Inbox Health customers are responsible for implementing anti-malware protection on their own CDE. |
| 76 | 75 | 5.3.3 | 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. |
Shared | Shared | Inbox Health is responsible for implementing anti-malware protection on assets supporting the CDE. Inbox Health customers are responsible for implementing anti-malware protection on their own CDE. |
| 77 | 76 | 5.3.4 | Audit logs for the anti-malware solution(s) are enabled and retained in accordance with Requirement 10.5.1. | Shared | Shared | Inbox Health is responsible for implementing anti-malware protection on assets supporting the CDE. Inbox Health customers are responsible for implementing anti-malware protection on their own CDE. |
| 78 | 77 | 5.3.5 | 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. | Shared | Shared | Inbox Health is responsible for implementing anti-malware protection on assets supporting the CDE. Inbox Health customers are responsible for implementing anti-malware protection on their own CDE. |
| 79 | 78 | 5.4.1 | Processes and automated mechanisms are in place to detect and protect personnel against phishing attacks. | Shared | Shared | Inbox Health is responsible for implementing anti-phishing mechanisms for Inbox Health's in-scope environment. Inbox Health customers are responsible for implementing anti-phishing mechanisms in support of their own CDE. |
| 80 | 79 | 6.1.1 | All security policies and operational procedures that are identified in Requirement 6 are: • Documented. • Kept up to date. • In use. • Known to all affected parties. |
Shared | Shared | Inbox Health is responsible for ensuring that their policies and procedures are documented, up to date and made known to all affected parties. Inbox Health customers are responsible for ensuring that their policies and procedures are documented, up to date and made known to all affected parties. |
| 81 | 80 | 6.1.2 | Roles and responsibilities for performing activities in Requirement 6 are documented, assigned, and understood. | Shared | Shared | Inbox Health is responsible for establishing defined roles and responsibilities to oversee development and maintenance of secure systems and software. Inbox Health customers are responsible for establishing defined roles and responsibilities to oversee network components supporting their own CDE. |
| 82 | 81 | 6.2.1 | 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. |
Shared | Shared | Inbox Health is responsible for maintaining a secure software development program to support their CDE assets. Inbox Health customers are responsible for maintaining a secure software development program to support their own CDE assets. |
| 83 | 82 | 6.2.2 | 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. |
Shared | Shared | Inbox Health is responsible for maintaining a secure software development program to support their CDE assets. Inbox Health customers are responsible for maintaining a secure software development program to support their own CDE assets. |
| 84 | 83 | 6.2.3 | 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. |
Shared | Shared | Inbox Health is responsible for maintaining a secure software development program to support their CDE assets. Inbox Health customers are responsible for maintaining a secure software development program to support their own CDE assets. |
| 85 | 84 | 6.2.3.1 | 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. |
Shared | Shared | Inbox Health is responsible for maintaining a secure software development program to support their CDE assets. Inbox Health customers are responsible for maintaining a secure software development program to support their own CDE assets. |
| 86 | 85a | 6.2.4 | 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, including SQL, LDAP , XPath, or other command, parameter, object, fault, or injection-type flaws. • Attacks on data and data structures, including attempts to manipulate buffers, pointers, input data, or shared data. • Attacks on cryptography usage, including attempts to exploit weak, insecure, or inappropriate cryptographic implementations, algorithms, cipher suites, or modes of operation. • Attacks on business logic, including attempts to abuse or bypass application features and functionalities through the manipulation of APIs, communication protocols and channels, client- side functionality, or other system/application functions and resources. This includes cross-site scripting (XSS) and cross-site request forgery (CSRF). • Attacks on access control mechanisms, including attempts to bypass or abuse identification, authentication, or authorization mechanisms, or attempts to exploit weaknesses in the implementation of such mechanisms. • Attacks via any “high-risk” vulnerabilities identified in the vulnerability identification process, as defined in Requirement 6.3.1. |
Shared | Shared | Inbox Health is responsible for maintaining a secure software development program to support their CDE assets. Inbox Health customers are responsible for maintaining a secure software development program to support their own CDE assets. |
| 87 | 86 | 6.3.1 | 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. |
Shared | Shared | Inbox Health is responsible for maintaining and implementing a process to identify security vulnerabilities and assign risk rankings. Inbox Health customers are responsible for maintaining and implementing a process to identify security vulnerabilities and assign risk rankings in their own CDE. |
| 88 | 87 | 6.3.2 | 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. | Shared | Shared | Inbox Health is responsible for maintaining an inventory of bespoke and custom software and third party software components to faciliate vulnerability and patch management. Inbox Health customers are responsible for maintaining an inventory of bespoke and custom software and third party software components to faciliate vulnerability and patch management. |
| 89 | 88 | 6.3.3 | All system components are protected from known vulnerabilities by installing applicable security patches/updates as follows: • Critical updates (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's assessment of the criticality of the risk to the environment as identified according to the risk ranking process at Requirement 6.3.1 |
Shared | Shared | Inbox Health is responsible for ensuring system assets supporting the CDE are protected against known vulnerabliites by installing applicable vendor patches. Inbox Health customers are responsible for ensuring system assets supporting their CDE are protected against known vulnerabliites by installing applicable vendor patches. |
| 90 | 89 | 6.4.1 | For public-facing web applications, new threats and vulnerabilities are addressed on an ongoing basis and these applications are protected against known attacks as follows: • Reviewing public-facing web applications via manual or automated application vulnerability security assessment tools or methods as follows: – At least once every 12 months and after significant changes. – By an entity that specializes in application security. – Including, at a minimum, all common software attacks in Requirement 6.2.4. – All vulnerabilities are ranked in accordance with requirement 6.3.1. – All vulnerabilities are corrected. – The application is re-evaluated after the corrections OR • Installing an automated technical solution(s) that continually detects and prevents web-based attacks as follows: – Installed in front of public-facing web applications 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. |
Shared | Shared | Inbox Health is responsible for maintaining a WAF solution and or conducting web application penetration testing to protect the CDE. Inbox Health customers are responsible for maintaining the WAF solution and or conducting web application penetration testing to protect their CDE. |
| 91 | 90 | 6.4.2 | 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. |
Shared | Shared | Inbox Health is responsible for maintaining an automated technical solution that detects and prevents web based attacks. Inbox Health customers are responsible for maintaining an automated technical solution that detects and prevents web based attacks. |
| 92 | 91 | 6.4.3 | 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 writtenbusiness or technical justification as to why each is necessary. |
Shared | Shared | Inbox Health is responsible for ensuring that payment page scripts loaded and executed in a Inbox Health owned payment page is authorized, protected, and maintained. Additionally, Inbox Health is responsible for ensuring integrity of Inbox Health provided payment scripts. Inbox Health customers are responsible for ensuring that non-Inbox Health payment page scripts loaded in their own payment page are authorized, protected, and maintained. |
| 93 | 92a | 6.5.1 | 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. |
Shared | Shared | Inbox Health is responsible for maintaining a secure change management program to support the CDE assets. Inbox Health customers are responsible for maintaining a secure change management program to support their CDE assets. |
| 94 | 93a | 6.5.2 | 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. | Shared | Shared | Inbox Health is responsible for maintaining a secure change management program to support the CDE assets. Inbox Health customers are responsible for maintaining a secure change management program to support their CDE assets. |
| 95 | 94a | 6.5.3 | Pre-production environments are separated from production environments and the separation is enforced with access controls. | Shared | Shared | Inbox Health is responsible for maintaining a secure software development program to support their CDE assets. Inbox Health customers are responsible for maintaining a secure software development program to support their own CDE assets. |
| 96 | 95a | 6.5.4 | Roles and functions are separated between production and pre-production environments to provide accountability such that only reviewed and approved changes are deployed. | Shared | Shared | Inbox Health is responsible for maintaining a secure software development program to support their CDE assets. Inbox Health customers are responsible for maintaining a secure software development program to support their own CDE assets. |
| 97 | 96a | 6.5.5 | 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. | Shared | Shared | Inbox Health is responsible for maintaining a secure software development program to support their CDE assets. Inbox Health customers are responsible for maintaining a secure software development program to support their own CDE assets. |
| 98 | 97a | 6.5.6 | Test data and test accounts are removed from system components before the system goes into production. | Shared | Shared | Inbox Health is responsible for maintaining a secure software development program to support their CDE assets. Inbox Health customers are responsible for maintaining a secure software development program to support their own CDE assets. |
| 99 | 98 | 7.1.1 | All security policies and operational procedures that are identified in Requirement 7 are: • Documented. • Kept up to date. • In use. • Known to all affected parties. |
Shared | Shared | Inbox Health is responsible for ensuring that their policies and procedures are documented, up to date and made known to all affected parties. Inbox Health customers are responsible for ensuring that their policies and procedures are documented, up to date and made known to all affected parties. |
| 100 | 99 | 7.1.2 | Roles and responsibilities for performing activities in Requirement 7 are documented, assigned, and understood. | Shared | Shared | Inbox Health is responsible for establishing defined roles and responsibilities to oversee access managament to system components in the CDE. Inbox Health customers are responsible for establishing defined roles and responsibilities to oversee access managament to system components in the CDE. |
| 101 | 100a | 7.2.1 | 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. |
Shared | Shared | Inbox Health is responsible for implementing access control systems within the CDE. Inbox Health customers are responsible for implementing access controls to systems in their own CDE. |
| 102 | 101a | 7.2.2 | Access is assigned to users, including privileged users, based on: • Job classification and function. • Least privileges necessary to perform job responsibilities. |
Shared | Shared | Inbox Health is responsible for implementing access control systems within the CDE. Inbox Health customers are responsible for implementing access controls to systems in their own CDE. |
| 103 | 102a | 7.2.3 | Required privileges are approved by authorized personnel. | Shared | Shared | Inbox Health is responsible for implementing access control systems within the CDE. Inbox Health customers are responsible for implementing access controls to systems in their own CDE. |
| 104 | 103 | 7.2.4 | 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. |
Shared | Shared | Inbox Health is responsible for implementing access control systems within the CDE. Inbox Health customers are responsible for implementing access controls to systems in their own CDE. |
| 105 | 104 | 7.2.5 | 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. |
Shared | Shared | Inbox Health is responsible for implementing access control systems within the CDE. Inbox Health customers are responsible for implementing access controls to systems in their own CDE. |
| 106 | 105 | 7.2.5.1 | 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. |
Shared | Shared | Inbox Health is responsible for implementing access control systems within the CDE. Inbox Health customers are responsible for implementing access controls to systems in their own CDE. |
| 107 | 106 | 7.2.6 | 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. |
Shared | Shared | Inbox Health is responsible for implementing access control systems within the CDE. Inbox Health customers are responsible for implementing access controls to systems in their own CDE. |
| 108 | 107 | 7.3.1 | An access control system(s) is in place that restricts access based on a user’s need to know and covers all system components. | Shared | Shared | Inbox Health is responsible for implementing access control systems within the CDE. Inbox Health customers are responsible for implementing access controls to systems in their own CDE. |
| 109 | 108 | 7.3.2 | The access control system(s) is configured to enforce permissions assigned to individuals, applications, and systems based on job classification and function. | Shared | Shared | Inbox Health is responsible for implementing access control systems within the CDE. Inbox Health customers are responsible for implementing access controls to systems in their own CDE. |
| 110 | 109 | 7.3.3 | The access control system(s) is set to “deny all” by default. | Shared | Shared | Inbox Health is responsible for implementing access control systems within the CDE. Inbox Health customers are responsible for implementing access controls to systems in their own CDE. |
| 111 | 110 | 8.1.1 | All security policies and operational procedures that are identified in Requirement 8 are: • Documented. • Kept up to date. • In use. • Known to all affected parties. |
Shared | Shared | Inbox Health is responsible for ensuring that their policies and procedures are documented, up to date and made known to all affected parties. Inbox Health customers are responsible for ensuring that their policies and procedures are documented, up to date and made known to all affected parties. |
| 112 | 111 | 8.1.2 | Roles and responsibilities for performing activities in Requirement 8 are documented, assigned, and understood. | Shared | Shared | Inbox Health is responsible for establishing defined roles and responsibilities to oversee authentication controls to system components in the CDE. Inbox Health customers are responsible for establishing defined roles and responsibilities to oversee authentication controls to system components in their CDE. |
| 113 | 112 | 8.2.1 | All users are assigned a unique ID before access to system components or cardholder data is allowed. | Shared | Shared | Inbox Health is responsible for implementing and monitoring user identification controls, assigning unique user IDs. Inbox Health customers are responsible for implementing and monitoring user identification controls, assigning unique user IDs. |
| 114 | 113 | 8.2.2 | Group, shared, or generic accounts, 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. |
Shared | Shared | Inbox Health is responsible for implementing and monitoring user identification controls, assigning unique user IDs. Inbox Health customers are responsible for implementing and monitoring user identification controls, assigning unique user IDs. |
| 115 | 114 | 8.2.3 | Additional requirement for service providers only: Service providers with remote access to customer premises use unique authentication factors for each customer premises. | Shared | Shared | Inbox Health customers are responsible for monitoring remote access to their customers. |
| 116 | 115 | 8.2.4 | 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. |
Shared | Shared | Inbox Health is responsible for implementing and monitoring user identification controls, assigning unique user IDs. Inbox Health customers are responsible for implementing and monitoring user identification controls, assigning unique user IDs. |
| 117 | 116 | 8.2.5 | Access for terminated users is immediately revoked. | Shared | Shared | Inbox Health is responsible for implementing and monitoring user identification controls, revoking user access when no longer necessary. Inbox Health customers are responsible for implementing and monitoring user identification controls, revoking user access when no longer necessary. |
| 118 | 117 | 8.2.6 | Inactive user accounts are removed or disabled within 90 days of inactivity. | Shared | Shared | Inbox Health is responsible for implementing and monitoring user identification controls, assigning unique user IDs. Inbox Health customers are responsible for implementing and monitoring user identification controls, assigning unique user IDs. |
| 119 | 118 | 8.2.7 | 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. |
Shared | Shared | Inbox Health customers are responsible for implementing and monitoring user identification controls, third party access to their CDE. |
| 120 | 119 | 8.2.8 | 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. | Shared | Shared | Inbox Health is responsible for maintaining a password policy compliant with PCI DSS requirements. Inbox Health customers are responsible for maintaining a password policy compliant with PCI DSS requirements. |
| 121 | 120 | 8.3.1 | 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. |
Shared | Shared | Inbox Health is responsible for implementing and monitoring user identification controls, assigning multi-factor authentication mechanisms. Inbox Health customers are responsible for implementing and monitoring user identification controls, assigning multi-factor authentication mechanisms. |
| 122 | 121 | 8.3.2 | Strong cryptography is used to render all authentication factors unreadable during transmission and storage on all system components. | Shared | Shared | Inbox Health is responsible for implementing and maintaining security of user identification controls. Inbox Health customers are responsible for implementing security of user identification controls. |
| 123 | 122 | 8.3.3 | User identity is verified before modifying any authentication factor. | Shared | Shared | Inbox Health is responsible for maintaining and modification of user authentication credentials. Inbox Health customers are responsible for maintaining and modification of user authentication credentials. |
| 124 | 123 | 8.3.4 | 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. |
Shared | Shared | Inbox Health is responsible for maintaining a password policy compliant with PCI DSS requirements. Inbox Health customers are responsible for maintaining a password policy compliant with PCI DSS requirements. |
| 125 | 124 | 8.3.5 | 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. |
Shared | Shared | Inbox Health is responsible for maintaining user identification controls. Inbox Health customers are responsible for maintaining user identification controls. |
| 126 | 125 | 8.3.6 | 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. |
Shared | Shared | Inbox Health is responsible for maintaining a password policy compliant with PCI DSS requirements. Inbox Health customers are responsible for maintaining a password policy compliant with PCI DSS requirements. |
| 127 | 126 | 8.3.7 | Individuals are not allowed to submit a new password/passphrase that is the same as any of the last four passwords/passphrases used. | Shared | Shared | Inbox Health is responsible for maintaining a password policy compliant with PCI DSS requirements. Inbox Health customers are responsible for maintaining a password policy compliant with PCI DSS requirements. |
| 128 | 127 | 8.3.8 | 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. |
Shared | Shared | Inbox Health is responsible for maintaining authentication procedures and disseminating them to all users in the CDE. Inbox Health customers are responsible for maintaining authentication procedures and disseminating them to all users in their CDE. |
| 129 | 128 | 8.3.9 | 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. |
Shared | Shared | Inbox Health is responsible for maintaining a password policy compliant with PCI DSS requirements. Inbox Health customers are responsible for maintaining a password policy compliant with PCI DSS requirements. |
| 130 | 129 | 8.3.10 | 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. |
Shared | Shared | Inbox Health customers are responsible for maintaining customer user access to CHD. |
| 131 | 130 | 8.3.10.1 | 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. |
Shared | Shared | Inbox Health customers are responsible for maintaining customer user access to CHD. |
| 132 | 131 | 8.3.11 | 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. |
Shared | Shared | Inbox Health is responsible for maintaining multi-factor authentication controls in the CDE. Inbox Health customers are responsible for maintaining multi-factor authentication controls in their CDE |
| 133 | 132 | 8.4.1 | MFA is implemented for all non-console access into the CDE for personnel with administrative access. | Shared | Shared | Inbox Health is responsible for maintaining multi-factor authentication controls in the CDE. Inbox Health customers are responsible for maintaining multi-factor authentication controls in their CDE |
| 134 | 133 | 8.4.2 | MFA is implemented for all non-console access into the CDE. | Shared | Shared | Inbox Health is responsible for maintaining multi-factor authentication controls in the CDE. Inbox Health customers are responsible for maintaining multi-factor authentication controls in their CDE |
| 135 | 134 | 8.4.3 | MFA is implemented for all remote network access originating from outside the entity’s network that could access or impact the CDE as follows: | Shared | Shared | Inbox Health is responsible for maintaining multi-factor authentication controls in the CDE. Inbox Health customers are responsible for maintaining multi-factor authentication controls in their CDE |
| 136 | 135 | 8.5.1 | 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. |
Shared | Shared | Inbox Health is responsible for maintaining multi-factor authentication controls in the CDE. Inbox Health customers are responsible for maintaining multi-factor authentication controls in their CDE |
| 137 | 136 | 8.6.1 | 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. |
Shared | Shared | Inbox Health is responsible for maintaining authentication and authorization controls within the CDE. Inbox Health customers are responsible for maintaining authentication and authorization controls within their CDE. |
| 138 | 137 | 8.6.2 | 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. | Shared | Shared | Inbox Health is responsible for maintaining authentication and authorization controls within the CDE. Inbox Health customers are responsible for maintaining authentication and authorization controls within their CDE. |
| 139 | 138 | 8.6.3 | 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. |
Shared | Shared | Inbox Health is responsible for maintaining authentication and authorization controls within the CDE. Inbox Health customers are responsible for maintaining authentication and authorization controls within their CDE. |
| 140 | 139 | 9.1.1 | All security policies and operational procedures that are identified in Requirement 9 are: • Documented. • Kept up to date. • In use. • Known to all affected parties. |
Shared | Shared | Inbox Health is responsible for ensuring that their policies and procedures are documented, up to date and made known to all affected parties. Inbox Health customers are responsible for ensuring that their policies and procedures are documented, up to date and made known to all affected parties. |
| 141 | 140 | 9.1.2 | Roles and responsibilities for performing activities in Requirement 9 are documented, assigned, and understood. | Shared | Shared | Inbox Health is responsible for establishing defined roles and responsibilities to oversee physical access controls in the CDE. Inbox Health customers are responsible for establishing defined roles and responsibilities to oversee physical access controls in the CDE. |
| 142 | 141 | 9.2.1 | Appropriate facility entry controls are in place to restrict physical access to systems in the CDE. | Shared | Shared | Inbox Health is responsible for physical security controls on all data centers supporting the CDE. Inbox Health customers are responsibile for the physical security controls on all data centers supporting their CDE. |
| 143 | 142 | 9.2.1.1 | 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 and 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. |
Shared | Shared | Inbox Health is responsible for physical security controls on all data centers supporting the CDE. Inbox Health customers are responsibile for the physical security controls on all data centers supporting their CDE.. |
| 144 | 143 | 9.2.2 | Physical and/or logical controls are implemented to restrict use of publicly accessible network jacks within the facility. | Shared | Shared | Inbox Health is responsible for physical security controls on all data centers supporting the CDE. Inbox Health customers are responsibile for the physical security controls on all data centers supporting their CDE. |
| 145 | 144 | 9.2.3 | Physical access to wireless access points, gateways, networking/communications hardware, and telecommunication lines within the facility is restricted. | Shared | Shared | Inbox Health is responsible for physical security controls on all data centers supporting the CDE. Inbox Health customers are responsibile for the physical security controls on all data centers supporting their CDE. |
| 146 | 145 | 9.2.4 | Access to consoles in sensitive areas is restricted via locking when not in use. | Shared | Shared | Inbox Health is responsible for physical security controls on all data centers supporting the CDE. Inbox Health customers are responsibile for the physical security controls on all data centers supporting their CDE. |
| 147 | 146 | 9.3.1 | 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 identification. • Limiting access to the identification process or system to authorized personnel. |
Shared | Shared | Inbox Health is responsible for physical security controls on all data centers supporting the CDE. Inbox Health customers are responsibile for the physical security controls on all data centers supporting their CDE. |
| 148 | 147 | 9.3.1.1 | 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. |
Shared | Shared | Inbox Health is responsible for physical security controls on all data centers supporting the CDE. Inbox Health customers are responsibile for the physical security controls on all data centers supporting their CDE. |
| 149 | 148a | 9.3.2 | Procedures are implemented for authorizing and managing visitor access to the CDE, including: • Visitors are authorized before entering. • Visitors are escorted at all times. • Visitors are clearly identified and given a badge or other identification that expires. • Visitor badges or other identification visibly distinguishes visitors from personnel. |
Shared | Shared | Inbox Health is responsible for physical security controls on all data centers supporting the CDE. Inbox Health customers are responsibile for the physical security controls on all data centers supporting their CDE. |
| 150 | 148a | 9.3.2 | Procedures are implemented for authorizing and managing visitor access to the CDE, including: • Visitors are authorized before entering. • Visitors are escorted at all times. • Visitors are clearly identified and given a badge or other identification that expires. • Visitor badges or other identification visibly distinguishes visitors from personnel. |
Shared | Shared | Inbox Health is responsible for physical security controls on all data centers supporting the CDE. Inbox Health customers are responsibile for the physical security controls on all data centers supporting their CDE. |
| 151 | 148a | 9.3.2 | Procedures are implemented for authorizing and managing visitor access to the CDE, including: • Visitors are authorized before entering. • Visitors are escorted at all times. • Visitors are clearly identified and given a badge or other identification that expires. • Visitor badges or other identification visibly distinguishes visitors from personnel. |
Shared | Shared | Inbox Health is responsible for physical security controls on all data centers supporting the CDE. Inbox Health customers are responsibile for the physical security controls on all data centers supporting their CDE. |
| 152 | 148a | 9.3.2 | Procedures are implemented for authorizing and managing visitor access to the CDE, including: • Visitors are authorized before entering. • Visitors are escorted at all times. • Visitors are clearly identified and given a badge or other identification that expires. • Visitor badges or other identification visibly distinguishes visitors from personnel. |
Shared | Shared | Inbox Health is responsible for physical security controls on all data centers supporting the CDE. Inbox Health customers are responsibile for the physical security controls on all data centers supporting their CDE. |
| 153 | 149 | 9.3.3 | Visitor badges or identification are surrendered or deactivated before visitors leave the facility or at the date of expiration. | Shared | Shared | Inbox Health is responsible for physical security controls on all data centers supporting the CDE. Inbox Health customers are responsibile for the physical security controls on all data centers supporting their CDE. |
| 154 | 150 | 9.3.4 | Visitor logs are used to maintain a physical record of visitor activity both within the facility and within sensitive areas, including: • The visitor’s name and the organization represented. • The date and time of the visit. • The name of the personnel authorizing physical access. • Retaining the log for at least three months, unless otherwise restricted by law. |
Shared | Shared | Inbox Health is responsible for physical security controls on all data centers supporting the CDE. Inbox Health customers are responsibile for the physical security controls on all data centers supporting their CDE. |
| 155 | 151 | 9.4.1 | All media with cardholder data is physically secured. | Shared | Shared | Inbox Health customers are responsible for storage of media in their own CDE. |
| 156 | 152 | 9.4.1.1 | Offline media backups with cardholder data are stored in a secure location. | Shared | Shared | Inbox Health customers are responsible for storage of media in their own CDE. |
| 157 | 153 | 9.4.1.2 | The security of the offline media backup location(s) with cardholder data is reviewed at least once every 12 months. | Shared | Shared | Inbox Health customers are responsible for storage of media in their own CDE. |
| 158 | 154 | 9.4.2 | All media with cardholder data is classified in accordance with the sensitivity of the data. | Shared | Shared | Inbox Health customers are responsible for storage of media in their own CDE |
| 159 | 155 | 9.4.3 | 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. |
Shared | Shared | Inbox Health customers are responsible for storage of media in their own CDE |
| 160 | 156 | 9.4.4 | Management approves all media with cardholder data that is moved outside the facility (including when media is distributed to individuals). | Shared | Shared | Inbox Health customers are responsible for storage of media in their own CDE |
| 161 | 157 | 9.4.5 | Inventory logs of all electronic media with cardholder data are maintained. | Shared | Shared | Inbox Health customers are responsible for storage of media in their own CDE |
| 162 | 158 | 9.4.5.1 | Inventories of electronic media with cardholder data are conducted at least once every 12 months. | Shared | Shared | Inbox Health customers are responsible for storage of media in their own CDE |
| 163 | 159 | 9.4.6 | Hard-copy materials with cardholder data are destroyed when no longer needed for business or legal reasons, as follows: • Materials are cross-cut shredded, incinerated, or pulped so that cardholder data cannot be reconstructed. • Materials are stored in secure storage containers prior to destruction. |
Shared | Shared | Inbox Health customers are responsible for storage of media in their own CDE |
| 164 | 160a | 9.4.7 | Electronic media with cardholder data is destroyed when no longer needed for business or legal reasons via one of the following: • The electronic media is destroyed. • The cardholder data is rendered unrecoverable so that it cannot be reconstructed. |
Shared | Shared | Inbox Health customers are responsible for storage of media in their own CDE |
| 165 | 160b | 9.4.7 | Electronic media with cardholder data is destroyed when no longer needed for business or legal reasons via one of the following: • The electronic media is destroyed. • The cardholder data is rendered unrecoverable so that it cannot be reconstructed. |
Shared | Shared | Inbox Health customers are responsible for storage of media in their own CDE |
| 166 | 161 | 9.5.1 | 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. |
Responsible | Not Responsible | Inbox Health customers are responsible for maintenance and protection of devices that capture payment card data via direct physical interaction with the card. |
| 167 | 162 | 9.5.1.1 | 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 methods of unique identification. |
Responsible | Not Responsible | Inbox Health customers are responsible for maintenance and protection of devices that capture payment card data via direct physical interaction with the card. |
| 168 | 163 | 9.5.1.2 | POI device surfaces are periodically inspected to detect tampering and unauthorized substitution. | Responsible | Not Responsible | Inbox Health customers are responsible for maintenance and protection of devices that capture payment card data via direct physical interaction with the card. |
| 169 | 164 | 9.5.1.2.1 | 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. | Responsible | Not Responsible | Inbox Health customers are responsible for maintenance and protection of devices that capture payment card data via direct physical interaction with the card. |
| 170 | 165 | 9.5.1.3 | Training is provided for personnel in POI environments to be aware of attempted tampering or replacement of POI devices, and includes: • Verifying the identity of any third-party persons claiming to be repair or maintenance personnel, before granting them access to modify or troubleshoot devices. • Procedures to ensure devices are not installed, replaced, or returned without verification. • Being aware of suspicious behavior around devices. • Reporting suspicious behavior and indications of device tampering or substitution to appropriate personnel. |
Responsible | Not Responsible | Inbox Health customers are responsible for maintenance and protection of devices that capture payment card data via direct physical interaction with the card. |
| 171 | 166 | 10.1.1 | All security policies and operational procedures that are identified in Requirement 10 are: • Documented. • Kept up to date. • In use. • Known to all affected parties. |
Shared | Shared | Inbox Health is responsible for ensuring that their policies and procedures are documented, up to date and made known to all affected parties. Inbox Health customers are responsible for ensuring that their policies and procedures are documented, up to date and made known to all affected parties. |
| 172 | 167 | 10.1.2 | Roles and responsibilities for performing activities in Requirement 10 are documented, assigned, and understood. | Shared | Shared | Inbox Health is responsible for establishing defined roles and responsibilities to oversee log management and audit trails for system components in the CDE. Inbox Health customers are responsible for establishing defined roles and responsibilities to oversee log management and audit trails for system components in their CDE. |
| 173 | 168 | 10.2.1 | Audit logs are enabled and active for all system components and cardholder data. | Shared | Shared | Inbox Health is responsible for maintaining audit logs for all systems in the CDE. Inbox Health customers are responsbile for maintaining audit logs for user activity to their CDE. |
| 174 | 169 | 10.2.1.1 | Audit logs capture all individual user access to cardholder data. | Shared | Shared | Inbox Health is responsible for maintaining audit logs for all systems in the CDE. Inbox Health customers are responsbile for maintaining audit logs for user activity to their CDE. |
| 175 | 170 | 10.2.1.2 | Audit logs capture all actions taken by any individual with administrative access, including any interactive use of application or system accounts. | Shared | Shared | Inbox Health is responsible for maintaining audit logs for all systems in the CDE. Inbox Health customers are responsbile for maintaining audit logs for user activity to their CDE. |
| 176 | 171 | 10.2.1.3 | Audit logs capture all access to audit logs. | Shared | Shared | Inbox Health is responsible for maintaining audit logs for all systems in the CDE. Inbox Health customers are responsbile for maintaining audit logs for user activity to their CDE. |
| 177 | 172 | 10.2.1.4 | Audit logs capture all invalid logical access attempts. | Shared | Shared | Inbox Health is responsible for maintaining audit logs for all systems in the CDE. Inbox Health customers are responsbile for maintaining audit logs for user activity to their CDE. |
| 178 | 173 | 10.2.1.5 | 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. |
Shared | Shared | Inbox Health is responsible for maintaining audit logs for all systems in the CDE. Inbox Health customers are responsbile for maintaining audit logs for user activity to their CDE. |
| 179 | 174 | 10.2.1.6 | Audit logs capture the following: • All initialization of new audit logs, and • All starting, stopping, or pausing of the existing audit logs. |
Shared | Shared | Inbox Health is responsible for maintaining audit logs for all systems in the CDE. Inbox Health customers are responsbile for maintaining audit logs for user activity to their CDE. |
| 180 | 175 | 10.2.1.7 | Audit logs capture all creation and deletion of system-level objects. | Shared | Shared | Inbox Health is responsible for maintaining audit logs for all systems in the CDE. Inbox Health customers are responsbile for maintaining audit logs for user activity to their CDE. |
| 181 | 176a | 10.2.2 | 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). |
Shared | Shared | Inbox Health is responsible for maintaining audit logs for all systems in the CDE. Inbox Health customers are responsbile for maintaining audit logs for user activity to their CDE. |
| 182 | 177a | 10.3.1 | Read access to audit logs files is limited to those with a job-related need. | Shared | Shared | Inbox Health is responsible for maintaining and securing audit logs for all systems in the CDE. Inbox Health customers are responsbile for maintaining and securing audit logs for all systems in their CDE. |
| 183 | 178a | 10.3.2 | Audit log files are protected to prevent modifications by individuals. | Shared | Shared | Inbox Health is responsible for maintaining and securing audit logs for all systems in the CDE. Inbox Health customers are responsbile for maintaining and securing audit logs for all systems in their CDE. |
| 184 | 179a | 10.3.3 | 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. | Shared | Shared | Inbox Health is responsible for maintaining and securing audit logs for all systems in the CDE. Inbox Health customers are responsbile for maintaining and securing audit logs for all systems in their CDE. |
| 185 | 180a | 10.3.4 | File integrity monitoring or change-detection mechanisms is used on audit logs to ensure that existing log data cannot be changed without generating alerts. | Shared | Shared | Inbox Health is responsible for maintaining and securing audit logs for all systems in the CDE. Inbox Health customers are responsbile for maintaining and securing audit logs for all systems in their CDE. |
| 186 | 181a | 10.4.1 | 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, network security controls, intrusion-detection systems/intrusion-prevention systems (IDS/IPS), authentication servers). |
Shared | Shared | Inbox Health is responsible for maintaining and reviewing of audit logs for all systems in the CDE. Inbox Health customers are responsbile for maintaining and reviewing of audit logs for all systems in their CDE. |
| 187 | 182 | 10.4.1.1 | Automated mechanisms are used to perform audit log reviews. | Shared | Shared | Inbox Health is responsible for maintaining and reviewing of audit logs for all systems in the CDE. Inbox Health customers are responsbile for maintaining andreviewing of audit logs for all systems in their CDE. |
| 188 | 183 | 10.4.2 | Logs of all other system components (those not specified in Requirement 10.4.1) are reviewed periodically. | Shared | Shared | Inbox Health is responsible for maintaining and reviewing of audit logs for all systems in the CDE. Inbox Health customers are responsbile for maintaining andreviewing of audit logs for all systems in their CDE. |
| 189 | 184 | 10.4.2.1 | 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 | Shared | Shared | Inbox Health is responsible for maintaining and reviewing of audit logs for all systems in the CDE. Inbox Health customers are responsbile for maintaining andreviewing of audit logs for all systems in their CDE. |
| 190 | 185 | 10.4.3 | Exceptions and anomalies identified during the review process are addressed. | Shared | Shared | Inbox Health is responsible for maintaining and reviewing of audit logs for all systems in the CDE. Inbox Health customers are responsbile for maintaining andreviewing of audit logs for all systems in their CDE. |
| 191 | 186 | 10.5.1 | Retain audit log history for at least 12 months, with at least the most recent three months immediately available for analysis. | Shared | Shared | Inbox Health is responsible for retention of audit logs in the CDE. Inbox Health customers are responsbile for retention of audit logs in their CDE. |
| 192 | 187a | 10.6.1 | System clocks and time are synchronized using time-synchronization technology. | Shared | Shared | Inbox Health is responsible for maintaining time synchronization for all systems in the CDE. Inbox Health customers are responsbile for maintaining time synchronization in their CDE. |
| 193 | 188a | 10.6.2 | 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). |
Shared | Shared | Inbox Health is responsible for maintaining time synchronization for all systems in the CDE. Inbox Health customers are responsbile for maintaining time synchronization in their CDE. |
| 194 | 189a | 10.6.3 | 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. |
Shared | Shared | Inbox Health is responsible for maintaining time synchronization for all systems in the CDE. Inbox Health customers are responsbile for maintaining time synchronization in their CDE. |
| 195 | 190 | 10.7.1 | 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 the following critical security control systems: • Network security controls. • IDS/IPS. • FIM. • Anti-malware solutions. • Physical access controls. • Logical access controls. • Audit logging mechanisms. • Segmentation controls (if used). |
Shared | Shared | Inbox Health is responsible for monitoring of critical security control systems in the CDE. Inbox Health customers are responsbile for monitoring of critical security control systems in their CDE. |
| 196 | 191 | 10.7.2 | Failures of critical security control systems are detected, alerted, and addressed promptly, including but not limited to failure of the following critical security control systems: • Network security controls. • IDS/IPS. • Change-detection mechanisms. • Anti-malware solutions. • Physical access controls. • Logical access controls. • Audit logging mechanisms. • Segmentation controls (if used). • Audit log review mechanisms. • Automated security testing tools (if used). |
Shared | Shared | Inbox Health is responsible for monitoring of critical security control systems in the CDE. Inbox Health customers are responsbile for monitoring of critical security control systems in their CDE. |
| 197 | 192 | 10.7.3 | Failures of any critical security controls 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 reoccurring. • Resuming monitoring of security controls. |
Shared | Shared | Inbox Health is responsible for monitoring of critical security control systems in the CDE. Inbox Health customers are responsbile for monitoring of critical security control systems in their CDE. |
| 198 | 193 | 11.1.1 | All security policies and operational procedures that are identified in Requirement 11 are: • Documented. • Kept up to date. • In use. • Known to all affected parties. |
Shared | Shared | Inbox Health is responsible for ensuring that their policies and procedures are documented, up to date and made known to all affected parties. Inbox Health customers are responsible for ensuring that their policies and procedures are documented, up to date and made known to all affected parties. |
| 199 | 194 | 11.1.2 | Roles and responsibilities for performing activities in Requirement 11 are documented, assigned, and understood. | Shared | Shared | Inbox Health is responsible for establishing defined roles and responsibilities to oversee testing of security of all systems and networks in the CDE. Inbox Health customers are responsible for establishing defined roles and responsibilities to oversee testing of security of all systems and networks in their CDE. |
| 200 | 195 | 11.2.1 | 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. • If automated monitoring is used, personnel are notified via generated alerts. |
Shared | Shared | Inbox Health is responsible for performing rogue wireless detection in the CDE. Inbox Health customers are responsible for performing rogue wireless detection for their own CDE. |
| 201 | 196 | 11.2.2 | An inventory of authorized wireless access points is maintained, including a documented business justification. | Shared | Shared | Inbox Health is responsible for performing rogue wireless detection in the CDE. Inbox Health customers are responsible for performing rogue wireless detection for their own CDE. |
| 202 | 197 | 11.3.1 | Internal vulnerability scans are performed as follows: • At least once every three months. • Vulnerabilities that are either high-risk or 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 (as noted above) 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. |
Shared | Shared | Inbox Health performs quarterly internal vulnerability scans for the CDE. Inbox Health customers are responsible for performing internal vulnerability scans for their in-scope CDE. |
| 203 | 198 | 11.3.1.1 | All other applicable vulnerabilities (those not ranked as high-risk or critical according to 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. |
Shared | Shared | Inbox Health performs quarterly internal vulnerability scans for the CDE. Inbox Health customers are responsible for performing internal vulnerability scans for their in-scope CDE. |
| 204 | 199 | 11.3.1.2 | Internal vulnerability scans are performed via authenticated scanning as follows: • Systems that are unable to accept credentials for authenticated scanning are documented. • Sufficient privileges are used for those systems that accept credentials for scanning. • If accounts used for authenticated scanning can be used for interactive login, they are managed in accordance with Requirement 8.2.2. |
Shared | Shared | Inbox Health performs quarterly internal vulnerability scans for the CDE. Inbox Health customers are responsible for performing internal vulnerability scans for their in-scope CDE. |
| 205 | 200 | 11.3.1.3 | Internal vulnerability scans are performed after any significant change as follows: • Vulnerabilities that are either high-risk or critical (according to the entity’s vulnerability risk rankings defined at Requirement 6.3.1) are resolved. • Rescans are conducted as needed. • Scans are performed by qualified personnel and organizational independence of the tester exists (not required to be a QSA or ASV). |
Shared | Shared | Inbox Health performs quarterly internal vulnerability scans for the CDE. Inbox Health customers are responsible for performing internal vulnerability scans for their in-scope CDE. |
| 206 | 201 | 11.3.2 | 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. |
Shared | Shared | Inbox Health performs quarterly external vulnerability scans for the Cardholder data environment (CDE). Inbox Health customers are responsible for performing external vulnerability scans for their in-scope environment (Per SAQ-A, SAQ-AEP scope requiprements) and/or their cardholder data environment (CDE). |
| 207 | 202 | 11.3.2.1 | External vulnerability scans are performed after any significant change as follows: • Vulnerabilities that are scored 4.0 or higher by the CVSS are resolved. • Rescans are conducted as needed. • Scans are performed by qualified personnel and organizational independence of the tester exists (not required to be a QSA or ASV). |
Shared | Shared | Inbox Health performs quarterly external vulnerability scans for the CDE. Inbox Health customers are responsible for performing external vulnerability scans for their in-scope CDE. |
| 208 | 203 | 11.4.1 | A penetration testing methodology is defined, documented, and implemented 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. • Documented approach to assessing and addressing the risk posed by exploitable vulnerabilities and security weaknesses found during penetration testing. • Retention of penetration testing results and remediation activities results for at least 12 months. |
Shared | Shared | Inbox Health is responsible for performing penetration testing for their in-scope environment, including internal testing, external testing, application layer testing and network layer testing on an annual basis, for the CDE. Inbox Health customers are responsible for performing penetration testing for their in-scope environment, including internal testing, external testing, application layer testing and network layer testing on an annual basis. |
| 209 | 204 | 11.4.2 | 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 • By a qualified internal resource or qualified external third-party • Organizational independence of the tester exists (not required to be a QSA or ASV). |
Shared | Shared | Inbox Health is responsible for performing penetration testing for their in-scope environment, including internal testing, external testing, application layer testing and network layer testing on an annual basis, for the CDE. Inbox Health customers are responsible for performing penetration testing for their in-scope environment, including internal testing, external testing, application layer testing and network layer testing on an annual basis. |
| 210 | 205 | 11.4.3 | 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 • By a qualified internal resource or qualified external third party • Organizational independence of the tester exists (not required to be a QSA or ASV). |
Shared | Shared | Inbox Health is responsible for performing penetration testing for their in-scope environment, including internal testing, external testing, application layer testing and network layer testing on an annual basis, for the CDE. Inbox Health customers are responsible for performing penetration testing for their in-scope environment, including internal testing, external testing, application layer testing and network layer testing on an annual basis. |
| 211 | 206 | 11.4.4 | 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. |
Shared | Shared | Inbox Health is responsible for ensuring exploitable vulnerabilities observed during penetration tests are corrected and testing is reperated to verify the corrections. Inbox Health customers are responsible for ensuring exploitable vulnerabilities observed during penetration tests are corrected and testing is reperated to verify the corrections. |
| 212 | 207 | 11.4.5 | 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 (see Requirement 2.2.3). • Performed by a qualified internal resource or qualified external third party. • Organizational independence of the tester exists (not required to be a QSA or ASV). |
Shared | Shared | Inbox Health is responsible for performing penetration testing, including segmentation validation. Inbox Health customers are responsible for performing penetration testing, including segmentation validation. |
| 213 | 208 | 11.4.6 | 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 (see Requirement 2.2.3). • Performed by a qualified internal resource or qualified external third party. • Organizational independence of the tester exists (not required to be a QSA or ASV). |
Shared | Shared | Inbox Health is responsible for performing penetration testing, including segmentation validation on a bi-annual basis for the CDE. Inbox Health customers are responsible for performing penetration testing including segmentation validation on a bi-annual basis for their CDE. |
| 214 | 209 | 11.4.7 | 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. | Shared | Shared | Reporting responsibilities are limited to service providers. This bullet is a best practice until its effective date; refer to Applicability Notes below for details. |
| 215 | 210 | 11.5.1 | 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. |
Shared | Shared | Inbox Health is responsible for maintaining IDS (intrusion detection) solutions in the CDE. Inbox Health customers are responsible for maintaining IDS solutions in their CDE. |
| 216 | 211 | 11.5.1.1 | Additional requirement for service providers only: Intrusion-detection and/or intrusion-prevention techniques detect, alert on/prevent, and address covert malware communication channels. | Shared | Shared | Inbox Health is responsible for maintaining IDS (intrusion detection) solutions in the CDE. Inbox Health customers are responsible for maintaining IDS solutions in their CDE. This bullet is a best practice until its effective date; refer to Applicability Notes below for details. |
| 217 | 212 | 11.5.2 | 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. • To perform critical file comparisons at least once weekly. |
Shared | Shared | Inbox Health is responsible for maintaining FIM/change detection solutions in the CDE. Inbox Health customers are responsible for maintaining FIM solutions in their CDE. |
| 218 | 213 | 11.6.1 | 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 security-impacting HTTP headers and the script contents of payment pages as received by the consumer browser. • The mechanism is configured to evaluate the received HTTP header and payment page. • The mechanism functions are performed as follows: – At least weekly OR – 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). |
Shared | Shared | Inbox Health is responsible for maintaining FIM/change detection solutions on Inbox Health owned payment pages. Additionally, Inbox Health is responsible for ensuring the integrity of Inbox Health provided payment page scripts on user-hosted payment pages through our evergreen deployment model. Inbox Health customers are responsible for maintaining FIM/change detection solutions on their own payment pages including any non-Inbox Health provided payment scripts. This bullet is a best practice until its effective date; refer to Applicability Notes below for details. |
| 219 | 214 | 12.1.1 | An overall information security policy is: • Established. • Published. • Maintained. • Disseminated to all relevant personnel, as well as to relevant vendors and business partners. |
Shared | Shared | Inbox Health establishes and maintain an information security policy. Inbox Health customers are responsible to establish and maintain an information security policy. |
| 220 | 215 | 12.1.2 | 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. |
Shared | Shared | Inbox Health reviews and update the information security policy atleast annually or when there are changes to the CDE. Inbox Health customers are responsible to review and update the information security policy atleast annually or when there are changes to the CDE. |
| 221 | 216 | 12.1.3 | 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. | Shared | Shared | Inbox Health is responsible to maintain policies that define information security roles and responsibilities. Inbox Health customers are responsible to maintain policies that define information security roles and responsibilities. |
| 222 | 217a | 12.1.4 | Responsibility for information security is formally assigned to a Chief Information Security Officer or other information security knowledgeable member of executive management. | Shared | Shared | Inbox Health is responsible to maintain policies that define information security roles and responsibilities. Inbox Health customers are responsible to maintain policies that define information security roles and responsibilities. |
| 223 | 218a | 12.2.1 | 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. |
Shared | Shared | Inbox Health establishes and maintains acceptable usage policies. Inbox Health customers are responsible to maintain acceptable usage policies. |
| 224 | 219 | 12.3.1 | For 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. • Review of each targeted risk analysis at least once every 12 months to determine whether the results are still valid or if an updated risk analysis is needed. • Performance of updated risk analyses when needed, as determined by the annual review. |
Shared | Shared | Inbox Health is responsible for performing targeted risk analyses is support of applicable control requirements with organization-defined periodicity. Inbox Health customers are responsible for performing targeted risk analyses supporting their own CDE. |
| 225 | 220 | 12.3.2 | A targeted risk analysis is performed for each PCI DSS requirement that the entity meets with the customized approach, to include: • Documented evidence detailing each element specified in Appendix D: Customized Approach (including, at a minimum, a controls matrix and risk analysis). • Approval of documented evidence by senior management. • Performance of the targeted analysis of risk at least once every 12 months. |
Shared | Shared | Inbox Health customers are responsible for performing targeted risk analyses is support of applicable control requirements with the customized approach. |
| 226 | 221 | 12.3.3 | 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. • Documetation of a plan, to respond to anticipated changes in cryptographic vulnerabilities. |
Shared | Shared | Inbox Health is responsible for encryption and key management processess related to CHD stored within their CDE. Inbox Health customers are responsible for encryption and key management processess related to CHD stored within their own CDE. |
| 227 | 222 | 12.3.4 | 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. |
Shared | Shared | Inbox Health is responsible for maintaining and reviewing the hardware and software technologies supporting the CDE. Inbox Health customers are responsible for maintaining and reviewing the hardware and software technologies supporting the CDE. |
| 228 | 223 | 12.4.1 | Additional requirement for service providers only: Responsibility is established by executive management for the protection of cardholder data and a PCI DSS compliance program to include: • Overall accountability for maintaining PCI DSS compliance. • Defining a charter for a PCI DSS compliance program and communication to executive management. |
Shared | Shared | Inbox Health is responsible to maintain policies that define information security roles and responsibilities. Inbox Health customers are responsible to maintain policies that define information security roles and responsibilities. |
| 229 | 224 | 12.4.2 | 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. Reviews are performed by personnel other than those responsible for performing the given task and include, but are not limited to, the following tasks: • Daily log reviews. • Configuration reviews for network security controls. • Applying configuration standards to new systems. • Responding to security alerts. • Change-management processes. |
Shared | Shared | Inbox Health is responsible for documenting their reviews of processess for adhering to PCI compliance controls. Inbox Health customers who are Service Providers are responsible for documenting their reviews of processess for adhering to PCI compliance controls. |
| 230 | 225 | 12.4.2.1 | 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 at Requirement 12.4.2. • Review and sign-off of results by personnel assigned responsibility for the PCI DSS compliance program. |
Shared | Shared | Inbox Health is responsible for documenting their reviews of processess for adhering to PCI compliance controls. Inbox Health customers who are Service Providers are responsible for documenting their reviews of processess for adhering to PCI compliance controls. |
| 231 | 226 | 12.5.1 | An inventory of system components that are in scope for PCI DSS, including a description of function/use, is maintained and kept current. | Shared | Shared | Inbox Health is responsible for maintaining inventory of system assets supporting the CDE. Inbox Health customers are responsible for maintaining inventory of system assets supporting their own CDE. |
| 232 | 227 | 12.5.2 | 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. At a minimum, the scoping validation includes: • Identifying all data flows for the various payment stages (for example, authorization, capture settlement, chargebacks, and refunds) and acceptance channels (for example, card-present, card-not-present, and e-commerce). • Updating all data-flow diagrams per Requirement 1.2.4. • Identifying all locations where account data is stored, processed, and transmitted, including but not limited to: 1) any locations outside of the currently defined CDE, 2) applications that process CHD, 3) transmissions between systems and networks, and 4) file backups. • Identifying all system components in the CDE, connected to the CDE, or that could impact security of the CDE. • Identifying all segmentation controls in use and the environment(s) from which the CDE is segmented, including justification for environments being out of scope. • Identifying all connections from third-party entities with access to the CDE. • Confirming that all identified data flows, account data, system components, segmentation controls, and connections from third parties with access to the CDE are included in scope. |
Shared | Shared | Inbox Health is responsible for performing scope validation activities in accordance with the PCI DSS. Inbox Health customers are responsible for performing scope validation activities for their own environments. |
| 233 | 228 | 12.5.2.1 | 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. At a minimum, the scoping validation includes all the elements specified in Requirement 12.5.2. | Shared | Shared | Inbox Health is responsible for performing scope validation activities in accordance with PCI DSS. Inbox Health customers are responsible for performing scope validation activities in accordance with PCI DSS. |
| 234 | 229 | 12.5.3 | 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, with results communicated to executive management. | Shared | Shared | Inbox Health is responsible for performing scope validation activities in accordance with PCI DSS. Inbox Health customers are responsible for performing scope validation activities in accordance with PCI DSS. |
| 235 | 230 | 12.6.1 | 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 the cardholder data. | Shared | Shared | Inbox Health is responsible for maintaining security awareness processes for personnel with access to the CDE. Inbox Health customers are responsible for maintaining security awareness processes for personnel with access to their own CDE. |
| 236 | 231 | 12.6.2 | 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. |
Shared | Shared | Inbox Health is responsible for maintaining security awareness processes for personnel with access to the CDE. Inbox Health customers are responsible for maintaining security awareness processes for personnel with access to their own CDE. |
| 237 | 232a | 12.6.3 | Personnel receive security awareness training as follows: • Upon hire and at least once every 12 months. • Multiple methods of communication are used. • Personnel acknowledge at least once every 12 months that they have read and understood the information security policy and procedures. |
Shared | Shared | Inbox Health is responsible for maintaining security awareness processes for personnel with access to the CDE. Inbox Health customers are responsible for maintaining security awareness processes for personnel with access to their own CDE. |
| 238 | 233 | 12.6.3.1 | 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. |
Shared | Shared | Inbox Health is responsible for maintaining security awareness processes for personnel with access to the CDE. Inbox Health customers are responsible for maintaining security awareness processes for personnel with access to their own CDE. |
| 239 | 234 | 12.6.3.2 | Security awareness training includes awareness about the acceptable use of end-user technologies in accordance with Requirement 12.2.1. | Shared | Shared | Inbox Health is responsible for maintaining security awareness processes for personnel with access to the CDE. Inbox Health customers are responsible for maintaining security awareness processes for personnel with access to their own CDE. |
| 240 | 235 | 12.7.1 | 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. | Shared | Shared | Inbox Health maintains background checks for personnel with access to their CDE. Inbox Health customers are responsible to maintain background checks for personnel with access to their own CDE. |
| 241 | 236 | 12.8.1 | 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. | Shared | Shared | Inbox Health monitors the TPSPs and their PCI compliance. Inbox Health customers are responsible for monitoring PCI compliance for service providers with whom cardholder data is shared, or could affect the security of the CDE. Customers must maintain a list of all service provides used within their own CDE. |
| 242 | 237 | 12.8.2 | 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 the CDE. • Written agreements include acknowledgments from TPSPs that TPSP's are responsible for the security of account data the TPSPs possess or otherwise store, process, or transmit on behalf of the entity, or to the extent that they could impact the security of the entity’s CDE. |
Shared | Shared | Inbox Health is responsible for maintainaing agreeements with service providers with whom cardholder data is shared, or could affect the security of the CDE. Inbox Health customers are responsible for maintainaing agreeements with service providers with whom cardholder data is shared, or could affect the security of the CDE. |
| 243 | 238 | 12.8.3 | An established process is implemented for engaging TPSPs, including proper due diligence prior to engagement. | Shared | Shared | Inbox Health maintains established processes, including following due diligence with TPSP. Inbox Health customers maintains established processes, including following due diligence with their TPSP with whom cardholder data is shared, or could affect the security of the CDE. |
| 244 | 239 | 12.8.4 | A program is implemented to monitor TPSPs’ PCI DSS compliance status at least once every 12 months. | Shared | Shared | Inbox Health is responsible for monitoring PCI compliance for service providers with whom cardholder data is shared, or could affect the security of the CDE. Inbox Health customers are responsible for monitoring PCI compliance for service providers with whom cardholder data is shared, or could affect the security of the CDE. |
| 245 | 240 | 12.8.5 | 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. | Shared | Shared | Inbox Health is responsible to maintain information on PCI requirements and responsibilites managed by service provider and those that are shared. Inbox Health customers are responsible to maintain information on PCI requirements and responsibilites managed by service provider and those that are shared. |
| 246 | 241 | 12.9.1 | Additional requirement for service providers only: TPSPs acknowledge in writing to customers that TPSP's are responsible for the security of account data the TPSP possesses or otherwise stores, processes, or transmits on behalf of the customer, or to the extent that they could impact the security of the customer’s CDE. | Shared | Shared | Inbox Health is responsible for acknloweding their responsibilities for maintaining PCI compliance. Inbox Health customers that are Service Providers are responsible for acknloweding their responsibilities for maintaining PCI compliance. |
| 247 | 242 | 12.9.2 | Additional requirement for service providers only: 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 (Requirement 12.8.4). • Information about which PCI DSS requirements are the responsibility of the TPSP and which are the responsibility of the customer, including any shared responsibilities (Requirement 12.8.5). |
Shared | Shared | Inbox Health is responsible for acknloweding their responsibilities for maintaining PCI compliance. customers that are Service Providers are responsible for acknloweding their responsibilities for maintaining PCI compliance. |
| 248 | 243 | 12.10.1 | 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 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. |
Shared | Shared | Inbox Health is responsible to maintain incident response policies and processes supporting the CDE. Inbox Health customers are responsible to maintain incident response policies and processes supporting their CDE. |
| 249 | 244 | 12.10.2 | 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. |
Shared | Shared | Inbox Health is responsible to maintain incident response policies and processes supporting the CDE. Inbox Health customers are responsible to maintain incident response policies and processes supporting their CDE. |
| 250 | 245 | 12.10.3 | Specific personnel are designated to be available on a 24/7 basis to respond to suspected or confirmed security incidents. | Shared | Shared | Inbox Health is responsible to maintain incident response policies and processes supporting the CDE. Inbox Health customers are responsible to maintain incident response policies and processes supporting their CDE. |
| 251 | 246 | 12.10.4 | Personnel responsible for responding to suspected and confirmed security incidents are appropriately and periodically trained on their incident response responsibilities. | Shared | Shared | Inbox Health is responsible to maintain incident response policies and processes supporting the CDE. Inbox Health customers are responsible to maintain incident response policies and processes supporting their CDE. |
| 252 | 247 | 12.10.4.1 | 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. | Shared | Shared | Inbox Health is responsible for performing targeted risk analyses is support of applicable control requirements with organization-defined periodicity or a customized approach. Inbox Health customers are responsible for performing targeted risk analyses supporting their own CDE. |
| 253 | 248a | 12.10.5 | 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. • Detection of unauthorized wireless access points. |
Shared | Shared | Inbox Health is responsible to maintain incident response policies and procedures to respond to security incidents. Inbox Health customers are responsible to maintain incident response policies and procedures to respond to security incidents. |
| 254 | 249 | 12.10.6 | The security incident response plan is modified and evolved according to lessons learned and to incorporate industry developments. | Shared | Shared | Inbox Health is responsible to maintain, modify and update the incident response policies and processes supporting the CDE. Inbox Health customers are responsible to maintain, modify and update the incident response policies and processes supporting their CDE. |
| 255 | 250 | 12.10.7 | 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. |
Shared | Shared | Inbox Health is responsible to maintain incident response procedures for detection of CHD (PAN) stored outside the CDE. Inbox Health customers are responsible to maintain incident response procedures for detection of CHD (PAN) stored outside the CDE. |
| 256 | 251 | A1.1.1 | Logical separation is implemented as follows: • The provider cannot access its customers’ environments without authorization. • Customers cannot access the provider’s environment without authorization. |
Shared | Shared | Inbox Health customers who are multi-tenant service providers need to maintain this requirement. |
| 257 | 252 | A1.1.2 | Controls are implemented such that each customer only has permission to access its own cardholder data and CDE. | Shared | Shared | Inbox Health customers who are multi-tenant service providers need to maintain this requirement. |
| 258 | 253 | A1.1.3 | Controls are implemented such that each customer can only access resources allocated to them. | Shared | Shared | Inbox Health customers who are multi-tenant service providers need to maintain this requirement. |
| 259 | 254 | A1.1.4 | The effectiveness of logical separation controls used to separate customer environments is confirmed at least once every six months via penetration testing. | Shared | Shared | Inbox Health customers who are multi-tenant service providers need to maintain this requirement. |
| 260 | 255 | A1.2.1 | Audit log capability 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. |
Shared | Shared | Inbox Health customers who are multi-tenant service providers need to maintain this requirement. |
| 261 | 256 | A1.2.2 | 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. | Shared | Shared | Inbox Health customers who are multi-tenant service providers need to maintain this requirement. |
| 262 | 257 | A1.2.3 | 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. |
Shared | Shared | Inbox Health customers who are multi-tenant service providers need to maintain this requirement. |
| 263 | 258 | A2.1.1 | Where POS POI terminals at the merchant or payment acceptance location use SSL and/or early TLS, the entity confirms the devices are not susceptible to any known exploits for those protocols. | Shared | Shared | Inbox Health customers who maintain POS POI terminals are required to maintain this requirement. |
| 264 | 259 | A2.1.2 | Additional requirement for service providers only: All service providers with existing connection points to POS POI terminals that use SSL and/or early TLS as defined in A2.1 have a formal Risk Mitigation and Migration Plan in place that includes: • Description of usage, including what data is being transmitted, types and number of systems that use and/or support SSL/early TLS, and type of environment. • Risk-assessment results and risk-reduction controls in place. • Description of processes to monitor for new vulnerabilities associated with SSL/early TLS. • Description of change control processes that are implemented to ensure SSL/early TLS is not implemented into new environments. • Overview of migration project plan to replace SSL/early TLS at a future date. |
Shared | Shared | Inbox Health customers who maintain POS POI terminals are required to maintain this requirement. |
| 265 | 260 | A2.1.3 | Additional requirement for service providers only: All service providers provide a secure service offering. | Shared | Shared | Inbox Health customers who maintain POS POI terminals are required to maintain this requirement. |
| Inbox Health |
>
<