Incident Response Procedure
The security contact for these procedures (Security Officer) is:
{Security Officer Name + Contact Details (that must still reach Operators in the SO’s absence)}
Unless blank or otherwise stated, the following actions must be taken within the specified deadline as measured from the (suspected) incident first being reported.
Step | Action | Deadline |
1. (Suspected) Discovery | Inform the local security team (if applicable) | WITHIN 4 HOURS |
Inform the federation Security Team | WITHIN 4 HOURS | |
2. Containment | Isolate affected hosts (if feasible) | WITHIN 1 DAY |
Snapshot and/or suspend affected VMs | WITHIN 4 HOURS | |
Disable affected appliances | WITHIN 4 HOURS | |
Disable (suspected) detrimental user access | WITHIN 4 HOURS | |
3. Confirmation | Investigate to confirm whether the incident is real | WITHIN 1 DAY |
4. Downtime Announcement | Announce applicable downtime. The reason e.g. “security operations in progress” should be stated. | WITHIN 1 DAY |
5. Analysis | Collect evidence regarding the incident - as appropriate | |
Perform analysis of the incident - as appropriate | ||
Follow-up on requests from security teams | WITHIN 4 HOURS of receipt | |
6. Debriefing | Prepare a post-mortem incident report in collaboration with the Security Officer | WITHIN 1 MONTH |
7. Normal Service Restoration | Restore normal service operation after incident handling is complete |
Post-mortem incident reports and the associated evidence and analysis must be retained for a period of at least 180 days after normal service operation.
Based on working hours: 1 day is 1 working day, 1 hour is 1 working hour