In the chapter they mentioned the need for a contingency plan in the event of a disaster, NIST SP 800 34 R1 provides the guidelines for preparing and maintaining information system contingency plans. There is a seven-step contingency plan which includes developing the contingency planning policy statement, conducting a business impact analysis, identifying preventative controls, creating contingency strategies, developing an information system contingency plan, ensuring the planning of testing, training, and exercises, and ensuring plan maintenance. Of these seven I find conducting the business impact analysis the most important because the main purpose is to figure out the critical business processes of supporting systems. The BIA additionally once filled out can help the information system contingency plan lead determine the requirements and priorities.
I agree with you that in developing a contingency plan, the most important thing is to determine the regulatory requirements to ensure that these can be carried out safely. On the other hand, these steps represent key element capabilities in an integrated information system contingency plan. The most important determinations are to ensure these security implementations in the security plan, as these reflect the core of the plan, embodying the key element capabilities of an integrated information system contingency plan.
Understandably I am on your side regarding your contingency planning’s analysis. This is so because interruptions to information technology (IT) system services can have a severe impact on an organization and its ability to carry out its basic functions. IT resources are essential to most business processes, interruptions to information technology (IT) system services can have a severe impact on an organization and its ability to carry out its basic functions. IT resources are essential to most business processes, and organizations depend upon information systems that operate effectively without serious interruptions. When organizations develop and maintain contingency plans for their IT systems, they can create a coordinated strategy to identify technical procedures and methods that will prevent most service disruptions and enable quick recovery should any disruptions occur.
You should have multiple plans to respond to different types of events. Each of these plans should be routinely tested and refined. While developing the contingency plan, the first step is to identify statutory and regulatory requirements, identify and prioritize your critical assets, and pinpoint the resources you need to recover. Next, identify, implement, and maintain controls. Consider backup recovery and alternate site locations. Next, you can draft the policy, then continue to test and refine it.
I often find clients attempting to consolidate all contingency plans into one master plan and this is a bad practice. While it may seem that all response plans are created equal this is not the case. Having a streamlined document for various response types is essential for an effective execution of a plan. No one wants to flip through a BCP to know how to respond to a cyber incident. To that end, I agree with how NIST has segmented the different types of contigency planning documents. This allows the appropiate parties (crisis communication, incident response, IT Ops) understand what role they plan in an incident and how to respond accordingly.
In the Information Systems Contingency Planning Process, a process plan for developing and maintaining effective information systems contingency measures is described. There are seven steps in total: 1. Develop contingency plan policies; 2. Conduct business impact analysis (BIA); 3. Identify preventive controls; 4. Develop contingency strategies; 5. Develop information systems contingency plans; Plan maintenance. These steps represent key element capabilities in an integrated information system contingency plan. Plan development represents the core of information systems contingency planning, is effective and ensures that personnel are fully aware of the organization’s contingency planning requirements, which must be based on clearly defined policies.
The disaster recovery plan is one of the most important plan to include within a business. Every organization must have a Disaster Recovery Plan implemented incase of a castastrophe. As the NIST mentions, the Disaster Recovery Plan is an information system focused designed to restore operability of a target system, application, or computer facility infrastructure at an alternative site after an emergency. The most important aspects of a disaster recovery are the resources/equipment, recovery time, and who has the responsibility of making sure the actions happen within the plan.
I agree the disaster recovery plan is one of the most important plans an organization can have. the DRP can set a simplified process for action in an unexpected event, allowing organizations to recover their systems in a faster time frame.
This chapter explain explicitly about guidance to aid personnel to establish information systems and operations to examine contingency planning requirements and priorities. Hence, Contingency Planning refers to interim measures adopted to bring back IT services following an emergency or system disruption. While it is primarily established for federal systems, NIST SP 800-34r1 has been used as the yardstick for contingency planning throughout much of the private sector. The main focus of a contingency plan is to enable an organization to return to its daily operations as an effective immediately after an unforeseen event has occurred. The contingency plan safeguards resources, lower customer inconvenience and identifies key staff, determining specific responsibilities on the coattails of the recovery.
A key consideration when developing technical contingency planning is routine maintenance of data security, data integrity, and data backups. While it is important to focus on incident response and disaster recovery, consistent data maintenance is crucial to being prepared in the event of a disaster and proactive planning. Data security and integrity maintenance will help ensure the data is safe and accurate within the storage devices. Offsite data backups in a location that would not be susceptible to the same natural disaster as a business’s main location will best prepare a business for ready access in a disaster.
NIST SP 800-34 R1 contains directives on contingency planning for federal information systems. It is crucial to start with the policy for contingency planning to formally document and guide the effort of contingency planning. Another major part of contingency planning is the business impact analysis, which comes second to the policy. The BIA will aid the plan by analyzing crucial information systems that will impact the business’ primary functions. To reduce risk, next preventive controls are identified to maintain and increase availability while also reducing contingency costs. Like most other policies, they should all be living documents that are regularly reviewed and altered as needed based on the relevant conditions facing the business at the time of review.
Great point about how these policies should be considered living documents. There are a handle of circumstances that would require regular review of these documents. For example, changes in personnel and relevant stakeholders. A call tree is only as valuable as it is current, especially during an incident. Being able to contact the necessary individuals in a timely fashion is critical to incident response and disaster recovery.
A business continuity plan focuses on maintaining the organization’s mission and business processes during and after an outage. An example of a business process could be the organization’s payroll process or customer service process. Business continuity plans can be written for individual business units or tasks/business processes within the entire organization’s operations. The focus is on restoring the organization’s essential functions at another location and ensuring that these functions are only operational for 30 days before they can be converted to regular operation. The business continuity plan can address other functions or functions at the field office level.
Thanks for your response, Zijian. I like how you tied this to a real-life example. In this case, it is also critical that the payroll team conducts a business impact analysis (BIA) to understand what specific processes need to be prioritized when recovering from an incident. For instance, employee direct deposit information/schedules should be assigned a HIGH impact rating; and therefore one of the first systems restored.
This document details the step-by-step process which entails contingency plan creation. These steps include developing the contingency planning policy,
conducting the business impact analysis (BIA) (which helps identify and prioritize information
systems and components critical to supporting organizational processes), identifying mitigative/preventive security controls (to reduce disaster/disruption impact), creating contingency strategies, developing an information system contingency plan, coordinating plan testing/training/and exercises, and ensuring plan maintenance. This plan should also reflect the ‘activation and notification phase’ when an incident originally occurs, the ‘recovery phase’ which entails the first steps of recovery such as shifting business operations to alternate sites, and the ‘reconstitution phase’ which coordinates long term recovery and returning to normal business conditions.
A key takeaway of mine from NIST Special Publication 800-34 Rev. 1: Contingency Planning Guide for
Federal Information Systems is the distinct difference between contingency and continuity planning. Contingency planning has to do with plans specific to information systems themselves, whereas continuity planning has to do with plans specific to an organization’s mission/business process. In the overall view of incident and disaster response, both of these types of plans (and more types of plans not yet mentioned, such as COOP, crisis communications, etc,) must come together to not duplicate or leave out necessary steps to take to continue business as normal, so even though they are distinctly different, team working on these types of plans need to communicate well and frequently.
The NIST 800-31 Rev 1 includes the 7 steps that any organization could take to have a viable contingency planning program. The first step in the process is to have a contingency planning policy statement. Then conducting a business impact analysis (BIA) to identify and prioritize the information systems based on their criticality. Once those critical system has been identified, the next step is to be identifying the preventive controls. Then the recovery strategies are being identified to ensure the system can be recovered quickly. After that the system contingency plan is being documented that includes the detailed instruction on recovering the systems. The testing being performed after that to ensure the contingency planning is being implemented effectively for recovering the systems in a timely manner. The final step in the process is to ensure the plan is being revised and updated regularly.
Contingency plans in an organization are super important, and something that all companies should take seriously (knowing what it is, what the processes are, and potentially have dry runs in the case of an emergency).
I feel like this aspect of security may be overlooked by companies, who may think that it will never happen to them.
Contingency Planning refers to interim measures to recover IT services following an emergency or system disruption. While designed for federal systems, NIST SP 800-34 has been used as the guideline for contingency planning throughout much of the private sector.
NIST’s 7-Step Contingency Planning Process
• Develop the contingency planning policy statement.
• Conduct the business impact analysis (BIA).
• Identify preventive controls.
• Create contingency strategies.
• Develop an information system contingency plan.
• Ensure plan testing, training, and exercises.
• Ensure plan maintenance.
In the chapter they mentioned the need for a contingency plan in the event of a disaster, NIST SP 800 34 R1 provides the guidelines for preparing and maintaining information system contingency plans. There is a seven-step contingency plan which includes developing the contingency planning policy statement, conducting a business impact analysis, identifying preventative controls, creating contingency strategies, developing an information system contingency plan, ensuring the planning of testing, training, and exercises, and ensuring plan maintenance. Of these seven I find conducting the business impact analysis the most important because the main purpose is to figure out the critical business processes of supporting systems. The BIA additionally once filled out can help the information system contingency plan lead determine the requirements and priorities.
Hi Dhaval,
I agree with you that in developing a contingency plan, the most important thing is to determine the regulatory requirements to ensure that these can be carried out safely. On the other hand, these steps represent key element capabilities in an integrated information system contingency plan. The most important determinations are to ensure these security implementations in the security plan, as these reflect the core of the plan, embodying the key element capabilities of an integrated information system contingency plan.
Understandably I am on your side regarding your contingency planning’s analysis. This is so because interruptions to information technology (IT) system services can have a severe impact on an organization and its ability to carry out its basic functions. IT resources are essential to most business processes, interruptions to information technology (IT) system services can have a severe impact on an organization and its ability to carry out its basic functions. IT resources are essential to most business processes, and organizations depend upon information systems that operate effectively without serious interruptions. When organizations develop and maintain contingency plans for their IT systems, they can create a coordinated strategy to identify technical procedures and methods that will prevent most service disruptions and enable quick recovery should any disruptions occur.
You should have multiple plans to respond to different types of events. Each of these plans should be routinely tested and refined. While developing the contingency plan, the first step is to identify statutory and regulatory requirements, identify and prioritize your critical assets, and pinpoint the resources you need to recover. Next, identify, implement, and maintain controls. Consider backup recovery and alternate site locations. Next, you can draft the policy, then continue to test and refine it.
I often find clients attempting to consolidate all contingency plans into one master plan and this is a bad practice. While it may seem that all response plans are created equal this is not the case. Having a streamlined document for various response types is essential for an effective execution of a plan. No one wants to flip through a BCP to know how to respond to a cyber incident. To that end, I agree with how NIST has segmented the different types of contigency planning documents. This allows the appropiate parties (crisis communication, incident response, IT Ops) understand what role they plan in an incident and how to respond accordingly.
In the Information Systems Contingency Planning Process, a process plan for developing and maintaining effective information systems contingency measures is described. There are seven steps in total: 1. Develop contingency plan policies; 2. Conduct business impact analysis (BIA); 3. Identify preventive controls; 4. Develop contingency strategies; 5. Develop information systems contingency plans; Plan maintenance. These steps represent key element capabilities in an integrated information system contingency plan. Plan development represents the core of information systems contingency planning, is effective and ensures that personnel are fully aware of the organization’s contingency planning requirements, which must be based on clearly defined policies.
The disaster recovery plan is one of the most important plan to include within a business. Every organization must have a Disaster Recovery Plan implemented incase of a castastrophe. As the NIST mentions, the Disaster Recovery Plan is an information system focused designed to restore operability of a target system, application, or computer facility infrastructure at an alternative site after an emergency. The most important aspects of a disaster recovery are the resources/equipment, recovery time, and who has the responsibility of making sure the actions happen within the plan.
Hi Victoria,
I agree the disaster recovery plan is one of the most important plans an organization can have. the DRP can set a simplified process for action in an unexpected event, allowing organizations to recover their systems in a faster time frame.
This chapter explain explicitly about guidance to aid personnel to establish information systems and operations to examine contingency planning requirements and priorities. Hence, Contingency Planning refers to interim measures adopted to bring back IT services following an emergency or system disruption. While it is primarily established for federal systems, NIST SP 800-34r1 has been used as the yardstick for contingency planning throughout much of the private sector. The main focus of a contingency plan is to enable an organization to return to its daily operations as an effective immediately after an unforeseen event has occurred. The contingency plan safeguards resources, lower customer inconvenience and identifies key staff, determining specific responsibilities on the coattails of the recovery.
A key consideration when developing technical contingency planning is routine maintenance of data security, data integrity, and data backups. While it is important to focus on incident response and disaster recovery, consistent data maintenance is crucial to being prepared in the event of a disaster and proactive planning. Data security and integrity maintenance will help ensure the data is safe and accurate within the storage devices. Offsite data backups in a location that would not be susceptible to the same natural disaster as a business’s main location will best prepare a business for ready access in a disaster.
NIST SP 800-34 R1 contains directives on contingency planning for federal information systems. It is crucial to start with the policy for contingency planning to formally document and guide the effort of contingency planning. Another major part of contingency planning is the business impact analysis, which comes second to the policy. The BIA will aid the plan by analyzing crucial information systems that will impact the business’ primary functions. To reduce risk, next preventive controls are identified to maintain and increase availability while also reducing contingency costs. Like most other policies, they should all be living documents that are regularly reviewed and altered as needed based on the relevant conditions facing the business at the time of review.
Hi Antonio,
Great point about how these policies should be considered living documents. There are a handle of circumstances that would require regular review of these documents. For example, changes in personnel and relevant stakeholders. A call tree is only as valuable as it is current, especially during an incident. Being able to contact the necessary individuals in a timely fashion is critical to incident response and disaster recovery.
Kelly
A business continuity plan focuses on maintaining the organization’s mission and business processes during and after an outage. An example of a business process could be the organization’s payroll process or customer service process. Business continuity plans can be written for individual business units or tasks/business processes within the entire organization’s operations. The focus is on restoring the organization’s essential functions at another location and ensuring that these functions are only operational for 30 days before they can be converted to regular operation. The business continuity plan can address other functions or functions at the field office level.
Thanks for your response, Zijian. I like how you tied this to a real-life example. In this case, it is also critical that the payroll team conducts a business impact analysis (BIA) to understand what specific processes need to be prioritized when recovering from an incident. For instance, employee direct deposit information/schedules should be assigned a HIGH impact rating; and therefore one of the first systems restored.
This document details the step-by-step process which entails contingency plan creation. These steps include developing the contingency planning policy,
conducting the business impact analysis (BIA) (which helps identify and prioritize information
systems and components critical to supporting organizational processes), identifying mitigative/preventive security controls (to reduce disaster/disruption impact), creating contingency strategies, developing an information system contingency plan, coordinating plan testing/training/and exercises, and ensuring plan maintenance. This plan should also reflect the ‘activation and notification phase’ when an incident originally occurs, the ‘recovery phase’ which entails the first steps of recovery such as shifting business operations to alternate sites, and the ‘reconstitution phase’ which coordinates long term recovery and returning to normal business conditions.
A key takeaway of mine from NIST Special Publication 800-34 Rev. 1: Contingency Planning Guide for
Federal Information Systems is the distinct difference between contingency and continuity planning. Contingency planning has to do with plans specific to information systems themselves, whereas continuity planning has to do with plans specific to an organization’s mission/business process. In the overall view of incident and disaster response, both of these types of plans (and more types of plans not yet mentioned, such as COOP, crisis communications, etc,) must come together to not duplicate or leave out necessary steps to take to continue business as normal, so even though they are distinctly different, team working on these types of plans need to communicate well and frequently.
The NIST 800-31 Rev 1 includes the 7 steps that any organization could take to have a viable contingency planning program. The first step in the process is to have a contingency planning policy statement. Then conducting a business impact analysis (BIA) to identify and prioritize the information systems based on their criticality. Once those critical system has been identified, the next step is to be identifying the preventive controls. Then the recovery strategies are being identified to ensure the system can be recovered quickly. After that the system contingency plan is being documented that includes the detailed instruction on recovering the systems. The testing being performed after that to ensure the contingency planning is being implemented effectively for recovering the systems in a timely manner. The final step in the process is to ensure the plan is being revised and updated regularly.
Contingency plans in an organization are super important, and something that all companies should take seriously (knowing what it is, what the processes are, and potentially have dry runs in the case of an emergency).
I feel like this aspect of security may be overlooked by companies, who may think that it will never happen to them.
Contingency Planning refers to interim measures to recover IT services following an emergency or system disruption. While designed for federal systems, NIST SP 800-34 has been used as the guideline for contingency planning throughout much of the private sector.
NIST’s 7-Step Contingency Planning Process
• Develop the contingency planning policy statement.
• Conduct the business impact analysis (BIA).
• Identify preventive controls.
• Create contingency strategies.
• Develop an information system contingency plan.
• Ensure plan testing, training, and exercises.
• Ensure plan maintenance.