Incident Response ProcedureThe security contact for these procedures (Research Collaboration 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 Research Collaboration Security Officer | WITHIN 4 HOURS | In collaboration with the Research Collaboration Security Officer, ensure that suspected affected external federated partners are informed | WITHIN 1 DAY | 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 Research Collaboration 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 |