There is a written cyber security incident response plan, it is enacted when an incident is identified, and incidents are reported internally and to the authority the rule names

Following the identification of a cyber security incident, the cyber security incident response plan is enacted. Required at Maturity Levels Two and Three of the Restrict administrative privileges mitigation strategy (Appendices B and C); ISM control ISM-1819 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 Incident response plan activation for a privileged account incident; Post-incident review record

Cyber security incidents are reported to the Chief Information Security Officer, or one of their delegates, as soon as possible after they occur or are discovered. Required at Maturity Levels Two and Three of the Restrict administrative privileges mitigation strategy (Appendices B and C); ISM control ISM-0123 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 Incident records for privileged account misuse showing CISO or delegate notification; Escalation matrix

Cyber security incidents are reported to ASD as soon as possible after they occur or are discovered. Required at Maturity Levels Two and Three of the Restrict administrative privileges mitigation strategy (Appendices B and C); ISM control ISM-0140 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 ASD ReportCyber references for privileged account compromise incidents; Written procedure naming who submits reports to ASD and when

An incident response plan must exist and be ready to activate if a security incident is suspected or confirmed. At minimum it covers: roles and duties, plus approaches for communication and for contacting parties, including at least notifying payment brands and acquirers; response procedures giving specific containment and mitigation steps per incident type; procedures for business recovery and continuity; processes for backing up data; an analysis of the legal duties to report compromises; coverage of, and responses covering, every critical system component; and reference to, or inclusion of, the payment brands' incident response procedures. Objective under the customized approach: a thorough incident response plan meeting card brand expectations is kept.

evidence an assessor asks for Incident response plan with role and contact tables; Payment brand and acquirer notification procedures; Incident-type playbooks with containment and mitigation steps; Legal reporting requirements analysis; Records of prior incidents showing plan use

Name one key person, plus at least one deputy, to run the enterprise incident handling process. These managers coordinate and document incident response and recovery, and may be enterprise employees, third-party vendors, or a mix of both. Where a third-party vendor is used, name at least one person inside the enterprise to oversee the vendor's work. Review this each year, or sooner when a major change in the enterprise could affect this Safeguard.

evidence an assessor asks for Appointment record naming the primary incident handling manager and at least one backup; Incident records showing the designated managers coordinated and documented response; Deputy incident manager named with contact details and coverage for leave; Named internal overseer for an outsourced incident response retainer or MSSP; Annual review record confirming incident manager appointments are still current

Set up and keep an incident response process that sets out who does what, which compliance requirements apply, and a plan for communications. Review it each year, or sooner when a major change in the enterprise could affect this Safeguard.

evidence an assessor asks for Incident response plan defining roles, applicable compliance requirements and the communication plan; Record of the annual incident response plan review and changes made; Mapping of the plan to legal and contractual notification duties, such as breach reporting deadlines; Communication plan templates for staff, customers, regulators and media, with approvers; Incident records showing the plan was followed in a real incident

The incident response plan is executed in coordination with relevant third parties once an incident is declared

evidence an assessor asks for Incident response plan with third party invocation; Retainer contract evidence for IR vendor; Joint exercise records with the IR vendor; Coordination procedure with law enforcement; Vendor activation log during real incidents

The institution establishes a written incident response plan designed to promptly respond to and recover from any security event materially affecting the confidentiality, integrity or availability of customer information in its control, addressing the goals of the plan, the internal processes for responding to a security event, clear roles, responsibilities and levels of decision-making authority, external and internal communications and information sharing, the requirements for remediating identified weaknesses in information systems and controls, documentation and reporting of security events and response activities, and the evaluation and revision of the plan after a security event. Not required of institutions holding information on fewer than 5,000 consumers (314.6).

evidence an assessor asks for Written incident response plan covering the seven areas; Post-incident review records

Identify and respond to suspected or known incidents, mitigate harmful effects, and document incidents and their outcomes. NIST recommends linkage to HIPAA Breach Notification Rule timelines.

evidence an assessor asks for Incident ticket log; Post-incident reports; Breach risk assessments per 164.402; Notification records (individuals, HHS, media)

Establish written Incident Response Plan and Business Continuity and Disaster Recovery Plan reasonably designed to respond to and recover from material cybersecurity events. Plans must address specified elements (internal processes, goals, roles, communications, remediation, documentation, evaluation). Test plans annually with all critical staff and proactively maintain backups isolated from network connections.

evidence an assessor asks for Incident Response Plan addressing all required §500.16(a)(1) elements; BCDR plan including ransomware scenarios; Annual tabletop and technical test results with lessons learned; Backup architecture demonstrating isolation (immutable, offline, or air-gapped); Backup restore test evidence; Communication plan including regulator and customer notifications; Post-incident review and improvement records

An incident response plan must exist and be ready to activate if a security incident is suspected or confirmed. At minimum it covers: roles and duties, plus approaches for communication and for contacting parties, including at least notifying payment brands and acquirers; response procedures giving specific containment and mitigation steps per incident type; procedures for business recovery and continuity; processes for backing up data; an analysis of the legal duties to report compromises; coverage of, and responses covering, every critical system component; and reference to, or inclusion of, the payment brands' incident response procedures. Objective under the customized approach: a thorough incident response plan meeting card brand expectations is kept.

evidence an assessor asks for Incident response plan with role and contact tables; Payment brand and acquirer notification procedures; Incident-type playbooks with containment and mitigation steps; Legal reporting requirements analysis; Records of prior incidents showing plan use

An incident response plan must exist and be ready to activate if a security incident is suspected or confirmed. At minimum it covers: roles and duties, plus approaches for communication and for contacting parties, including at least notifying payment brands and acquirers; response procedures giving specific containment and mitigation steps per incident type; procedures for business recovery and continuity; processes for backing up data; an analysis of the legal duties to report compromises; coverage of, and responses covering, every critical system component; and reference to, or inclusion of, the payment brands' incident response procedures. Objective under the customized approach: a thorough incident response plan meeting card brand expectations is kept.

evidence an assessor asks for Incident response plan with role and contact tables; Payment brand and acquirer notification procedures; Incident-type playbooks with containment and mitigation steps; Legal reporting requirements analysis; Records of prior incidents showing plan use

The organization is to prepare for handling information security incidents by defining, setting up and communicating how incidents are managed and who does what. Purpose (stated in ISO/IEC 27002:2022): makes incident handling fast, effective, consistent and orderly, including how events are communicated. 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 5.24.

evidence an assessor asks for Statement of Applicability entry for control A.5.24, showing inclusion or justified exclusion, implementation status and the risks it treats; An approved incident management plan and procedures covering evaluation, detection, classification, escalation, recovery, communication, evidence handling and post-incident review; Incident management objectives and priorities agreed with management, including resolution time frames by severity; A roles and responsibilities document for the incident team and its communication to internal and external parties; Training, certification and exercise records for incident responders

Incidents are to be handled following the documented response procedures. Purpose (stated in ISO/IEC 27002:2022): ensures incidents are responded to efficiently and effectively. 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 5.26.

evidence an assessor asks for Statement of Applicability entry for control A.5.26, showing inclusion or justified exclusion, implementation status and the risks it treats; Documented incident response procedures or playbooks communicated to relevant parties; Incident records showing containment, evidence collection, escalation, communication and formal closure; Response activity logs or ticket histories kept for later analysis; Communication records to internal and external parties following need-to-know