Author Gary Hibberd
Does incident management need people? We think it does.
When it comes to incident management it pays to make sure everyone is clear on who to call and their roles and responsibilities
Some business owners believe Business Continuity is all about ‘Disaster Recovery Planning’. In fact this is only a third of what is important.
Business Continuity is made up of;
- Incident Management
- Business Continuity
- and Disaster Recovery
You can’t get to the last without going through the first.
Your Incident Management plans need to be clear about roles and responsibilities in a crisis and must contain instructions on call trees and escalation plans. When something goes wrong people need to know who to call. So follow a few ideas to make sure that your customers and teams know who will be helping them when they need help the most.
Top 4 Steps to Incident Management
Talk to your business and decide when you’re going to be open and who is going to be on call. This can include being on call for emergencies or simply on hand to deal with customer inquiries.
Assign Roles & Responsibilities
Ensure everyone is clear about their role over the holiday season. If someone is on call, does it means that they must be available on the phone or be available to drive 25 miles to your Data Centre? Either way, they need to know. It’s no good calling your support team only to hear them singing ‘It’s Christmassssssss’ at full volume down the phone to you!
Write IT down
Sounds obvious but you need to write a plan and make sure you have the number of the IT department who look after your website/systems. This is usually the area that goes wrong when the staffing is lowest.
Communicate your plans
They say that communication is the key to all healthy relationships and I believe that’s true in business too. Make sure everyone understands the expectations placed upon them. Why not send a festive message to your customers and clients and remind them of your opening hours and what to do should they need your help in an emergency? It’s a great way to re-engage and shows you care.
As the saying goes “Business Continuity is not just for Christmas. It’s for life” (well it sort of goes like that)… So no doubt you have all of this in place anyway. But if you haven’t then make this year the year that Business Continuity comes to life and is used in a pro-active way rather than a re-active way.
Speak to a member of the team now on
03455 760 999
We would love to help you, ask for Gary:
ISO 27001 incident management
What ISO 27001 has to say about incident management
ISO 27001 is the international standard for information security. It is an information security management system.
16.1 Management of information security incidents and improvements
Objective: To ensure a consistent and effective approach to the management of information security incidents, including communication on security events and weaknesses.
16.1.1 Responsibilities and procedures
Management responsibilities and procedures should be established to ensure a quick, effective and orderly response to information security incidents.
The following guidelines for management responsibilities and procedures with regard to information security incident management should be considered:
a) management responsibilities should be established to ensure that the following procedures are developed and communicated adequately within the organization:
1) procedures for incident response planning and preparation;
2) procedures for monitoring, detecting, analysing and reporting of information security events and incidents;
3) procedures for logging incident management activities;
4) procedures for handling of forensic evidence;
5) procedures for assessment of and decision on information security events and assessment of information security weaknesses;
6) procedures for response including those for escalation, controlled recovery from an incident and communication to internal and external people or organizations;
b) procedures established should ensure that:
1) competent personnel handle the issues related to information security incidents within the organization;
2) a point of contact for security incidents’ detection and reporting is implemented;
3) appropriate contacts with authorities, external interest groups or forums that handle the issues related to information security incidents are maintained;
c) reporting procedures should include:
1) preparing information security event reporting forms to support the reporting action and to help the person reporting to remember all necessary actions in case of an information security event;
2) the procedure to be undertaken in case of an information security event, e.g. noting all details immediately, such as type of non-compliance or breach, occurring malfunction, messages on the screen and immediately reporting to the point of contact and taking only coordinated actions;
3) reference to an established formal disciplinary process for dealing with employees who commit security breaches;
4) suitable feedback processes to ensure that those persons reporting information security events are notified of results after the issue has been dealt with and closed.
The objectives for information security incident management should be agreed with management, and it should be ensured that those responsible for information security incident management understand the organization’s priorities for handling information security incidents.
Information security incidents might transcend organizational and national boundaries. To respond to such incidents there is an increasing need to coordinate response and share information about these incidents with external organizations as appropriate.
16.1.2 Reporting information security events
Information security events should be reported through appropriate management channels as quickly as possible.
All employees and contractors should be made aware of their responsibility to report information security events as quickly as possible. They should also be aware of the procedure for reporting information security events and the point of contact to which the events should be reported.
Situations to be considered for information security event reporting include:
a) ineffective security control;
b) breach of information integrity, confidentiality or availability expectations;
c) human errors;
d) non-compliances with policies or guidelines;
e) breaches of physical security arrangements;
f) uncontrolled system changes;
g) malfunctions of software or hardware;
h) access violations.
Malfunctions or other anomalous system behaviour may be an indicator of a security attack or actual security breach and should therefore always be reported as an information security event.
16.1.3 Reporting information security weaknesses
Employees and contractors using the organization’s information systems and services should be required to note and report any observed or suspected information security weaknesses in systems or services.
All employees and contractors should report these matters to the point of contact as quickly as possible in order to prevent information security incidents. The reporting mechanism should be as easy, accessible and available as possible.
Employees and contractors should be advised not to attempt to prove suspected security weaknesses. Testing weaknesses might be interpreted as a potential misuse of the system and could also cause damage to the information system or service and result in legal liability for the individual performing the testing.
16.1.4 Assessment of and decision on information security events
Information security events should be assessed and it should be decided if they are to be classified as information security incidents.
The point of contact should assess each information security event using the agreed information security event and incident classification scale and decide whether the event should be classified as an information security incident. Classification and prioritization of incidents can help to identify the impact and extent of an incident.
In cases where the organization has an information security incident response team (ISIRT), the assessment and decision can be forwarded to the ISIRT for confirmation or reassessment.
Results of the assessment and decision should be recorded in detail for the purpose of future reference and verification.
16.1.5 Response to information security incidents
Information security incidents should be responded to in accordance with the documented procedures.
Information security incidents should be responded to by a nominated point of contact and other relevant persons of the organization or external parties (see 16.1.1).
The response should include the following:
a) collecting evidence as soon as possible after the occurrence;
b) conducting information security forensics analysis, as required (see 16.1.7);
c) escalation, as required;
d) ensuring that all involved response activities are properly logged for later analysis;
e) communicating the existence of the information security incident or any relevant details thereof to other internal and external people or organizations with a need-to-know;
f) dealing with information security weakness(es) found to cause or contribute to the incident; g) once the incident has been successfully dealt with, formally closing and recording it. Post-incident analysis should take place, as necessary, to identify the source of the incident. Other information
The first goal of incident response is to resume ‘normal security level’ and then initiate the necessary recovery.
16.1.6 Learning from information security incidents
Knowledge gained from analysing and resolving information security incidents should be used to reduce the likelihood or impact of future incidents.
There should be mechanisms in place to enable the types, volumes and costs of information security incidents to be quantified and monitored. The information gained from the evaluation of information security incidents should be used to identify recurring or high impact incidents.
The evaluation of information security incidents may indicate the need for enhanced or additional controls to limit the frequency, damage and cost of future occurrences, or to be taken into account in the security policy review process (see 5.1.2).
With due care of confidentiality aspects, anecdotes from actual information security incidents can be used in user awareness training (see 7.2.2) as examples of what could happen, how to respond to such incidents and how to avoid them in the future.
16.1.7 Collection of evidence
The organization should define and apply procedures for the identification, collection, acquisition and preservation of information, which can serve as evidence.
Internal procedures should be developed and followed when dealing with evidence for the purposes of disciplinary and legal action.
In general, these procedures for evidence should provide processes of identification, collection, acquisition and preservation of evidence in accordance with different types of media, devices and status of devices, e.g. powered on or off. The procedures should take account of:
a) chain of custody;
b) safety of evidence;
c) safety of personnel;
d) roles and responsibilities of personnel involved;
e) competency of personnel;
Where available, certification or other relevant means of qualification of personnel and tools should be sought, so as to strengthen the value of the preserved evidence.
Forensic evidence may transcend organizational or jurisdictional boundaries. In such cases, it should be ensured that the organization is entitled to collect the required information as forensic evidence. The requirements of different jurisdictions should also be considered to maximize chances of admission across the relevant jurisdictions.
Identification is the process involving the search for, recognition and documentation of potential evidence. Collection is the process of gathering the physical items that can contain potential evidence. Acquisition is the process of creating a copy of data within a defined set. Preservation is the process to maintain and safeguard the integrity and original condition of the potential evidence.
When an information security event is first detected, it may not be obvious whether or not the event will result in court action. Therefore, the danger exists that necessary evidence is destroyed intentionally or accidentally before the seriousness of the incident is realized. It is advisable to involve a lawyer or the police early in any contemplated legal action and take advice on the evidence required.