6Q

Business Continuity Plan

The Concepts and Practices of Designing and Implementing a Business Continuity and Disaster Recovery Plan

A Business continuity refers to a plan of action that assures that normal operations continue even in the event of a calamity. A disaster recovery plan, on the other hand, is a subset of ongoing business planning that entails the restoration of critical support systems. Communications, hardware, and IT assets are among the systems (Conklin et al, 2018). When building and implementing a business continuity and disaster recovery plan, goals that strive to minimize downtime as well as a focus on returning technical operations to normal in the shortest amount of time are important considerations. The strategy lays out the steps that colleagues must follow to ensure that normal business operations continue. A business impact study, which estimates the impact of a business function interruption, and data gathering, which is essential to establish recovery plans, are among the plan's priorities (Han et al, 2020). Lost sales and income, higher expenses, client retention, regulatory fines, and contractual penalties are all factors considered. Following the study, the plan will concentrate on data backup and recovery. The plan outlines pre-planned activities and business processes that will negatively influence the company, as well as the measures required to offset the damage.

Testing a Disaster Recovery Plan

Good contingency planning necessitates continuous testing and evaluation of the strategy. Because of the nature of data processing, equipment, programs, and documentation must be updated on a regular basis. It's critical to think of the plan as a living document because of these efforts. A checklist of things for testing a disaster recovery strategy is supplied. When conducting a recovery test, the following are considered (Han et al, 2020):

1. The test's purpose and the components of the plan that are being reviewed.

2. The test's objectives and how to determine whether they were met.

3. Meet with management to discuss the test and goals to secure their approval and support.

4. The test should be announced by management, along with the projected completion time.

5. At the end of the test time, the findings were collected.

6. Assessing the outcome to determine whether the recovery was effective

7. Consider the implications of the test results. Does a successful recovery in a basic case imply that all critical jobs will be restored within the allowed outage time?

8. Make change suggestions by calling for responses by a given date

9. Notify on areas of results including users and auditors

10. Change the disaster recovery plan if necessary.

The disaster recovery plan should also specify the areas that will be tested to ensure its success. Individual application system recovery using off-site files and documents, reloading of system save media, processing capabilities of different machines, management's capacity to establish system priority, and ability to recover and process successfully without key personnel are among the areas covered. Other areas tested include the effectiveness of security measures and security bypass procedures during the recovery period, the plan's ability to clarify areas of responsibility and chain of command, the ability to complete emergency evacuation, and the ability of users of real-time systems to cope with temporary loss of online information.

Risk management plan

A risk management provides insight n ongoing activity that will continue throughout the life of the project and the process should include risk identification, risk assessment, plans for newly identified risks, trigger conditions and contingency plans as well as reports of risks on a regular basis. The management plan has four essential components: risk identification, risk assessment and measurement, risk mitigation, risk reporting and monitoring, and risk governance.

Impact of Change Management Plan on the Overall Risk Strategy

Effective change management assists firms in avoiding the additional and excessive expenditures generated when the people side of change is not appropriately managed by the administration. The purpose of risk management is to recognize potential problems before they occur, so that risk-management measures can be planned and implemented as needed throughout the product or project's life cycle to minimize negative consequences on goal achievement. To be effective, the change management process must consider how a change or replacement will impact the organization's processes, systems, and employees.

One of the most common change risks is that the change program may face strong opposition from end users, impacted groups, and even managers. The management plan considers degrees of resistance, awareness, or desire to support change, stakeholder commitment, leadership support, budgeting, uncertainty, a strategic communication plan, and organized governance. As a result, the plan has an impact on the best methods of risk identification, and the analysis recognizes the severity and extent of the impact on groups, processes, and tools. The more the consequences, the greater the dangers to the change management program (Altamony et al, 2016). Therefore, the management plan influences development of a pram leadership with an understanding of the implementation risk for the program hence overall risk strategy development.

Concepts included in a security plan for the Development of secure software

A secure program is composed of the same fundamental building parts, which comprise concept and planning, architecture and design, implementation, testing, and bug fixing, release and maintenance, and end of life. The concept and planning stage's purpose is to define and evaluate the application concept. This process includes developing a project plan, writing project specifications, and allocating human resources. SDL discovery, security needs, and security awareness training are among the approaches (Fujdiak et al, 2019). The goal of the architectural and design stages is to create a product that fits the requirements. This process includes modeling the application's structure and usage scenarios, as well as selecting third-party components to aid speed up development. Writing the application code, debugging, and creating stable builds appropriate for testing are all part of the implementation stage. Testing and bug fixing entails detecting and correcting application faults, as well as conducting automated and manual tests, identifying problems, and resolving them. New versions and patches are made available during the release and maintenance process. When a piece of software reaches its "end of life," the developer no longer supports it. Specific end-of-life laws may apply to applications that store sensitive data. (Fujdiak et.al, 2019)

References

Altamony, H., Al-Salti, Z., Gharaibeh, A., & Elyas, T. (2016). The relationship between change management strategy and successful enterprise resource planning (ERP) implementations: A theoretical perspective. International Journal of Business Management and Economic Research, 7(4), 690-703.

Conklin, W. A., White, G., Cothren, C., Davis, R. L., & Williams, D. (2018). Principles of computer security: CompTIA Security+ and beyond (5th ed.). McGraw Hill Professional.

Fujdiak, R., Mlynek, P., Mrnustik, P., Barabas, M., Blazek, P., Borcik, F., & Misurec, J. (2019, June). Managing the secure software development. In 2019 10th IFIP International Conference on New Technologies, Mobility and Security (NTMS) (pp. 1-4). IEEE.

Han, W., Xue, J., Zhang, F., & Sun, Z. (2020, October). An Effective Remote Data Disaster Recovery Plan for the Space TT&C System. In International Conference on Machine Learning for Cyber Security (pp. 31-41). Springer, Cham.