This article provides background information on the interrelationship between information systems contingency planning and other types of security and emergency management-related contingency planning, organizational resilience, and the systems development life cycle. This document provides guidance to assist personnel in evaluating information systems and operations to determine contingency planning requirements and priorities. The guidance defines a seven-step contingency planning process that includes:
1. Provide guidance on developing effective contingency planning policies.
2. Conduct a business impact analysis to identify and prioritize relevant information systems important to the business continuity of the enterprise.
3. Preventive controls to reduce the impact of system outages and reduce emergency life cycle costs.
4. Develop contingency strategies to quickly restore the system after an outage
5. Develop information system contingency plans, restore information system security and restore information system availability
6. Test systems, train staff, and practice strategies
7. Make sure the maintenance plan is on time and updated regularly.
It’s important to note that this article is helpful in assisting the reader in evaluating information systems and operations. Contingency plans are great for mitigating risk and getting a business back on track. You want to have a contingency plan in place and you want to make sure everyone is on the same page to minimize potential risk that any attack may cause.
A Business Impact Analysis (BIA) is a crucial part of the contingency planning process. The BIA helps the organization categorize the system components, supported mission/business processes, and interdependencies. From there, the organization can map mission/business processes to the system components and interdependencies to prioritize what systems need to be brought back up when recovery is required in the event of an intrusion or breach. Changes in ways companies do business in combination with changes in technology require BIA’s to be performed periodically, typically at least once a year, to ensure it will continue to be effective in the event of a disruption or breach.
A business contingency plan is a strategy for how your organization will respond to important or business-critical events that knock your original plans off track. Executed correctly, a business contingency plan can mitigate risk and help you get back to business as usual—as quickly as possible. You might be familiar with contingency plans to respond to natural disasters—businesses and governments typically create contingency plans for disaster recovery after floods, earthquakes, or tornadoes. But contingency plans are just as important for business risks. For example, you might create a contingency plan outlining what you will do if your primary competitors merge or how you’ll pivot if you lose a key client. You could even create a contingency plan for smaller occurrences that would have a big impact—like your software service going down for more than three hours
NIST Special Publication 800-34 Rev. 1 discusses how organizations should develop, plan, and implement contingency plans for information systems. “Information system contingency planning refers to a coordinated strategy involving plans, procedures, and technical measures that enable the recovery of information systems, operations, and data after a disruption.”
I thought section 2 was interesting in this publication as it discusses the types of plans and how they work together in the broader context of emergency management. Continuity and contingency planning are often confused in their use. Continuity planning typically applies to the mission/business itself whereas contingency planning applies to information systems and provides steps needed to recover it. In a similar manner, I think the types of plans get confused by many firms under the banner of disaster recovery. It’s important to understand the nuance of each plan type as they are designed to address specific scenarios. A poor plan is better than no plan at all, and firms should aspire to implement the various plans in alignment with their business objectives.
I like the last point you made. A poor plan is better than no plan at all. At least initiating a plan and running through it through rehearsal will at least help you pinpoint the weaknesses of the plan and strengthen it. Given that you have a good team that is open to understanding flaws in the system rather than simply ignoring it as a requirement.
NIST Special Publication 800-34 Rev. 1 is a contingency planning guide which provides guide for federal information systems not limited to federal agencies but also for organizations to implement. Contingency planning help as a control measure for recovering information systems services and other IT businesses after a disruption. It is very important to have a contingency strategies.
The managers, Chief Information Officers (CIOs), Senior Agency Information Security Officers (SAISOs), Information System Security Officers (ISSOs), System engineers and architects and System Administrator are the right authority to ensure and enforce contingency compliance with their organizations to have this planning in place for unforeseen circumstances.
1. The BCP focuses on sustaining an organization’s mission/business processes during and after a
disruption. The BCP may also be scoped to address only the
functions deemed to be priorities. A BCP may be used for long-term recovery in conjunction with the
COOP plan, allowing for additional functions to come online as resources or time allow
2. Disaster recovery plan (DRP) is a documented and structured approach that describes how an organization can recover and restore system functionality, data, and infrastructure to quickly resume work after an unplanned incident.
Absence of a disaster recovery plan will pose many risks such as: inability for the company to operate effectively, inability to recover systems and data in the event of a disaster, inability to recover from financial loss, and reputational damage for poor handling of the disaster. DRP plan is important as it contains strategies to minimize the effects of a disaster so the organization can continue its operations.
This document outlined several different plans, their purpose, and scope relative to information system contingency planning. For example, the Disaster Recovery Plan (DRP), which provides procedures for relocating information systems operations to an alternate location, is highlighted. It is considered a structured approach to help an organization recover and restore system functionality, data, and infrastructure to quickly resume work after an unplanned incident. It is one of the most important items for a system to have because there is always the potential for it to fail at any moment. Without a proper plan in place the business can be affected tremendously in loss in profits, reputational, and more. With reference to last week’s material, one extremely important part of a disaster recovery plan is backups.
Key point of the reading for me is the difference between ISCP and DRP
The ISCP differs from a DRP primarily in that the information system contingency plan procedures are developed for recovery of the system regardless of site or location. An ISCP can be activated at the system’s current location or at an alternate site. In contrast, a DRP is primarily a site-specific plan developed with procedures to move operations of one or more information systems from a damaged or uninhabitable location to a temporary alternate location. Once the DRP has successfully transferred an information system site to an alternate site, each affected system would then use its respective ISCP to restore, recover, and test systems, and put them into operation.
NIST 800-34, Rev 1 provides guidance for contingency planning. Section 3.4.1 identifies backup & recovery which takes the system security plan categorization’s availability and determines what recovery strategies an information system should follow. In contrast, a LOW availability system would resort to tape backup or relocate to a cold site. Where as a HIGH availability system would use a hot site, a complete replicant of the system. I thought this was particularly interesting because I haven’t thought about relocation based on availability until I came across this section. It makes sense too, that high availability systems would likely have to be brought up almost immediately after they are brought down. HIGH availability systems in some cases might have a limited time before their impact becomes severe, in some cases might have to be brought back within the hour. Having a consistent contingency plan ensures availability is not compromised.
For a successful organization and proper business operations, Information systems play a vital role in today’s digital era. Organizations face many threats to information security from attackers every day. In this critical situation, always needing to run all business operations regularly is the biggest challenge without any interruption to successful business operation and organizational success. Contingency planning supports establishing requirements, plans, procedures, and technical measures for system continuity operations, facing incident environment, and recovering quickly in case of disaster happen or disruption occurs. Contingency planning defines each unique system and provides a preventive measure, recovery strategies, and system impact level technical consideration.
To develop a contingency plan for an information system one must consider the essential mission and business process, and provide restoration priorities, contingency roles, and responsibilities assigned to individuals. Furthermore, maintain a process in case of system disruption, compromise, and failure. The restoration process must occur without affecting essential operations with review and approval from a designated official within the organization. Information system contingency planning has a critical component of emergency management. The system services emergency events to manage the contingency in business operations like managing disruption without affecting organization sensitive information, legitimate user services, proper recovery in disaster incidents, and more.
Overall the contingency plan focuses on business operations with regularity in the moment of every critical incident and disaster response/recovery process, which gives stability to businesses and organizations to continue to grow business in the future.
This article helps organization in categorizing their information system impact through FIPS 199 and provide guidance in their information system contingency plan.
“Information system contingency planning refers to a coordinated strategy involving plans, procedures,
and technical measures that enable the recovery of information systems, operations, and data after a
disruption. Contingency planning generally includes one or more of the following approaches to
restore disrupted services
-Restoring information systems using alternate equipment;
-Performing some or all of the affected business processes using alternate processing (manual)
means (typically acceptable for only short-term disruptions);
– Recovering information systems operations at an alternate location (typically acceptable for
only long–term disruptions or those physically impacting the facility); and
-Implementing of appropriate contingency planning controls based on the information system’s
security impact level” NIST 800-34
The article introduced the 7-step contingency planning process including
1. Develop the contingency planning policy statement
2. Conduct the business impact analysis
3. Identify preventive controls
4. Create contingency strategies
5. Develop an information system contingency plan
6. Ensure plan testing, training, and exercises
7. Ensure plan maintenance
In these steps, business Impact Analysis (BIA) is a crucial part because this analysis determines which operational activities are the most critical, and what resources are used mainly to maintain business continuity during and after a disruption. This analysis helps an organization know where they invest to get an effective cost-benefit analysis.
NIST SP 800 34r1 guides the reader through the development of a contingency plan for Client/server systems, Telecommunications systems, and/or Mainframe systems. I enjoyed reading the section in chapter 2 on types of plans. Each organization needs a group of different plans to truly be prepared for disaster recovery. These plans can include an Occupant Emergency Plan, Information System Contingency Plan, Cyber Incident Response Plan, Crisis Communications Plan, Continuity or Operations Plan, and more.
This framework is a great resource for the government to develop information system contingency planning. As the steps listed:
-Develop policy statement: should mention roles and responsibilities, the scope of organization functions, resources, training, exercise and testing schedules, maintenance schedule, backup and storage minimums.
-Conduct BIA: determine business processes and their recovery, identify resource requirements, identify recovery priorities for system resources. Some terms are important for BIA: MTD-maximum tolerable downtime, RTO-recovery time objective, RPO-recovery point objective.
-Identify Controls
-Create Strategies
-Plan, Test, Train, Exercise: testing procedures, systems recoveries, internal and external connectivity, system performance, restoration of normal operations, other plans. Training of personnel helps them to understand their roles and responsibilities and mitigate the risk of incidents.
-Maintenance: based on the business needs and dynamic tech changes policies are being adjusted and it’s important the check on them. Continuous monitoring helps organizations to stay effective with the tools, produce ongoing updates with the plans, and create assessment reports and milestone documents.
Finding the Cost Balance Point as outlined by NIST 800-34r1 seems like a challenging but useful task. Companies need to calculate how most cost is associated to recover the system at different lengths of time and weigh it against how much the cost of disruption is for the same period of time. Where these two costs intersect is the cost balence point. This is the optimum point in which the total cost of the system disruption is at its lowest amount. Because there is so many different variables that go into these figures, it will not be the same for every organization. So it is important for each company to calculate this themselves, as there is no one size fits all answer.
I agree is a hard but very crucial task when it comes to a disruption of business, these calculations must be accurate or a business could find itself adding to the damage that has already been done
NIST Special Publication 800-34r1 does a very through explanation of providing instructions, recommendations, and considerations for information system contingency planning. One part of this reading that I found of particular interest was Table 2-2 which lists the various types of Contingency plans. This includes the Business Continuity Plan & Disaster Recovery Plan, which we are most familiar with, but there are several more as well. For example, there is the Crisis Communications Plan which is essentially used to explain how to disperse communications, provide critical information, and control rumors. Another one I was unfamiliar with was the Occupant Emergency Plan (OEP), which is used to minimize loss of life/injury as well as protect property damage in response to physical threat. It’s interesting because I assumed there were only a couple contingency plans, but they have several for a variety of different reasons.
The key point I wanted to talk about was 3.4.1 back up and recovery. They are means to restore operations after a disruption. Strategies and methods of recovery and back up should address impact and downtimes that are described in the BIA. Recovery approaches should vary depending on the incident. FIPS 199 describe the potential incidents in a rating of low, moderate and high. With low being little impact with backup of tape and strategy of relocation. Moderate backup of optical backup and strategy of cold or warm site. High of mission critical, backup of mirrored system and strategy of hot site.
I always found the topic of contingency planning to be very interesting, ever since I started studying Information Security in 2013. This document mentions the word detail more than 50 times. It is mentioned frequently because the procedures and protocols that are to be followed by the people involved are indeed detail oriented. “The contingency plan should contain detailed guidance and procedures for restoring a damaged system unique to the system’s security impact level and recovery requirements.” Moreover, the document asserts that “fundamental planning principles are necessary for developing an effective contingency capability.”
This article provides background information on the interrelationship between information systems contingency planning and other types of security and emergency management-related contingency planning, organizational resilience, and the systems development life cycle. This document provides guidance to assist personnel in evaluating information systems and operations to determine contingency planning requirements and priorities. The guidance defines a seven-step contingency planning process that includes:
1. Provide guidance on developing effective contingency planning policies.
2. Conduct a business impact analysis to identify and prioritize relevant information systems important to the business continuity of the enterprise.
3. Preventive controls to reduce the impact of system outages and reduce emergency life cycle costs.
4. Develop contingency strategies to quickly restore the system after an outage
5. Develop information system contingency plans, restore information system security and restore information system availability
6. Test systems, train staff, and practice strategies
7. Make sure the maintenance plan is on time and updated regularly.
Hi Yangyuan,
It’s important to note that this article is helpful in assisting the reader in evaluating information systems and operations. Contingency plans are great for mitigating risk and getting a business back on track. You want to have a contingency plan in place and you want to make sure everyone is on the same page to minimize potential risk that any attack may cause.
A Business Impact Analysis (BIA) is a crucial part of the contingency planning process. The BIA helps the organization categorize the system components, supported mission/business processes, and interdependencies. From there, the organization can map mission/business processes to the system components and interdependencies to prioritize what systems need to be brought back up when recovery is required in the event of an intrusion or breach. Changes in ways companies do business in combination with changes in technology require BIA’s to be performed periodically, typically at least once a year, to ensure it will continue to be effective in the event of a disruption or breach.
A business contingency plan is a strategy for how your organization will respond to important or business-critical events that knock your original plans off track. Executed correctly, a business contingency plan can mitigate risk and help you get back to business as usual—as quickly as possible. You might be familiar with contingency plans to respond to natural disasters—businesses and governments typically create contingency plans for disaster recovery after floods, earthquakes, or tornadoes. But contingency plans are just as important for business risks. For example, you might create a contingency plan outlining what you will do if your primary competitors merge or how you’ll pivot if you lose a key client. You could even create a contingency plan for smaller occurrences that would have a big impact—like your software service going down for more than three hours
NIST Special Publication 800-34 Rev. 1 discusses how organizations should develop, plan, and implement contingency plans for information systems. “Information system contingency planning refers to a coordinated strategy involving plans, procedures, and technical measures that enable the recovery of information systems, operations, and data after a disruption.”
I thought section 2 was interesting in this publication as it discusses the types of plans and how they work together in the broader context of emergency management. Continuity and contingency planning are often confused in their use. Continuity planning typically applies to the mission/business itself whereas contingency planning applies to information systems and provides steps needed to recover it. In a similar manner, I think the types of plans get confused by many firms under the banner of disaster recovery. It’s important to understand the nuance of each plan type as they are designed to address specific scenarios. A poor plan is better than no plan at all, and firms should aspire to implement the various plans in alignment with their business objectives.
Matthew Bryan,
I like the last point you made. A poor plan is better than no plan at all. At least initiating a plan and running through it through rehearsal will at least help you pinpoint the weaknesses of the plan and strengthen it. Given that you have a good team that is open to understanding flaws in the system rather than simply ignoring it as a requirement.
NIST Special Publication 800-34 Rev. 1 is a contingency planning guide which provides guide for federal information systems not limited to federal agencies but also for organizations to implement. Contingency planning help as a control measure for recovering information systems services and other IT businesses after a disruption. It is very important to have a contingency strategies.
The managers, Chief Information Officers (CIOs), Senior Agency Information Security Officers (SAISOs), Information System Security Officers (ISSOs), System engineers and architects and System Administrator are the right authority to ensure and enforce contingency compliance with their organizations to have this planning in place for unforeseen circumstances.
1. The BCP focuses on sustaining an organization’s mission/business processes during and after a
disruption. The BCP may also be scoped to address only the
functions deemed to be priorities. A BCP may be used for long-term recovery in conjunction with the
COOP plan, allowing for additional functions to come online as resources or time allow
2. Disaster recovery plan (DRP) is a documented and structured approach that describes how an organization can recover and restore system functionality, data, and infrastructure to quickly resume work after an unplanned incident.
Absence of a disaster recovery plan will pose many risks such as: inability for the company to operate effectively, inability to recover systems and data in the event of a disaster, inability to recover from financial loss, and reputational damage for poor handling of the disaster. DRP plan is important as it contains strategies to minimize the effects of a disaster so the organization can continue its operations.
This document outlined several different plans, their purpose, and scope relative to information system contingency planning. For example, the Disaster Recovery Plan (DRP), which provides procedures for relocating information systems operations to an alternate location, is highlighted. It is considered a structured approach to help an organization recover and restore system functionality, data, and infrastructure to quickly resume work after an unplanned incident. It is one of the most important items for a system to have because there is always the potential for it to fail at any moment. Without a proper plan in place the business can be affected tremendously in loss in profits, reputational, and more. With reference to last week’s material, one extremely important part of a disaster recovery plan is backups.
Key point of the reading for me is the difference between ISCP and DRP
The ISCP differs from a DRP primarily in that the information system contingency plan procedures are developed for recovery of the system regardless of site or location. An ISCP can be activated at the system’s current location or at an alternate site. In contrast, a DRP is primarily a site-specific plan developed with procedures to move operations of one or more information systems from a damaged or uninhabitable location to a temporary alternate location. Once the DRP has successfully transferred an information system site to an alternate site, each affected system would then use its respective ISCP to restore, recover, and test systems, and put them into operation.
NIST 800-34, Rev 1 provides guidance for contingency planning. Section 3.4.1 identifies backup & recovery which takes the system security plan categorization’s availability and determines what recovery strategies an information system should follow. In contrast, a LOW availability system would resort to tape backup or relocate to a cold site. Where as a HIGH availability system would use a hot site, a complete replicant of the system. I thought this was particularly interesting because I haven’t thought about relocation based on availability until I came across this section. It makes sense too, that high availability systems would likely have to be brought up almost immediately after they are brought down. HIGH availability systems in some cases might have a limited time before their impact becomes severe, in some cases might have to be brought back within the hour. Having a consistent contingency plan ensures availability is not compromised.
For a successful organization and proper business operations, Information systems play a vital role in today’s digital era. Organizations face many threats to information security from attackers every day. In this critical situation, always needing to run all business operations regularly is the biggest challenge without any interruption to successful business operation and organizational success. Contingency planning supports establishing requirements, plans, procedures, and technical measures for system continuity operations, facing incident environment, and recovering quickly in case of disaster happen or disruption occurs. Contingency planning defines each unique system and provides a preventive measure, recovery strategies, and system impact level technical consideration.
To develop a contingency plan for an information system one must consider the essential mission and business process, and provide restoration priorities, contingency roles, and responsibilities assigned to individuals. Furthermore, maintain a process in case of system disruption, compromise, and failure. The restoration process must occur without affecting essential operations with review and approval from a designated official within the organization. Information system contingency planning has a critical component of emergency management. The system services emergency events to manage the contingency in business operations like managing disruption without affecting organization sensitive information, legitimate user services, proper recovery in disaster incidents, and more.
Overall the contingency plan focuses on business operations with regularity in the moment of every critical incident and disaster response/recovery process, which gives stability to businesses and organizations to continue to grow business in the future.
This article helps organization in categorizing their information system impact through FIPS 199 and provide guidance in their information system contingency plan.
“Information system contingency planning refers to a coordinated strategy involving plans, procedures,
and technical measures that enable the recovery of information systems, operations, and data after a
disruption. Contingency planning generally includes one or more of the following approaches to
restore disrupted services
-Restoring information systems using alternate equipment;
-Performing some or all of the affected business processes using alternate processing (manual)
means (typically acceptable for only short-term disruptions);
– Recovering information systems operations at an alternate location (typically acceptable for
only long–term disruptions or those physically impacting the facility); and
-Implementing of appropriate contingency planning controls based on the information system’s
security impact level” NIST 800-34
The article introduced the 7-step contingency planning process including
1. Develop the contingency planning policy statement
2. Conduct the business impact analysis
3. Identify preventive controls
4. Create contingency strategies
5. Develop an information system contingency plan
6. Ensure plan testing, training, and exercises
7. Ensure plan maintenance
In these steps, business Impact Analysis (BIA) is a crucial part because this analysis determines which operational activities are the most critical, and what resources are used mainly to maintain business continuity during and after a disruption. This analysis helps an organization know where they invest to get an effective cost-benefit analysis.
NIST SP 800 34r1 guides the reader through the development of a contingency plan for Client/server systems, Telecommunications systems, and/or Mainframe systems. I enjoyed reading the section in chapter 2 on types of plans. Each organization needs a group of different plans to truly be prepared for disaster recovery. These plans can include an Occupant Emergency Plan, Information System Contingency Plan, Cyber Incident Response Plan, Crisis Communications Plan, Continuity or Operations Plan, and more.
This framework is a great resource for the government to develop information system contingency planning. As the steps listed:
-Develop policy statement: should mention roles and responsibilities, the scope of organization functions, resources, training, exercise and testing schedules, maintenance schedule, backup and storage minimums.
-Conduct BIA: determine business processes and their recovery, identify resource requirements, identify recovery priorities for system resources. Some terms are important for BIA: MTD-maximum tolerable downtime, RTO-recovery time objective, RPO-recovery point objective.
-Identify Controls
-Create Strategies
-Plan, Test, Train, Exercise: testing procedures, systems recoveries, internal and external connectivity, system performance, restoration of normal operations, other plans. Training of personnel helps them to understand their roles and responsibilities and mitigate the risk of incidents.
-Maintenance: based on the business needs and dynamic tech changes policies are being adjusted and it’s important the check on them. Continuous monitoring helps organizations to stay effective with the tools, produce ongoing updates with the plans, and create assessment reports and milestone documents.
Finding the Cost Balance Point as outlined by NIST 800-34r1 seems like a challenging but useful task. Companies need to calculate how most cost is associated to recover the system at different lengths of time and weigh it against how much the cost of disruption is for the same period of time. Where these two costs intersect is the cost balence point. This is the optimum point in which the total cost of the system disruption is at its lowest amount. Because there is so many different variables that go into these figures, it will not be the same for every organization. So it is important for each company to calculate this themselves, as there is no one size fits all answer.
Hello Ryan,
I agree is a hard but very crucial task when it comes to a disruption of business, these calculations must be accurate or a business could find itself adding to the damage that has already been done
NIST Special Publication 800-34r1 does a very through explanation of providing instructions, recommendations, and considerations for information system contingency planning. One part of this reading that I found of particular interest was Table 2-2 which lists the various types of Contingency plans. This includes the Business Continuity Plan & Disaster Recovery Plan, which we are most familiar with, but there are several more as well. For example, there is the Crisis Communications Plan which is essentially used to explain how to disperse communications, provide critical information, and control rumors. Another one I was unfamiliar with was the Occupant Emergency Plan (OEP), which is used to minimize loss of life/injury as well as protect property damage in response to physical threat. It’s interesting because I assumed there were only a couple contingency plans, but they have several for a variety of different reasons.
The key point I wanted to talk about was 3.4.1 back up and recovery. They are means to restore operations after a disruption. Strategies and methods of recovery and back up should address impact and downtimes that are described in the BIA. Recovery approaches should vary depending on the incident. FIPS 199 describe the potential incidents in a rating of low, moderate and high. With low being little impact with backup of tape and strategy of relocation. Moderate backup of optical backup and strategy of cold or warm site. High of mission critical, backup of mirrored system and strategy of hot site.
I always found the topic of contingency planning to be very interesting, ever since I started studying Information Security in 2013. This document mentions the word detail more than 50 times. It is mentioned frequently because the procedures and protocols that are to be followed by the people involved are indeed detail oriented. “The contingency plan should contain detailed guidance and procedures for restoring a damaged system unique to the system’s security impact level and recovery requirements.” Moreover, the document asserts that “fundamental planning principles are necessary for developing an effective contingency capability.”