"The more you get that down on paper, the better you’re going to be in a real crisis,"    

An incident response plan takes its place beside business continuity and disaster-recovery plans as a key corporate document that helps guarantee companies will survive whatever glitch, emergency or calamity comes their way.

The typical response to trouble -- the deer-caught-in-the-headlights look -- is exactly why companies need such a plan,  And while a business continuity plan aims to preserve operations in the face of adversity and a disaster recovery plan details what to do in case of a disaster, an incident response plan is broader, laying out how to respond to scenarios as diverse as data security breaches and network crashes.   

Given their breadth and specificity, these documents are usually lengthy and in need of regular upkeep. They will vary from company to company and even among departments within the same company, but here are five points that all IT-specific plans should contain.

1. A sense of what can happen

You can’t possibly anticipate what will happen in a crisis or during the aftermath -- that’s the nature of the beast. But that doesn’t mean you can’t plan for one, Well-prepared companies pick potential incidents representative of the various crises that could occur and then devise strategies to handle them.

2. A well-chosen team

Managers and above need to name names, They need to identify which departments have roles to play when something happens.

Think broadly, lining up people from the human resources, public relations, legal and purchasing departments to pitch in during an incident. Go outside the company, too, and identify the key suppliers and service groups most likely to play a part during a crisis.
 
"Identify secondary or backup people, too, in case [the first-tier] people are unavailable,".

3. A communication plan

Bridge lines, conference call numbers and Intranet sites will be crucial for getting team members together when they’re trying to fix problems that might have them working in diverse geographical locations.

The plan should also include the individual contact information for team members that goes well beyond office e-mail addresses and phone extensions. The document needs to contain home phone numbers and e-mails along with mobile phone numbers.
 
Finally, the plan needs to say which team member owns communications, so when the time comes, there’s no delay in getting everyone talking.

4. A list of who does what (and when)

Good incident response plans don’t just name the members of the response team; rather, they lay out who will have which responsibilities and authority so they can get right to work.
 
In a crisis, an IT Professional can’t run around and say, ‘Hey, do I have permission to do this?' A public relations person can’t run around and say, ‘Who’s going to approve my release?'. The plan must give them the power to make those decisions quickly.
          
But the plan should also give them guidelines to help them make the best decisions. It should spell out the values and principles that will guide the response and the communications. A hospital IT Manager might establish in his incident response plan that patient safety is the top priority, so that the response team knows that its actions must first align with that goal. Or a university snr manager might state that communicating promptly and honestly with students and faculty is a top concern, thereby establishing for team members that they need to put that above other priorities.

It’s important, too, to assign key roles to specific team members in advance, Determine who will handle communications with the public if needed, internal business colleague and external partners. Pick a particular person to track spending. And assign someone to document the team’s response to an incident -- those notes will be valuable when it comes time to update the incident response plan.
 
Nothing works better than to have a go-to team that’s trained and ready to resolve the problem.

5. A safe, accessible home

Good incident response plans will have detailed, often proprietary, corporate information along with personal contact information for team members. That kind of document should be kept under lock and key, or at least secured deep in the corporate computer system (but please keep in mind that if your Computer / Network systems are inaccessable its not going to be very useful unless there is also a hard copy with appropriate persons).
 
The best approach is to thoroughly think out how and where the information is stored to guarantee access during all sorts of scenarios. Pick staff members who should have hard copies, encrypt documents on CD and have them in an on-site safe, and also have off-site locations that key employees know about but now one else needs to.
 

Plan to revisit and revise

An incident response plan is never really done. Rather, it needs to be revisited and revised as an organization grows, new threats develop, and team members change.

Start by putting someone in charge of managing the document.  IT security executives are often in charge of incident-response plans in larger organizations. Whatever the title, the plan’s manager should update the document not only with everyday items, such as the names of new team members as employees come and go, but also with revisions to policies and procedures as incidents happen. The manager should also train new team members as they come on board and organize regularly scheduled drills, tests and simulations.

Testing requirements

You don’t want to find holes and glitches in your incident response plan when you’re dealing with a denial-of-service attack or a downed server. That’s why it’s so important to test it ahead of time.
 
Start with a desktop-type test, just walking through and acting out the plan; that will help identify any glaring problems with the document before going through the time and expense of a simulation. Then move to the next level by simulating an actual event.