IT incident response logs Summarization Prompt

# IT Incident Response Logs Summarization Prompt ## Background & Context IT incident response logs document cybersecurity events, attacks, system outages, and the corresponding response actions taken by IT security teams. These logs are typically created by IT security analysts, system administrators, and automated security tools during and after security incidents. The primary consumers of these summaries include IT management, CISOs, compliance officers, security teams for knowledge sharing, and occasionally executive leadership during significant incidents. The goal is to understand what happened, how it was addressed, and what can be prevented in the future. ## Report Structure & Components IT incident response logs commonly contain: - Incident identifier and classification (severity level, type) - Timeline of events (detection time, response time, resolution time) - Systems/assets affected - Threat actor information (if identified) - Initial alert/detection method - Investigation steps and findings - Containment and eradication actions - Recovery procedures implemented - Root cause analysis - Business impact assessment - Remediation recommendations - Evidence collection notes - Communication logs - Compliance/regulatory implications ## Critical Information to Extract Focus on extracting: 1. Incident severity and categorization 2. Key timeline metrics (time-to-detect, time-to-respond, time-to-resolve) 3. Attack vector or root cause 4. Extent of the impact (systems affected, data compromised) 5. Successful mitigation actions 6. Unresolved vulnerabilities or remaining risks 7. Critical recommendations for preventing recurrence 8. Resource requirements for full remediation 9. Compliance implications or reporting obligations 10. Relevant IOCs (Indicators of Compromise) for future detection ## Stakeholder Priorities Different stakeholders need different elements: - **Executives**: Focus on business impact, reputational risk, financial implications, regulatory exposure, and high-level remediation timelines - **IT Management**: Emphasize resource allocation needs, root cause, technical debt implications, and team performance during response - **Security Teams**: Detail technical specifics, attack methodology, evasion techniques used, effectiveness of security controls, and specific remediation steps - **Compliance Officers**: Highlight regulatory requirements fulfilled/violated, documentation completeness, and evidence preservation status - **External Auditors**: Summarize adherence to incident response procedures, documentation standards, and compliance requirements ## Output Format Guidelines Structure the summary as follows: 1. **Executive Summary** (2-3 sentences on incident nature, impact, and status) 2. **Incident Overview** (bullet points with key facts) 3. **Timeline** (condensed chronological list of key events) 4. **Impact Assessment** (technical and business impacts in bullet form) 5. **Response Effectiveness** (brief assessment of what worked/didn't) 6. **Recommendations** (prioritized action items) 7. **Metrics Dashboard** (suggest key metrics to visualize: detection times, response times, affected systems) 8. **Compliance Status** (bullet points on regulatory implications) Total length: 1-2 pages (500-750 words) for standard incidents; up to 3 pages for major incidents. ## Special Considerations - Be aware of technical terminology differences between security domains (network security vs. application security vs. cloud security) - Maintain confidentiality by not revealing sensitive security architecture details in the summary - Distinguish between confirmed facts vs. suspected/unverified information - Translate technical jargon appropriately based on the audience - Understand the "kill chain" or "attack lifecycle" frameworks to properly contextualize incident stages - Consider referencing relevant MITRE ATT&CK tactics and techniques when applicable - Be aware that logs may contain inconsistencies in timestamps due to system clock variations - Note that incident response documentation may be legally discoverable in certain scenarios ## Sample Output Structure # INCIDENT SUMMARY: [Incident ID] - [Incident Name] ## Executive Summary [2-3 sentences covering incident nature, impact scope, current status] ## Incident Overview - **Classification**: [Type/Severity] - **Detection**: [How/When discovered] - **Duration**: [Start time → Resolution time] - **Systems Affected**: [List of key systems] - **Data Impact**: [Data affected/exposed] - **Attribution**: [If known/suspected] ## Key Timeline - **[Date/Time]**: Initial detection - **[Date/Time]**: Response initiated - **[Date/Time]**: Key response activities - **[Date/Time]**: Containment achieved - **[Date/Time]**: Recovery completed ## Impact Assessment - **Technical Impact**: [Systems/services affected] - **Business Impact**: [Operational/financial consequences] - **User Impact**: [Number of affected users/services] ## Response Effectiveness - **What Worked**: [Effective controls/procedures] - **What Failed**: [Failed controls/procedures] - **Detection Gaps**: [Monitoring improvements needed] ## Key Recommendations 1. [High priority action item] 2. [Medium priority action item] 3. [Long-term improvement] ## Compliance Implications - [Any regulatory reporting requirements] - [Documentation completeness status] - [Evidence preservation status] ## Follow-up Actions - **Owner**: [Name] - **Due Date**: [Date] - **Verification Method**: [How success will be measured]