1. Requirement 10: Logging & Monitoring All Access to System Components & Cardholder Data.
    1. 10.1 Rules for the systems & user monitoring are documented & understood.
      1. 10.1.1 Documentation in support of the systems & user monitoring are maintained, in use and known by all affected parties.
      2. 10.1.2 Systems & user monitoring roles & responsibilities are: - Documented. - Assigned. - Understood.
    2. 10.2 Audit logs are in place for the detection of anomalies, suspicious activity and in support of forensic analysis.
      1. 10.2.1 All system components & customer data is protected by enabled and active audit logging.
        1. 10.2.1.1 All individual user access to cardholder data is captured.
        2. 10.2.1.2 All individual admin access, including any interactive use of application or system accounts is captured.
        3. 10.2.1.3 All access to audit logs are captured.
        4. 10.2.1.4 All invalid logical access attempts are captured.
        5. 10.2.1.5 All changes to ID & authentication credentials are captured. - Creation of new accounts. - Elevation of Privileges. - All changes, additions, or deletion of Admin access accounts.
        6. 10.2.1.6 All initialisation of new audit logs and all starting, stopping or pausing of the existing audit logs are captured.
        7. 10.2.1.7 All creations & deletions of system-level objects are captured.
      2. 10.2.2 Audit logs record the following details: - User ID. - Event type. - Date & time. - Success & failures. - Event origin. - Identity or name of affected data, system component, resource or service (e.g., name & protocol).
    3. 10.3 Protect audit logs from destruction and unauthorised modifications.
      1. 10.3.1 Read access to audit log files is limited to legitimate job-needs.
      2. 10.3.2 Protect audit log files from modification by individuals.
      3. 10.3.3 Prompt backup of audit log files (including those for external-facing technologies) to a secure, central, internal log server(s) or other media that is difficult to modify.
      4. 10.3.4 FIM or change-detection mechanisms ensure that any existing log data cannot be changed without creating alerts.
    4. 10.4 Audit logs reviews are carried out to identify anomalies or suspicious activity.
      1. 10.4.1 Daily audit log reviews. - All security events. - All servers & system components that process, store or transmit CHD +/or SAD. - All critical system components. - All servers & system components that perform security functions (e.g., NSCs, IDS/IPS, authentication servers.
        1. 10.4.1.1 Automated audit log reviews.
      2. 10.4.2 Periodic audit log reviews of all other system components (those not covered by 10.4.1).
        1. 10.4.2.1 Frequency of log reviews are risk-based (12.3.1)
      3. 10.4.3 any identified exceptions & anomalies are addressed.
    5. 10.5 Audit history retention.
      1. 10.5.1 Retention for a minimum of 12 months (3 months immediately available).
    6. 10.6 Time-synchronisation is in place to ensure consistent time settings across all in-scope systems.
      1. 10.6.1 All in-scope system clocks & time are synchronised using time-synchronisation technology.
      2. 10.6.2 All in-scope systems have correct & consistent time. - 1 or more designated time servers are used. - Only the designated central time server(s) receives time from external sources. - External time source(s) uses International Atomic Time or Coordinated Universal Time (UTC). - The designated time server receives updates from specific industry-accepted external sources.
      3. 10.6.3 Time-synchronisation settings & data are protected: - Access strictly restricted based on business needs. - Critical system time settings are logged, monitored and reviewed.
    7. 10.7 Critical security control system failures are detected, reported & responded to.
      1. 10.7.1 Service Providers Only.
      2. 10.7.2 Critical security control system failures are identified and responded to, including the following: - NSC failures. - IDS/IPS failures. - Change-detection failures. - Anti-malware solution failures. - Physical access control failures. - Logical access control failures. - Audit logging failures. - Segmentation control (if used) failures. - Audit log review failures. - Automated security testing tool failures (if used).
      3. 10.7.3 Responding to critical security system failures. - Restore security functions. - Identify & document duration of failure. - Identify & document root cause of failure. - Identify & address any security issues caused by the failure. - Determine any further actions needed. - Implement controls to prevent reoccurrence. - Resume monitoring of security controls.
  2. Requirement 11: Security Testing
    1. 11.1 Rules for the security testing are documented & understood.
      1. 11.1.1 Documentation in support of the security testing are maintained, in use and known by all affected parties.
      2. 11.1.2 Security testing roles & responsibilities are: - Documented. - Assigned. - Understood.
    2. 11.2 Wireless access points are identified & monitored and rogue wireless devices are addressed.
      1. 11.2.1 Management of authorised & unauthorised wireless access points. - Testing for wireless access points. - Detecting & identifying authorised & unauthorised wireless access points. - Quarterly testing, detection & identification is carried out. - Automated monitoring sends alerts to appropriate personnel.
      2. 11.2.2 Maintain an inventory of business justified wireless access points.
    3. 11.3 External & internal vulnerability scanning.
      1. 11.3.1 Internal vulnerability scanning is carried out. - Quarterly. - Critical & high-risk (6.3.1) vulnerabilities are resolved. - Rescans are carried out to confirm effective remediation of identified critical & high-risk vulnerabilities. - Scan too is kept up to to date. - Scans are carried out by qualified personnel, who have independence of the internal operations.
        1. 11.3.1.1 All other lower risk vulnerabilities are managed. - Remediated in accordance with the schedules defined by the perceived risk (12.3.1). - Rescans are carried out as needed.
        2. 11.3.1.2 Authenticated scanning is used. - Any exceptions to authentication scanning is documented. - Sufficient privileges are applied to the systems being scanned. - Accounts used for authenticated scans, with interactive logins, are managed I.A.W. 8.2.2.
        3. 11.3.1.3 Internal scans are carried out after any significant changes. - Critical & high-risk (6.3.1) vulnerabilities are resolved. - Rescans are conducted, as needed. - Scans are carried out by qualified (and independent) personnel (not needing to be a QSA or ASV).
      2. 11.3.2 External vulnerability scanning is carried out. - Quarterly. - By an Approved Scanning Vendor (ASV). - Identified vulnerabilities are resolved for a passing scan. - Rescans are carried out, as needed, to confirm the effective resolution.
        1. 11.3.2.1 External scans are carried out after any significant changes. - Vulnerabilities CVSS 4.0 or higher are resolved. - Rescans are carried out, as needed. - Scans are performed by qualified (independent) testers (not required to be a QSA or ASV).
    4. 11.4. External & Internal penetration testing is performed regularly & exploitable vulnerabilities, & security weaknesses, are corrected.
      1. 11.4.1 A penetration testing methodology is defined, documented and implemented by the entity.
      2. 11.4.2 Internal penetration testing is carried out. - As per 11.4.1. - At least annually. - After significant infrastructure or application upgrade, or change. - By a qualified internal resource or qualified external 3rd-party. - Tester independence (not required to be a QSA or ASV).
      3. 11.4.3 External penetration testing is carried out. - As per 11.4.1. - At least annually. - After significant infrastructure or application upgrade, or change. - By a qualified internal resource or qualified external 3rd-party. - Tester independence (not required to be a QSA or ASV).
      4. 11.4.4 All identified exploitable vulnerabilities & security weaknesses are corrected. - Aligned with the perceived risk exposure (6.3.1). - Testing is repeated to verify corrections.
      5. 11.4.5 Validate effectiveness of any segmentation measures. - At least annually. - Covering all segmentation controls/methods used. - Confirming the effectiveness to isolate the CDE from all out-of-scope. - Confirming effectiveness to isolate systems with different security levels. - Carried out by a qualified internal or qualified external 3rd-party. - Tester independence (not needing to be a QSA or ASV).
      6. 11.4.6 Service Providers Only.
      7. 11.4.7 Multi-tenant Service Providers Only.
    5. 11.5 Network intrusions & unexpected file changes are detected and responded to.
      1. 11.5.1 IDS/IPS is used to help prevent intrusions into the network. - Monitor all traffic at the CDE perimeter. - Monitor all traffic at critical points in the CDE, - Alert personnel to suspected compromise. - Ensure all IDS/IPS are kept upto date.
        1. 11.5.1.1 Service Provider Only.
      2. 11.5.2 Change detection (e.g., FIM) is used. - Alert personnel of modifications to critical files. - Carry out weekly comparisons of critical files.
    6. 11.6 Detect & respond to unauthorised changes to payment pages.
      1. 11.6.1 A change and tamper detection mechanism is deployed to protect all payment pages. - Alert personnel to unauthorised modification to the HTTP headers and the contents of payment pages, as received by the consumer' browser. - Configured to evaluate the received HTTP header and payment page. - Functions are performed: - At least weekly. OR - Periodically (Frequency based on perceived risk (12.3.1)).