Privileged access events and logs from internet-facing servers are collected centrally, protected from change, and reviewed in a timely manner

Privileged access events are centrally logged. Required at Maturity Levels Two and Three of the Restrict administrative privileges mitigation strategy (Appendices B and C); ISM control ISM-1509 in ASD's Essential Eight to ISM mapping (December 2023).

evidence an assessor asks for Central log platform showing privileged access events ingested; Sample of privileged sign-ins traced end to end

Privileged user account and security group management events are centrally logged. Required at Maturity Levels Two and Three of the Restrict administrative privileges mitigation strategy (Appendices B and C); ISM control ISM-1650 in ASD's Essential Eight to ISM mapping (December 2023).

evidence an assessor asks for Central logging of privileged account and security group changes; Alert rules for additions to administrative groups

Event logs are protected from unauthorised modification and deletion. Required at Maturity Levels Two and Three of the Restrict administrative privileges mitigation strategy (Appendices B and C); ISM control ISM-1815 in ASD's Essential Eight to ISM mapping (December 2023). ASD lists this event logging and incident requirement under Restrict administrative privileges, so it is assessed for the events this strategy generates.

evidence an assessor asks for Integrity protection and access restrictions on the store of privileged access event logs; List of accounts able to delete those logs

Event logs from internet-facing servers are analysed in a timely manner to detect cyber security events. Required at Maturity Levels Two and Three of the Restrict administrative privileges mitigation strategy (Appendices B and C); ISM control ISM-1906 in ASD's Essential Eight to ISM mapping (December 2023). ASD lists this event logging and incident requirement under Restrict administrative privileges, so it is assessed for the events this strategy generates.

evidence an assessor asks for Detection rules analysing privileged activity on internet-facing servers; Triage records with timestamps

Cyber security events are analysed in a timely manner to identify cyber security incidents. Required at Maturity Levels Two and Three of the Restrict administrative privileges mitigation strategy (Appendices B and C); ISM control ISM-1228 in ASD's Essential Eight to ISM mapping (December 2023). ASD lists this event logging and incident requirement under Restrict administrative privileges, so it is assessed for the events this strategy generates.

evidence an assessor asks for Analysis records of privileged access anomalies (new admin accounts, unusual hours) with outcomes; Timeliness metrics for privileged-activity alerts

Successful and unsuccessful multi-factor authentication events are centrally logged. Required at Maturity Levels Two and Three of the Multi-factor authentication mitigation strategy (Appendices B and C); ISM control ISM-1683 in ASD's Essential Eight to ISM mapping (December 2023).

evidence an assessor asks for Central log platform showing successful and unsuccessful multi-factor events ingested; Retention setting for authentication logs

PowerShell module logging, script block logging and transcription events are centrally logged. Required at Maturity Levels Two and Three of the User application hardening mitigation strategy (Appendices B and C); ISM control ISM-1623 in ASD's Essential Eight to ISM mapping (December 2023).

evidence an assessor asks for Central logging of the scripting shell's module logging, script block logging and transcription; Sample events in the log platform

Command line process creation events are centrally logged. Required at Maturity Levels Two and Three of the User application hardening mitigation strategy (Appendices B and C); ISM control ISM-1889 in ASD's Essential Eight to ISM mapping (December 2023).

evidence an assessor asks for Central logging of command line process creation events; Audit policy showing command line capture enabled

Audit logging must be switched on and actively recording for every system component and for cardholder data. Applies to all entities. The guidance explains that logs feed alerts and other monitoring tools such as IDS and SIEM and give a history trail for investigating incidents, and it advises storing only essential information in logs because log content is itself sensitive. Customized approach objective: every activity affecting system components and cardholder data leaves a record.

evidence an assessor asks for Inventory of in-scope system components reconciled against log sources reporting to the SIEM; Audit policy or syslog configuration exports for sampled servers, network devices and databases; SIEM source health report showing last event received per device; Cloud provider logging configuration (for example trail or activity log settings) for in-scope accounts

Every day, at a minimum, the entity must review: all security events; the logs of each critical system component; the logs of each system component that stores, processes or transmits CHD and/or SAD; and the logs of each server and system component with a security function (such as authentication servers, IDS/IPS and network security controls). Applies to all entities. Objective under the customized approach: activity that may be suspicious or anomalous is found fast, keeping its impact low.

evidence an assessor asks for Daily log review procedure naming the four log categories; SIEM dashboards or review tickets showing a review for every calendar day, including weekends and holidays; List of critical system components and security function systems covered by review; Reports or sign-offs from an outsourced SOC, if used; Interview records with analysts performing the review

Gather audit logs, making sure logging has been switched on across enterprise assets as the audit log management process requires.

evidence an assessor asks for Logging configuration per asset type enabled per the log management process; Log source coverage report against the asset inventory; Log collection standard specifying which assets must have audit logging switched on; Group policy, agent or cloud diagnostic settings enabling audit logging on each asset type; Log source silence alerts showing assets that stopped sending logs and the follow-up

Review audit logs at least weekly to spot anomalies or unusual events that might signal a threat.

The requirement's own words: at least weekly

evidence an assessor asks for Weekly log review records with anomalies identified and follow-up; Reviewer sign-off or ticket evidence for each weekly review; Log review procedure defining weekly review scope, triage steps and escalation to incident response; SIEM dashboards or correlation rules used for the weekly review, with last-tuned dates; Incident or investigation tickets raised from weekly review findings

Computing hardware and software, runtime environments, and their data are monitored to find potentially adverse events

evidence an assessor asks for EDR coverage report by asset class; File integrity monitoring baseline and drift alerts; Software inventory reconciliation with allowlist; Hardware tamper detection telemetry; Patch and configuration drift dashboard

Policies, procedures and controls are implemented to monitor and log the activity of authorised users and to detect unauthorised access to or use of, or tampering with, customer information by such users.

evidence an assessor asks for User activity logging on systems holding customer information; Monitoring rules or reviews that detect misuse by authorised users

Implement hardware, software, and procedural mechanisms that record and examine activity in information systems that contain or use ePHI. NIST recommends central log management aligned to SP 800-92.

evidence an assessor asks for Logging standard; Central log management deployment; Log retention configuration; SIEM use case catalog

Securely maintain systems that, based on Risk Assessment, are designed to reconstruct material financial transactions and include audit trails to detect and respond to cybersecurity events that have material likelihood of harming operations. Retain transaction records five years and audit trails three years.

evidence an assessor asks for Logging and SIEM design document; List of in-scope financial systems and event logs; Five-year transaction record retention proof; Three-year audit trail retention proof; Log integrity protection controls (WORM, hashing); Log review and alerting procedures; Risk Assessment driving logging scope

Audit logging must be switched on and actively recording for every system component and for cardholder data. Applies to all entities. The guidance explains that logs feed alerts and other monitoring tools such as IDS and SIEM and give a history trail for investigating incidents, and it advises storing only essential information in logs because log content is itself sensitive. Customized approach objective: every activity affecting system components and cardholder data leaves a record.

evidence an assessor asks for Inventory of in-scope system components reconciled against log sources reporting to the SIEM; Audit policy or syslog configuration exports for sampled servers, network devices and databases; SIEM source health report showing last event received per device; Cloud provider logging configuration (for example trail or activity log settings) for in-scope accounts

Every day, at a minimum, the entity must review: all security events; the logs of each critical system component; the logs of each system component that stores, processes or transmits CHD and/or SAD; and the logs of each server and system component with a security function (such as authentication servers, IDS/IPS and network security controls). Applies to all entities. Objective under the customized approach: activity that may be suspicious or anomalous is found fast, keeping its impact low.

evidence an assessor asks for Daily log review procedure naming the four log categories; SIEM dashboards or review tickets showing a review for every calendar day, including weekends and holidays; List of critical system components and security function systems covered by review; Reports or sign-offs from an outsourced SOC, if used; Interview records with analysts performing the review

Audit logging must be switched on and actively recording for every system component and for cardholder data. Applies to all entities. The guidance explains that logs feed alerts and other monitoring tools such as IDS and SIEM and give a history trail for investigating incidents, and it advises storing only essential information in logs because log content is itself sensitive. Customized approach objective: every activity affecting system components and cardholder data leaves a record.

evidence an assessor asks for Inventory of in-scope system components reconciled against log sources reporting to the SIEM; Audit policy or syslog configuration exports for sampled servers, network devices and databases; SIEM source health report showing last event received per device; Cloud provider logging configuration (for example trail or activity log settings) for in-scope accounts

Every day, at a minimum, the entity must review: all security events; the logs of each critical system component; the logs of each system component that stores, processes or transmits CHD and/or SAD; and the logs of each server and system component with a security function (such as authentication servers, IDS/IPS and network security controls). Applies to all entities. Objective under the customized approach: activity that may be suspicious or anomalous is found fast, keeping its impact low.

evidence an assessor asks for Daily log review procedure naming the four log categories; SIEM dashboards or review tickets showing a review for every calendar day, including weekends and holidays; List of critical system components and security function systems covered by review; Reports or sign-offs from an outsourced SOC, if used; Interview records with analysts performing the review

Logs recording activity, exceptions, faults and other events of interest are to be generated, kept, protected and analysed. Purpose (stated in ISO/IEC 27002:2022): records events, generates evidence, protects log integrity, identifies security events and supports investigations. As an Annex A reference control, it is compared with the controls determined in risk treatment (6.1.3 c) and recorded in the Statement of Applicability as included or excluded, with the justification and implementation status (6.1.3 d); implementation guidance is ISO/IEC 27002:2022 8.15.

evidence an assessor asks for Statement of Applicability entry for control A.8.15, showing inclusion or justified exclusion, implementation status and the risks it treats; The topic-specific logging policy defining purposes, events to be logged, fields captured, retention and protection; Log source inventory showing which systems send which event types to central logging or SIEM; Configuration evidence that logs are tamper-protected (append-only storage, hashing, restricted deletion) and that administrators cannot erase their own activity; SIEM correlation rules, use cases and alert tuning records, and evidence of regular log review

Networks, systems and applications are to be monitored for anomalous behaviour, with appropriate steps taken to evaluate possible information security incidents. Purpose (stated in ISO/IEC 27002:2022): spots abnormal behaviour and possible security incidents. As an Annex A reference control, it is compared with the controls determined in risk treatment (6.1.3 c) and recorded in the Statement of Applicability as included or excluded, with the justification and implementation status (6.1.3 d); implementation guidance is ISO/IEC 27002:2022 8.16.

evidence an assessor asks for Statement of Applicability entry for control A.8.16, showing inclusion or justified exclusion, implementation status and the risks it treats; A documented monitoring scope covering network traffic, system access, configuration files, security tool logs, code integrity and resource use, with retention periods; Baselines of normal behaviour for systems and user groups, and the detection rules built on them; Alerting configuration with thresholds and evidence of tuning to reduce false positives; Monitoring team rota or SOC arrangement with trained staff and redundant alert channels