ABCDEFGHIJKLMNOPQRSTUVWXYZAA
1
PCI DSS Responsibility Matrix
2
Template example created by Strike Graph
3
Note: This is intended as a general example only. It may be necessary to reorganize the different technology layers or define additional component characteristics as applicable to a particular environment. Additionally, entities may wish to identify responsibilities for each
system component in greater detail than provided for here.
4
5
6
Sample PCI DSS Responsibility Matrix
7
PCI DSS 2.0 RequirementControl OwnerEvidence OwnerStatusExpiration DateLink to EvidenceNotes
8
Requirement 1: Install and maintain a firewall configuration to protect cardholder data
9
1.1 Establish firewall and router configuration standards that include the following:J. AustinE. VedderOverdue1/31/2022{link}3/1, FD: awaiting access
10
1.1.1 A formal process for approving and testing all network connections and changes to the firewall and router configurations.P.RuddF.OceanCurrent6/1/2025{link}
11
1.1.2 Current network diagram that identifies all connections between the cardholder data environment and other networks, including any wireless networks.
12
1.1.3 Current diagram that shows all cardholder data flows across systems and networks.
13
1.1.4 Requirements for a firewall at each Internet connection and between any demiltarized zone (DMZ) and the internal nework zone.
14
1.1.5 Description of groups, roles, and responsibilities for logical management of network components.
15
1.1.6 Documentation and business justification for use of all services, protocols, and ports allowed, including documentation of security features implemented for those protocols considered to be insecure.
Examples of insecure services, protocols, or ports include but are not limited to FTP, Telnet, POP3, IMAP, and SNMP v1 and v2.
16
1.1.7 Requirement to review firewall and router rule sets at least every six months.
17
1.2 Build firewall and router configurations that restrict connections between untrusted networks and any systems components in the cardholder data environment.
Note: an "untrusted network" is any network that is external to the networks belonging to the entity under review, and/or which is out of the entity's ability to control or manage.
18
1.2.1 Restrict inbound and outbound traffic to that which is necessary for the cardholder data environment, and specifically deny all other traffic.
19
1.2.2 Secure and synchronize router configuration files.
20
1.2.3 Install perimeter firewalls between all wireless networks and the cardholder data environment, and configure these firewalls to deny or, if traffic is necessary for business purposes, permit only authorized traffic between the wireless environment and the cardholder data environment.
21
1.3 Prohibit direct public access between the Internet and any system component in the cardholder data environment.
22
1.3.1 Implement a DMZ to limit inbound traffic to only system components that provide authorized publicly accessible services, protocols, and ports.
23
1.3.2 Limit inbound Internet traffic to IP addresses within the DMZ.
24
1.3.3 Do not allow any direct connections inbound or outbound for traffic between the Internet and the cardholder data environment.
25
1.3.4 Implement anti-spoofing measures to detect and block forged source IP addresses from entering the network. (For example, block traffic originating from the Internet with an internal source address.)
26
1.3.5 Do not allow unauthorized outbound traffic from the cardholder data environment to the Internet.
27
1.3.6 Implement stateful inspection, also known as dynamic packet filtering. (That is, only “established” connections are allowed into the network.)
28
1.3.7 Place system components that store cardholder data (such as a database) in an internal network zone, segregated from the DMZ and other untrusted networks.
29
1.3.8 Do not disclose private IP addresses and routing information to unauthorized parties.
30
1.4 Install personal firewall software on any mobile and/or employee-owned devices that connect to the Internet when outside the network (for example, laptops used by employees), and which are also used to access the network. Firewall configurations include:
• Specific configuration settings are defined for personal firewall software.
• Personal firewall software is actively running.
• Personal firewall software is not alterable by users of mobile and/or employee-owned devices.
31
1.5 Ensure that security policies and operational procedures for managing firewalls are documented, in use, and known to all affected parties.
32
Requirement 2: Do not use vendor-supplied defaults for system passwords and other security parameters
33
2.1 Always change vendor-supplied defaults and remove or disable unnecessary default accounts before installing a system on the network. This applies to ALL default passwords, including but not limited to those used by operating systems, software that provides security services, application and system accounts, point-of-sale (POS) terminals, Simple Network Management Protocol (SNMP) community strings, etc.).
34
2.1.1 For wireless environments connected to the cardholder data environment or transmitting cardholder data, change ALL wireless vendor defaults at installation, including but not limited to default wireless encryption keys, passwords, and SNMP community strings.
35
2.2 Develop configuration standards for all system components. Assure that these standards address all known security vulnerabilities and are consistent with industry-accepted system hardening standards. Sources of industry-accepted system hardening standards may include, but are not limited to: • Center for Internet Security (CIS) • International Organization for Standardization (ISO) • SysAdmin Audit Network Security (SANS) Institute • National Institute of Standards Technology (NIST).
36
2.2.1 Implement only one primary function per server to prevent functions that require different security levels from co-existing on the same server. (For example, web servers, database servers, and DNS should be implemented on separate servers.) Note: Where virtualization technologies are in use, implement only one primary function per virtual system component
37
2.2.2 Enable only necessary services, protocols, daemons, etc., as required for the function of the system.
38
2.2.3 Implement additional security features for any required services, protocols, or daemons that are considered to be insecure—for example, use secured technologies such as SSH, S-FTP, SSL, or IPSec VPN to protect insecure services such as NetBIOS, file-sharing, Telnet, FTP, etc.
39
2.2.4 Configure system security parameters to prevent misuse.
40
2.2.5 Remove all unnecessary functionality, such as scripts, drivers, features, subsystems, file systems, and unnecessary web servers.
41
2.3 Encrypt all non-console administrative access using strong cryptography. Use technologies such as SSH, VPN, or SSL/TLS for web-based management and other non-console administrative access.
42
2.4 Maintain an inventory of system components that are in scope for PCI DSS.
43
2.5 Ensure that security policies and operational procedures for managing vendor defaults and other security parameters are documented, in use, and known to all affected parties.
44
2.6 Shared hosting providers must protect each entity’s hosted environment and cardholder data. These providers must meet specific requirements as detailed in Appendix A: Additional PCI DSS Requirements for Shared Hosting Providers.
45
Requirement 3: Protect stored cardholder data
46
3.1 Keep cardholder data storage to a minimum by implementing data retention and disposal policies, procedures and processes that include at least the following for all cardholder data (CHD) storage:
· Limiting data storage amount and retention time to that which is required for legal, regulatory, and business requirements
· Processes for secure deletion of data when no longer needed
· Specific retention requirements for cardholder data
· A quarterly process for identifying and securely deleting stored cardholder data that exceeds defined retention.
47
3.2 Do not store sensitive authentication data after authorization (even if encrypted). If sensitive authentication data is received, render all data unrecoverable upon completion of the authorization process.
48
3.2.1 Do not store the full contents of any track (from the magnetic stripe located on the back of a card, equivalent data contained on a chip, or elsewhere). This data is alternatively called full track, track, track 1, track 2, and magnetic-stripe data.
49
3.2.2 Do not store the card verification code or value (three-digit or four-digit number printed on the front or back of a payment card) used to verify cardnot-present transactions.
50
3.2.3 Do not store the personal identification number (PIN) or the encrypted PIN block.
51
3.3 Mask PAN when displayed (the first six and last four digits are the maximum number of digits to be displayed), such that only personnel with a legitimate business need can see the full PAN.
52
3.4 Render PAN unreadable anywhere it is stored (including on portable digital media, backup media, and in logs) by using any of the following approaches: · One-way hashes based on strong cryptography, (hash must be of the entire PAN) · Truncation (hashing cannot be used to replace the truncated segment of PAN) · Index tokens and pads (pads must be securely stored) · Strong cryptography with associated key-management processes and procedures.
53
3.4.1 If disk encryption is used (rather than fileor column-level database encryption), logical access must be managed separately and independently of native operating system authentication and access control mechanisms (for example, by not using local user account databases or general network login credentials). Decryption keys must not be associated with user accounts.
54
3.5 Document and implement procedures to protect keys used to secure stored cardholder data against disclosure and misuse:
55
3.5.1 Restrict access to cryptographic keys to the fewest number of custodians necessary.
56
3.5.2 Store secret and private keys used to encrypt/decrypt cardholder data 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 dataencrypting key · Within a secure cryptographic device (such as a host 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 industryaccepted method
57
3.5.3 Store cryptographic keys in the fewest possible locations.
58
3.6 Fully document and implement all key-management processes and procedures for cryptographic keys used for encryption of cardholder data, including the following:
59
3.6.1 Generation of strong cryptographic keys
60
3.6.2 Secure cryptographic key distribution
61
3.6.3 Secure cryptographic key storage
62
3.6.4 Cryptographic key changes for keys that have reached the end of their cryptoperiod (for example, after a defined period of time has passed and/or after a certain amount of ciphertext has been produced by a given key), as defined by the associated application vendor or key owner, and based on industry best practices and guidelines (for example, NIST Special Publication 800-57).
63
3.6.5 Retirement or replacement (for example, archiving, destruction, and/or revocation) of keys as deemed necessary when the integrity of the key has been weakened (for example, departure of an employee with knowledge of a clear-text key component), or keys are suspected of being compromised.
64
3.6.6 If manual clear-text cryptographic key-management operations are used, these operations must be managed using split knowledge and dual control.
65
3.6.7 Prevention of unauthorized substitution of cryptographic keys.
66
3.6.8 Requirement for cryptographic key custodians to formally acknowledge that they understand and accept their key-custodian responsibilities.
67
3.7 Ensure that security policies and operational procedures for protecting stored cardholder data are documented, in use, and known to all affected parties.
68
For the complete matrix of 12 PCI DSS Requirements get Strike Graph.
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100