The starting point for any security breach incident plan, good or otherwise, is that is must be formal. By this I mean it has been formalised on media and available to company staff, has been reviewed and signed off by senior company managers and is subject to a regular review procedure.
By submitting your personal information, you agree that TechTarget and its partners may contact you regarding relevant content, products and special offers.
There should be more than one version of the plan and all versions should be synchronised. There should be a basic or high-level plan available to all staff so people know what basic steps they need to take in the event of something going awry.
This version needs to be easily available (e.g. on a company intranet) included as part of the staff handbook and staff should be reminded of the plan regularly and not solely during a new employees joining programme.
Consideration should be given to creating a senior managers/board version of the plan, but the main plan should be created for the managers and people who will form the team that will be the first responders and those that will take over the investigation and management of a breach.
This main plan should start with a policy statement, scope (e.g. company staff, contractors etc.) and a clear definition of what is considered to be a breach. A policy statement needs to be short and encompasses company values, for clarity supplemental policies can be added in later sections of the document covering the nuts and bolts of the plan. For example, a policy covering the reporting of an incident as the header to a section covering reporting mechanisms and procedures.
Key sections that I would expect to find in plan are:
- Policy, definition and scope,
- A diagrammatic representation of the process with key information
- Incident reporting,
- First responders and Incident team composition (names, contact details, roles and responsibilities within the team),
- Incident assessment (including whether forensic evidence gathering is required),
- Incident countermeasures (server/workstation/network isolation, invoking a disaster recovery plan or business continuity plan, evidence gathering, managing media reports and public relations, involving external parties as necessary including the police and forensic investigators),
- Identifying corrective actions (detailed incident review, project and budgetary plan to implement corrective actions, can include company policy and procedures, training, hardware, software etc.),
- Monitoring corrective actions (to the point where the incident team believes that the incident can be closed. A report should then be prepared for file and a summary report prepared for distribution to Senior Managers and the Board).
Peter Wenham is a committee member of the BCS Security Forum strategic panel and director of information assurance consultancy Trusted Management.
Read more on incident response
- Security Think Tank: Planning key to incident response
- Security Think Tank: Incident response – prepare, test, and test again
- Security Think Tank: Three steps to effective incident response
- Security Think Tank: The dos and don’ts of a good incident response plan
- Security Think Tank: Ready for your data breach moment?