Incident Management Guidelines
This page sets out guidelines for managing incidents, whatever the cause. You can also consult our Incident Handling Checklist and print the page for future reference.
Generally, you will need to:
Some steps may not apply to the particular situation you are attempting to manage, as there can never be a 'one size fits all' approach. However, most judgments are down to common sense.
For information on specific types of information security breaches, please refer to the related information links for Viruses, Inappropriate Usage, Unauthorised Access, Theft and Systems Failure.
The first stage of any Incident Management Policy (IMP) should be 'qualification' - does the event qualify as an incident?
Has there been (or is there now) a threat to the organisation's business assets, a breach of regulatory requirements or company policy?
If so, it is necessary to enter the full incident response process.
Qualification can be taken one step further. Is the incident a crisis? The difference between an incident and a crisis is largely based on scale. If the incident is extraordinary and enterprise threatening (for example, September 11th, July 7th, Foot and Mouth, etc), then you should also look at crisis management.
There are five main stages to be considered in an incident response process:
1. Containment
2. Assessment
3. Countermeasures
4. Appraisal
5. Conclusion
Remember that some steps may not be appropriate for your incident. Read them through and apply your own judgment to the situation.
- Record the time, duration and location of the incident.
- Isolate systems and logons to the affected system. For example, introduce new passwords and review system access rights
- Determine whether the system should be isolated or access paths removed to prevent further damage
- Preserve the scene. For example, take photographs, save logs, record evidence, take notes of system connectivity etc
- Create a forensic backup of relevant data or systems. For example, imaging of computer systems
- Identify what records or logs exist for the incident
- Identify other evidence. For example, witnesses, CCTV, manual systems
- Perform general fact-finding
- Determine who should be notified internally
- Determine who should be notified externally
- Determine the extent of damage or penetration
- If an attempt was unsuccessful, establish why it failed
- Establish the value and relevance of evidence
- Interview witnesses or relevant parties
- Perform crime scene analysis
- Gather supporting evidence. For example, carry out penetration tests, network reviews, and risk assessments
- Gather staff evidence. For example, Human Resources records
- Perform a business impact analysis
- Perform appropriate technical upgrades, patches and a configuration review
- Harden network protection
- Review intrusion detection devices and policy
- Adjust server loads and access
- Revise policy and review staff training
- Determine HR and contractual issues (to include external suppliers)
- Review outsourcing agreements (as appropriate) and revise or negotiate liability clauses and warranties
- Manage PR and publicity issues. For example, inform shareholders
- Involve appropriate external parties. For example, your local police force.
- Do you need to report the incident to the police?
- Ask "should we disclose to statutory bodies?" See Incident Reporting
- Review assessment and countermeasures
- Determine whether you have had an internal or external attack
- Address disciplinary issues
- Consider legal proceedings
- Address contractual issues
- Should the incident be kept internal or taken to an external body?
- Should court proceedings or a tribunal be instigated?
- Address PR issues