1. Requirement 7: Access to System Components & Payment Account Data Is Restricted, Based On Business Need To Know (N2K).
   1. 7.1 Rules for the restriction of access, based on business N2K, are documented & understood.
      1. 7.1.1 Documentation in support of the N2K access restrictions are maintained, in use and known by all affected parties.
      2. 7.1.2 N2K access restriction roles & responsibilities are: - Documented. - Assigned. - Understood.
      3. 7.3 An access control system(s) (ACS) is used to manage access to system components & data.
         1. 7.3.1 An ACS is used to restrict access, to all system components, based on a user's N2K.
         2. 7.3.2 An ACS enforces permissions to individuals, applications & systems, based on job classification & function.
         3. 7.3.3 An ACS is set to "Deny All" by default.
   2. 7.2 Access to system components & data is appropriately defined & assigned.
      1. 7.2.1 Implement & Maintain a defined access control model, including: - Access based on business & access needs. - Access is based on users' job classification & functions. - Application of the Principle of Least Privilege.
      2. 7.2.2 Access for all users is based on: - Job classification & function. - The principle of Least Privilege.
      3. 7.2.3 All access privileges are explicitly approved by authorised persons.
      4. 7.2.4 All user (including 3rd Party/vendors) accounts are periodically reviewed: - At least every 6-months. - Ensure user accounts and access remain appropriate. - Any inappropriate access is addressed. - Management acknowledges the appropriateness of the granted access levels.
      5. 7.2.5 The Least Privilege principle is applied to application & system accounts: - Based on the operability of the system or application. - Limited to systems, applications or processes that specifically require their use.
         1. 7.2.5.1 Reviews of access by application & system accounts & related access privileges are reviewed: - Risk-based (12.3.1) frequency. - Application/system access remains appropriate to the performed function. - Any inappropriate access is addressed. - Management acknowledges the appropriateness of the granted access levels.
      6. 7.2.6 All user access to query repositories of stored CHD is restricted: - using applications or other programmatic methods (actions based on user roles & least privilege). - Restricting direct access, or stored CHD repository queries) to only responsible administrator(s).
   3. 7.3 An access control system(s) (ACS) is used to manage access to system components & data.
      1. 7.3.1 An ACS is used to restrict access, to all system components, based on a user's N2K.
      2. 7.3.2 An ACS enforces permissions to individuals, applications & systems, based on job classification & function.
      3. 7.3.3 An ACS is set to "Deny All" by default.
2. Requirement 8: All Users Are Identified & Access To System Components Authenticated.
   1. 8.1 Rules for Logical Access Management are documented & understood.
      1. 8.1.1 Documentation in support of Logical Access Management are maintained, in use and known by all affected parties.
      2. 8.1.2 Logical Access Management roles & responsibilities are: - Documented. - Assigned. - Understood.
   2. 8.2 User IS & related accounts for users & admins are strictly managed across an account's lifecycle.
      1. 8.2.1 All users are assigned a unique ID before access is granted.
      2. 8.2.2 Management of Group, Shared, Generic or other shared authentication credentials: - Account use is prevented accept on an exceptional basis. - Use is timebound. - Use has a documented business justification. - Use is explicitly approved by management. - Individual user identity is confirmed before access to the account is granted. - Every action can be attributed to an individual user.
      3. 8.2.3 Service Provider only.
      4. 8.2.4 The addition, deletion and modification of User IDs, Authentication factors and other identifier objects are managed: - Authorised with the appropriate approval. - Implemented as per the specific documented privileges.
      5. 8.2.5 Terminated users have access immediately revoked.
      6. 8.2.6 After 90 days of inactivity, user accounts are removed or disabled.
      7. 8.2.7 3rd-Party that remotely access, support, or maintain system components are managed: - Timebound enablement (disabled when not in use). - Use is monitored for unexpected activity.
      8. 8.2.8 Maximum 15 minute idle session before lockout.
   3. 8.3 Strong authentication is established & managed for all Users & Administrators.
      1. 8.3.1 Implement 1 of the following authentication factors: - Something you know (e.g., Password). - Something you have (e.g., token/smart card). - Something you are (e.g., biometrics).
      2. 8.3.2 For all system components; authentication factors are rendered unreadable, during storage & transmission, using strong cryptography.
      3. 8.3.3 Verify user ID before any authentication factor is modified.
      4. 8.3.4 Management of invalid authentication attempts: - Lockout out after no more than 10 attempts. - Lockout for a minimum of 30 minutes or until the user identify is confirmed.
      5. 8.3.5 Password management. - Set to a unique value for 1st-time use and upon reset. - Forced change immediately after 1st use.
      6. 8.3.6 Password criteria. - 12 characters (minimum of 8 if not supported). - Alphanumeric.
      7. 8.3.7 Password history. - Last 4 passwords/passphrases.
      8. 8.3.8 Documented authentication policies & procedures are communicated to all users. - Guidance on selecting strong authentication factors. - Guidance on protecting their authentication factors. - Instructions to not reuse previously used passwords/passphrases. - )n the event of suspected compromise, instructions to change passwords/passphrases and how to report the incident.
      9. 8.3.9 For single factor user access, change timeframe: - At least once every 90 days. OR - Account security posture is dynamically analysed and real-time access to resources is automatically determined accordingly.
      10. 8.3.10 Service Providers only.
          1. 8.3.10.1 Service Providers only.
      11. 8.3.11 Use of physical or logical security tokens, smart cards or certificates. - Assigned to individual users and not shared. - Protected against unauthorised use.
   4. 8.4. Multi-Factor Authentication is used for all access into the CDE.
      1. 8.4.1 All non-console access is protected by MFA.
      2. 8.4.2 All access into the CDE is protected by MFA.
      3. 8.4.3 All remote network access (from outside the network) that could impact the CDE is protected by MFA. - All personnel (users & admins) originating from outside the network. - All 3rd-Parties & Vendors.
   5. 8.5 MFA is securely configured to prevent misuse.
      1. 8.5.1 MFA is configured to: - Protect against replay attacks. - Ensure that it cannot be bypassed by any users (inc. Admin), unless specifically authorised (on an exception, timebound, basis) by management & documented. - At least 2 independent authentication factors are used. - All authentication factors are successful before access is granted.
   6. 8.6 Application & system accounts and associated factors are strictly managed.
      1. 8.6.1 Interactive logins for systems & applications are effectively managed. - Only enabled for exceptional circumstances. - Timebound for the exceptional circumstance. - Business justification is documented. - Explicitly approved by management. - Individual identity is confirmed before access is granted. - Every action can be attributed to the individual user.
      2. 8.6.2 Systems & application account interactive logins are not hard-coded in scripts, configuration/property files or bespoke and custom source code.
      3. 8.6.3 Any system or application account passwords/passphrases are protected against misuse. - Periodically changed (as per risk-based timeframe). - Sufficiently complex for the change frequency.
3. Requirement 9: Restrict Physical Access to Cardholder Data.
   1. 9.1 Rules for the Physical Access Management are documented & understood.
      1. 9.1.1 Documentation in support of Physical Access Management are maintained, in use and known by all affected parties.
      2. 9.1.2 Physical Access Management roles & responsibilities are: - Documented. - Assigned. - Understood.
   2. 9.2 Physical Access Control
      1. 9.2.1 Appropriate facility entry controls are in place to restrict physical access into the CDE.
         1. 9.2.1.1 Physical access is monitored by video cameras or physical access control systems (or both). - Points of ingress & egress to sensitive areas, within the CDE, are monitored. - Monitoring devices or systems are protected from tampering or disabling. - Collected data is reviewed and correlated with other entries. - Collected data is securely retained for a minimum of 3 months (unless restricted by law).
      2. 9.2.2 Access to publicly accessible network jacks is restricted using physical +/or logical controls.
      3. 9.2.3 Physical access to the facility's wireless access points, gateways, networking/communications hardware & telecommunications lines is restricted.
      4. 9.2.4 All inactive consoles, within sensitive areas, are locked.
   3. 9.3 Visitor Control Management.
      1. 9.3.1 Visitor control procedures are in place for managing physical access to the CDE. - Identify personnel. - Manage changes to an individual's physical access requirements. - Revoking or terminating personnel ID. - Limiting access to the identification process or system to authorised personnel.
         1. 9.3.1.1 Control of physical access within the CDE. - Access is authorised. - Access is immediately revoked upon termination. - All physical access mechanisms (e.g., keys, access cards, etc.) are returned or disabled upon termination.
      2. 9.3.2 Visitor authorisation & management. - Visitors are pre-authorised. - Visitors are escorted at all times. - Visitors are clearly identified & given a badge or other ID that expires. - Visitors are clearly distinguishable from permanent staff.
      3. 9.3.3 Visitors passes are surrendered or deactivated at the end of the visit or at the expiration date.
      4. 9.3.4 A visitor log is maintained. - Visitor name & company represented. - Visit date & time. - Name of person authorising physical access. - Visitor log retained for a minimum of 3 months (unless restricted by law).
   4. 9.4 Media is securely managed.
      1. 9.4.1 All cardholder data media is physically secured.
         1. 9.4.1.1 Offline backups are securely stored.
         2. 9.4.1.2 Offline backup locations are reviewed at least annually.
      2. 9.4.2 All cardholder data media is data classified.
      3. 9.4.3 Media secure transfers outside the facility. - Logged. - Sent by courier or other trackable delivery method. - Offsite tracking logs include media location details.
      4. 9.4.4 Management approval for external transfers.
      5. 9.4.5 Electronic Media inventory logs.
         1. 9.4.5.1 At least annually, inventories of electronic cardholder data media is carried out.
      6. 9.4.6 Hardcopy cardholder data is securely destroyed, when no longer required for business or legal reasons.
      7. 9.4.7 Electronic cardholder media is securely destroyed, when no longer required for business or legal reasons.
   5. 9.5 Protection of Point-Of-Interaction (POI) devices (tampering & unauthorised substitution).
      1. 9.5.1 Face to Face (F2F) POI payment card devices are protected from tampering or unauthorised substitution. - Maintain a POI inventory. - Period POI inspections. - Awareness training.
         1. 9.5.1.1 Maintain an up-to-date POI device inventory.
         2. 9.5.1.2 Periodic POI device inspections are carried out to help detect any tampering or unauthorised substitutions.
            1. 9.5.1.2.1 Frequency of POI devices inspections are risk-based (12.3.1).
         3. 9.5.1.3 Training is provided to personnel within the POI environments, making them aware of the signs of attempted tampering or replacement of POI devices. - Verifying 3rd-parties (e.g., repair or maintenance) identity before granting access to the POI devices. - Procedures for ensuring that devices are not installed, replaced, or returned without verification. - Awareness of suspicious behaviour near devices. - Reporting suspicious behaviour & indications of device tampering or substitution to appropriate personnel.