NIST SP 800-61

Handle cloud, third-party, and supply chain incidents and integrate threat intelligence per NIST SP 800-61 Rev 2 supplemented by NIST SP 800-150 (Cyber Threat Information Sharing) + NIST SP 800-161 (Supply Chain Risk Management). Cloud incident handling must address (a) shared responsibility model per cloud service (SaaS + PaaS + IaaS) with provider-side vs consumer-side responsibilities documented in advance, (b) cloud provider incident reporting channels and SLAs (incident notification timing + scope + format), (c) evidence collection in cloud environments (audit log export + snapshots + identity provider logs + control-plane logs + workload artefacts) where consumer access to underlying infrastructure is limited, (d) cross-tenant isolation verification post-incident, (e) cloud-specific containment (revoke API keys + rotate credentials + isolate accounts + cordon affected workloads + s

• cloud IR runbook per provider per service-model with credential rotation + log export + provider escalation + containment authority
• supplier contract clauses for incident notification + joint investigation + scope of access
• threat intelligence subscription evidence + IoC enrichment + retrospective hunting evidence
• supply chain incident playbook per NIST SP 800-161

• cloud IR using on-prem runbook (wrong tools + wrong evidence + wrong authority)
• supplier contracts lack incident notification clauses
• threat intelligence consumed but not enriched + not driving hunting

Execute Containment + Eradication + Recovery per NIST SP 800-61 Rev 2 Section 3.3. Containment Strategy (Section 3.3.1) must be chosen based on (a) potential damage to and theft of resources, (b) need for evidence preservation, (c) service availability requirements, (d) time and resources to implement the strategy, (e) effectiveness of the strategy (partial vs full), (f) duration of the solution (emergency workaround vs temporary vs permanent). Identify Attacking Hosts (Section 3.3.2) via attacker IP address validation + research via search engines + databases + incident response coordination centres + monitor possible communication channels (although NIST 800-61 cautions about attribution complexity). Eradication and Recovery (Section 3.3.4) must (a) eliminate components of the incident (delete malware + disable breached accounts + identify and mitigate exploited vulnerabilities), (b) r

• pre-documented containment strategy per incident category with decision criteria
• evidence preservation procedure before destructive containment
• eradication checklist (malware removal + account disable + vulnerability mitigation)
• recovery procedure (restore from clean backup + rebuild + patches + credential rotation + heightened monitoring period)

• containment chosen under pressure without pre-documented strategy producing inconsistent decisions
• evidence destroyed during containment because preservation step skipped
• recovery declared complete without heightened-monitoring follow-up

Coordinate with external parties and handle privacy and breach incidents per NIST SP 800-61 Rev 2 Chapter 4 (Coordination and Information Sharing). Coordination must address (a) coordination relationships per Section 4.1 (team-to-team + team-to-coordinating-team + coordinating-team-to-coordinating-team), (b) sharing agreements and reporting requirements per Section 4.2 (peer-to-peer + sector ISAC + national CSIRT + law enforcement + regulator + sub-processor and supply chain partner relationships + customer relationships), (c) information sharing techniques per Section 4.3 (ad-hoc + partially-automated + standardised through formats like STIX/TAXII), (d) granular information sharing per Section 4.4 (business impact + technical + general indicators) with appropriate redaction. Privacy and breach response: (a) integrate privacy team with security team for incidents involving personal data,

• coordination relationship matrix with internal and external parties + sharing agreements + reporting obligations
• STIX/TAXII or equivalent automation evidence
• privacy + legal + communications integration in CSIRT workflow
• regulator notification log and evidence of timing compliance (GDPR + CCPA + state laws + sectoral)

• privacy handover after technical containment producing missed regulator clocks
• external sharing ad hoc with no standardised format
• no documented criteria for what gets shared with whom

Operate detection and analysis per NIST SP 800-61 Rev 2 Section 3.2 (Detection and Analysis). Tasks include (a) Attack vectors as taxonomy (External/Removable Media + Attrition + Web + Email + Improper Usage + Loss or Theft of Equipment + Other) for categorisation per Section 3.2.1, (b) Signs of an Incident: precursors and indicators monitored across SIEM + IDS/IPS + antimalware + log management + file integrity monitoring + third-party monitoring services + public information sources + people-reported indicators per Section 3.2.2, (c) Sources of Precursors and Indicators inventory per Section 3.2.3, (d) Incident Analysis including network and system profiling + understand normal behaviour + create log retention policy + perform event correlation + keep all host clocks synchronised + use a knowledge base + use Internet search engines for research + run packet sniffers to collect addition

• attack vector taxonomy with categorisation policy
• precursor and indicator monitoring evidence across SIEM + IDS + AV + log mgmt + FIM + third-party feeds + public sources + people-reported
• incident documentation template covering status + summary + indicators + actions + chain of custody + impact + evidence list
• prioritisation matrix mapping functional + information + recoverability impact to priority

• incident documentation incomplete - missing indicators + impact rationale + chain of custody
• prioritisation done ad hoc without matrix producing inconsistent decisions
• no event correlation - SIEM produces alerts but no analyst correlation

Establish incident response policy, plan, and procedures per NIST SP 800-61 Rev 2 Chapter 2 (Organizing a Computer Security Incident Response Capability) Section 2.1 and Chapter 3 Section 3.1 (Preparation). Policy must define statement of management commitment + purpose and objectives + scope (to whom and what the policy applies) + roles and responsibilities + reportable incident definitions + reporting requirements + performance measures + reporting and contact forms. Plan must operationalise the policy with mission + strategies and goals + senior management approval + organisational approach + communication path between teams + measures of effectiveness + roadmap for maturing capability. Procedures must include standard operating procedures + technical processes + use of incident response toolkits + checklists. Review policy + plan + procedures at least annually and after every signifi

• approved IR policy with management commitment + scope + roles + reportable incidents + measures
• IR plan with mission + strategy + senior management approval + communication paths
• operational procedures + technical SOPs + toolkits + checklists
• annual review evidence and post-incident review trigger

• policy unmaintained or out of step with current organisation chart
• plan exists on paper but never operationalised in procedures
• no annual review evidence

Conduct Post-Incident Activity per NIST SP 800-61 Rev 2 Section 3.4. Tasks include (a) Lessons Learned Meeting per Section 3.4.1: held within several days of the end of every major incident with attendees including the handlers + management + appropriate external parties, structured to answer questions about (what happened + how well did staff and management perform + were documented procedures followed + were they adequate + what would the staff and management do differently next time + how could information sharing with other organisations have been improved + what corrective actions can prevent similar incidents + what precursors or indicators should be watched for to detect similar incidents + what additional tools or resources are needed), (b) Using Collected Incident Data per Section 3.4.2: incident response metrics (number of incidents handled + time per incident + objective and s

• lessons-learned meeting record per major incident with attendees + questions answered + recommendations + closure tracking
• evidence retention policy and per-incident retention decisions
• incident response metrics (volume + time + assessment) reported to leadership

• lessons-learned skipped for many incidents
• recommendations recorded but never closed
• evidence retention undocumented producing inconsistent decisions

Build the preparedness capability per NIST SP 800-61 Rev 2 Section 3.1 (Preparation). Preparation must address (a) Communications and Facilities: contact information (24/7 numbers + email + pagers + secure messaging) + on-call lists + escalation rosters + war room + secure storage for evidence + encryption for incident reports + jump bags + secure communication channels (encrypted email + signed messages + out-of-band channels for compromised-network scenarios), (b) Incident Analysis Hardware and Software: digital forensic workstations + laptops + spare equipment + blank removable media + portable printers + protocol analyzers + packet sniffers + forensic software + scripts and CDs/USB sticks + chain-of-custody supplies, (c) Incident Analysis Resources: port lists + documentation for operating systems + applications + protocols + intrusion detection signatures + network diagrams + lists

• jump bag inventory and recertification dates
• incident analysis hardware/software inventory with maintenance evidence
• knowledge base of port lists + signatures + baselines + critical asset inventory
• training records + exercise reports (tabletop and technical) + threat intelligence subscription evidence

• jump bags never recertified - tools out of date
• no tabletop exercises in 12+ months
• no threat intelligence consumption integrated with detection

Establish a Computer Security Incident Response Team (CSIRT) per NIST SP 800-61 Rev 2 Section 2.4 (Incident Response Team Structure) and Section 2.5 (Incident Response Personnel). Team structure options include central team + distributed teams + coordinating team + fully-outsourced + partially-outsourced. Staffing model and selection considerations include team size + skills required (technical + communication + leadership + analytical) + multi-disciplinary coverage (network + system + application + forensic + legal + communications + privacy) + 24x7 coverage requirements + on-call rotation + escalation contacts. Define team relationships with the rest of the organisation: Management + Information Security + IT Support + Legal + Public Affairs and Media Relations + Human Resources + Business Continuity + Physical Security and Facilities Management. Establish formal handoff and informatio

• CSIRT charter naming team structure (central / distributed / coordinating / outsourced)
• named staff per role with skills mapping covering 24/7 coverage
• documented relationships with Management + IT + Legal + Privacy + Comms + HR + BC + Physical
• external coordination contacts (sector ISAC + national CSIRT + law enforcement)

• CSIRT charter exists but staffing not maintained or rotation gaps
• no documented relationships with privacy, comms, legal
• external coordination contacts not validated annually