Incident Response¶
Step-by-step procedures for handling security incidents and service outages within the GRC-ITSM platform.
Overview
GRC-ITSM is the central hub for tracking, documenting, and communicating throughout the incident response lifecycle. Every incident, from initial detection through lessons learned, is managed within the platform to maintain a complete audit trail for compliance with NIST SP 800-171, DFARS, and other applicable frameworks.
1. Incident Ticket Creation¶
When an incident is detected, whether through an automated alert, a security tool, or a user report, an incident ticket must be created in the GRC-ITSM platform immediately.
Required Fields¶
The ticket should capture the following at creation:
| Field | Description |
|---|---|
| Date & Time of Detection | When the incident was first identified |
| Detection Source | Alert system, security tool, user report, etc. |
| Affected Systems & Assets | Systems, services, or assets impacted |
| Initial Severity | Critical, High, Medium, or Low |
| Sensitive Data Involvement | Whether CUI or other sensitive data is potentially involved |
| IRT Personnel | Incident Response Team members assigned to the ticket |
Automated Ticket Creation
Certain security tools (e.g., Huntress) can integrate directly with the GRC-ITSM platform to create incident tickets and notify IRT members automatically upon alert, eliminating the manual creation step for those detection sources.
2. Documentation Throughout Response¶
The GRC-ITSM platform serves as the authoritative record for all actions taken during an incident. At every phase (containment, eradication, and recovery) personnel document their activities within the incident ticket.
What to Document¶
- Private notes on the ticket for each action taken, including timestamps and rationale for key decisions
- Attachments uploaded directly to the ticket: screenshots, log exports, forensic outputs, and tool reports
This creates a centralized repository for investigation artifacts and evidence, and establishes the audit trail needed for compliance with applicable regulatory requirements (e.g., NIST SP 800-171 and DFARS reporting for organizations handling CUI).
3. Communication & Status Updates¶
Internal notifications are driven through the platform's ticket notification system. Update frequency is based on severity:
| Severity | Update Frequency |
|---|---|
| Critical | At least every 4 hours |
| High | At least daily |
| Medium / Low | At each phase transition |
Record All Communications
All incident communications, both internal and external, should be tracked within the ticket to maintain a complete record for audit and compliance purposes.
4. Lessons Learned & Follow-Up Actions¶
After resolution, the Incident Response Team conducts a post-incident review. Findings are documented via private notes on the incident ticket:
- Root cause analysis - what caused the incident
- What worked well - effective response actions and processes
- Gaps identified - areas where the response fell short
- Recommendations - specific improvements to prevent recurrence
Follow-Up Tracking¶
Any improvement actions resulting from the review are tracked as platform items with:
- Assigned owner
- Target completion date
- Status tracking through to closure
5. Audit & Compliance¶
Annual audits of incident response compliance include a review of GRC-ITSM records to verify:
- Incidents were properly detected and tracked
- Response activities were documented at each phase
- Incidents were resolved with appropriate evidence
- Required external reporting was completed on time
DFARS Reporting Requirement
For CUI incidents where DFARS 252.204-7012 applies, DIB-CS notification must be completed within 72 hours of discovery. Verify this timeline is met as part of every CUI incident review.
Any exceptions or procedural violations identified during audit are documented in the GRC-ITSM platform with corrective actions tracked to closure.