Contingency Plan - What is the meaning under ISO/TS requirements

[mazura]

Hello,

Can anyone brief me the meaning of contigency plan under ISO/TS requirements in details? HOw should I go about it?

Thanks.

Mazura
Malaysia

[Marc]

Take a quick look at Contingency Plan Input - A sample contingency plan I have been developing for some basics.

Also see: CONTINGENCY PLANNING FOR THE SMALL ENTERPRISE

Every business and organization can experience a serious incident that can prevent it from continuing normal operations. This can range from a flood or fire to a serious computer malfunction or Information Security incident.

The management of the organization have a responsibility to recover from such incidents in the minimum amount of time, with minimum disruption and at minimum cost. This requires careful preparation and planning.

By outlining the most common steps in contingency planning and disaster recovery, as well as identifying popular tools and solutions, hopefully this web site will help make this process far less daunting.

It is vital that the organization takes the development and maintenance of the disaster recovery or business continuity plan seriously. It is not one of those tasks that can be left until everyone has time to deal with it. A serious incident can affect the organization at any time and this includes the next 24 hours!

The contingency plan needs to be developed by a team representing all functional areas of the organization. If the organization is large enough, a formal project needs to be established, which must have approval and support from the very top of the enterprise.

One of the first contingency planning tasks to be undertaken is to prepare a comprehensive list of the potentially serious incidents that could affect the normal operations of the business. This list should include all possible incidents no matter how remote the likelihood of their occurrence.

Against each item listed the project team or manager should note a probability rating. Each incident should also be rated for potential impact severity level. From this information, it will become much easier to frame the plan in the context of the real needs of the organization.

Once the assessment stage has been completed, the structure of the plan can be established. The plan will contain a range of milestones to move the organization from its disrupted status towards a return to normal operations.

The first important milestone is the process which deals with the immediate aftermath of the disaster. This may involve the emergency services or other specialists who are trained to deal with extreme situations.

The next stage is to determine which critical business functions need to be resumed and in what order. The plan will of necessity be detailed, and will identify key individuals who should be familiar with their duties under the plan.

Once this plan has been developed it must be subjected to rigorous testing. The testing process itself must be properly planned and should be carried out in a suitable environment to reproduce authentic conditions in so far as this is feasible.

The Plan must be tested by those persons who would undertake those activities if the situation being tested occurred in reality. The test procedures should be documented and the results recorded. This is important to ensure that feedback is obtained for fine tuning the Plan.

Equally, it is important to audit both the plan itself, and the contingency and back up arrangements supporting it. No short cut can be made here.

This stage is dependent upon the development of the plan and the successful testing and audit of the plans activities. It is necessary that all personnel must be made aware of the plan and be aware of its contents and their own related duties and responsibilities.

Again, it is important that all personnel take the disaster recovery planning seriously, even if the events which would trigger the Plan seem remote and unlikely. Obtain feedback from staff in order to ensure that responsibilities and duties are understood, particularly those which require close dependency on actions being taken by others.

The plan must always be kept up to date and applicable to current business circumstances. This means that any changes to the business process or changes to the relative importance of each part of the business process must be properly reflected within the plan.

Someone must be assigned responsibility for ensuring that the plan is maintained and updated regularly and should therefore ensure that information concerning changes to the business process are properly communicated.

Any changes or amendments made to the plan must be fully tested. Personnel should also be kept abreast of such changes in so far as they affect their duties and responsibilities.

[Mike S.]

The links provide some good info. Does anyone have contingency plans they would like to post as examples, perhaps with an explanation as to what criteria they used in determining how far to take it/how many contingencies to plan for?

[jmp4429]

In Reply to Parent Post by Mike S.

The links provide some good info. Does anyone have contingency plans they would like to post as examples, perhaps with an explanation as to what criteria they used in determining how far to take it/how many contingencies to plan for?

I'll bite:

Contingency Plans – Contingency Plans have been prepared to provide an uninterrupted supply of finished products to the customer.

6.2.1 Electrical Interruptions -- XXX has a double loop system delivering power to the plant. In the event that one trunk line goes down, the secondary trunk line will provide power to the plant. In the event that both lines are disrupted, an onsite generator capable of providing power to the facility can be brought on-line within minutes.

6.2.2 Water Interruptions -- XXX has a double loop system delivering water to the plant. In the event that one trunk line goes down, the secondary line will provide water to XXX.

6.2.3 Telephone Interruptions --XXX has secondary direct lines into the plant if the main line to the switchboard fails. These secondary lines work independently from the power system. Numerous cell phones are available in the event that the secondary line is disrupted.

6.2.4 Computer Systems -- The computer system is backed up daily with the backup copy taken offsite by a member of the IT (Information Technology) department. A backup copy is placed into a safe deposit box weekly. Back-up servers control the production environment. In the event that one server goes down, the other server will take control of the computer environment within 20 minutes. The servers are attached to a 1 hr UPS which allows the servers to be shut down in an appropriate fashion. The IT department has prepared and maintains an IT-specific Contingency Plan document. [Which is about 2" thick, by the way]

6.2.5 Labor Shortages -- XXX does not have a labor union on site. Any labor shortage will be rectified by working with the local Employment Security Commission.

6.2.6 Key Equipment Failure -- The maintenance department has a partial supply of repair parts on site. Critical spare parts not on site can be delivered from the vendors within three business days.

6.2.7 Finished Goods Inventory -- A finished goods inventory level safety buffer for all finished products is maintained to insure against interrupted customer deliveries caused by production interruptions.

6.2.8 Field Returns – Should an exceptional quantity of Field Returns being experienced require replacement, XXX will deliver replacement parts within twelve to sixteen weeks.

At the last automotive company I worked for, our Key Equipment Failure contingency plan was much more involved. I remember sitting down to develop it: If something should happen to Machine #23001 so that we can’t repair it, in a pinch we can build the product on Machine #27032, etc….

Not sure if this was a customer specific requirement that we get that carried away or not, but it occurred to me that if something that bad happened to a machine, it was probably due to fire, and no other machines would be available either.

[Shaun Daly]

I too struggled with the content of contingency plans. There dont seem to be too many examples evailable to gat a feel of what they should contain.

In the end I knocked up something for the shopfloor based around the 4/6/7 M's.

I still have to knock up a Management Contingency Plan in time for the TS audit <sigh>

[IEGeek - 2006]

In our system and therefore in our BCIR (Business Continuity Incident Recovery Plan) we made one glaring error according to our registrar ~~ we had great plans and call rosters, emergency notifications, utility contacts, supplier and customer contacts etc. All these detailed things to do in the event of an "incident", even down to the smallest detail.

We never defined "incident"?!?!?!?!?!?!?!?!?

Be sure and define what constitutes an incident. This was almost a Major Non-Conformance in the eyes of our registrar.

I would post ours for review, becuase now I think it is a great plan, however in perusing it prior to uploading, there is too much personal information and company specific protected information. Sorry

[Jim Wynne]

In Reply to Parent Post by IEGeek

Be sure and define what constitutes an incident. This was almost a Major Non-Conformance in the eyes of our registrar

A contingency plan should be the result of an FMEA process--brainstorming (what are all of the things that might happen?), ranking of likelihood (a hard drive failure is more likely than a meteor strike) and recommended actions. This will take care of defining what constitutes an "incident."
Another part of it is responsibility and authority; who is responsible for intitiating a plan, and does that person have the requisite authority to make sure the plan is implemented?

[IEGeek - 2006]

Agreed and Agreed

Well Said!!!!