This Material is developed by Enhance Your Future Pty Ltd for Australian Institute of Science

and Technology (AIST)

 ICTSAS505 - Review and
update disaster recovery and
contingency plans
 Evaluate impact of system on business continuity
 Evaluate threats to system
 Formulate prevention and recovery strategy
 Develop disaster recovery plan to support strategy
 TOPIC 1 – EVALUATE IMPACT OF
SYSTEM ON BUSINESS CONTINUITY

 Welcome to the unit ICTSAS505 - Review and update disaster recovery and contingency plans.
 This unit describes the skills and knowledge required to analyse the impact of the system on the
organisation and carry out risk analysis, disaster recovery and contingency planning.
 It applies to individuals who apply a wide range of higher level technical skills and systematic
problem solving approaches in information and communications technology (ICT) related areas.
  
IDENTIFY BUSINESS CRITICAL FUNCTIONS AND THE SECURITY
ENVIRONMENT FROM DOCUMENTATION AND FROM DISCUSSION WITH
BUSINESS AREA AND PROJECT TEAM

 Planning for disaster recovery and business continuity are imperative to minimise risk and enable a business to continue to
be able to operate after unexpected events, changes and serious disruptions.
  In order to develop, review or update disaster recovery and contingency plans, it is necessary to evaluate the impact of the
system on business continuity.
 Information is gathered through a combination of accessing documentation and engaging in discussions with business
areas and other relevant personnel.
ANALYSE THE CLIENT BUSINESS DOMAIN

 Gathering information about the client’s business domain is important.

 Regardless of a how good a person’s knowledge is in their own technical field, each business and industry will have
differences in the way they operate, resources they use and how they use them.
 IT (information technology) infrastructure material gathered to identify and evaluate the impact of a system on business
continuity will include information on:
 Networks
 Facilities
 Data
 Software
 Hardware
 Any other related resources and services
BUSINESS CRITICAL FUNCTIONS

 To facilitate business continuity, it is necessary to identify which parts of a business are critical for it to operate.
 Critical functions for many types of business may include:
 Customer service functions
 Payroll
 Financial
 Production
 Functions and systems critical for business continuity can be identified through surveying organisational business areas
and arranging workshops or meetings where managers discuss their systems individually and as a whole.
THE ENVIRONMENT

 Identifying the security environment can be done from documentation and discussions with the
relevant business area and project team (e.g. business clients, business analysts, solution developers
including third party ones).
 The environment may include:
 Organisational security policies
 Threats to security that may be present in the environment
 Customs (habitual practices)
 Relevant expertise and knowledge
IDENTIFY CRITICAL DATA AND SOFTWARE
FROM DOCUMENTATION

 Data and software need to be assessed from documentation to determine which are critical and which
are not.
  Most organisations contain data within some systems that is irreplaceable, unique and therefore
critical to the organisation being able to function properly.
  Organisational software may or may not be critical depending upon how easy and cost effective it is
to recover or replace.
ASSESSMENT FORMS TO IDENTIFY CRITICAL DATA AND SOFTWARE

 Assessment forms are completed by management, users and IT staff to form part of the
documentation for analysis to determine critical data and software.
 Assessment forms include those for:
 Software (columns for which software is used, and frequency of use)
 Data (columns for data used, data created
 Resources and facilities
SOFTWARE

 A software assessment form would identify which software is used and how frequently it is used.
 It would include column headings for items such as:
 Which software is used
 Frequency of use (e.g. columns for ‘rarely’, ‘1-3 times a week’, ‘daily’, ‘2-3 times daily’, ‘more frequently’).
 Afterwards, to analyse critical areas, it is important to specify the assumption.
 Analysis of impact must occur for each assumption made on software accessibility.
DATA

 A data assessment form would be completed for each system and include sections to identify the
following:
 Data source - where the data originates from: source documents, reports, irrecoverable sources
such as conversations/phone calls, developed at the workstation, from other data files, other (to
be specified) etc.
 Data activity for each system and percentage of use of system for that activity
 Some files/documents may be unrecoverable, and critical to the individual, but not critical to business
continuity.
ASSESS POTENTIAL IMPACT OF BUSINESS
RISK AND THREATS ON ICT SYSTEMS

 A business impact analysis (BIA) is a systematic process conducted to identify and evaluate the
potential effects of an interruption or change to critical business operations and systems.
 Interruptions can occur due to contingencies.
 Contingencies are future circumstances or events that are possibilities, but are not expected to
necessarily occur.
 A BIA can be done as part of a disaster recovery plan to identify and evaluate the impact of an
interruption to critical business systems which occur as a result of system downtime or failure.
FINANCIAL IMPACT

 What would the impact of a system failure be on the business?

 The answer will depend on whether or not that system is critical to business continuity.
 If a business has insufficient or no cash flow, it may not be able to continue, so the financial impact of
system failure is crucial to consider.
IDENTIFY AND EVALUATE STATUTORY REQUIREMENTS,
COMMERCIAL REQUIREMENTS AND CONTINGENCY POSSIBILITIES
ACCORDING TO SPECIFICATIONS AND COST CONSTRAINTS

 All organisations are subject to commercial and statutory requirements, and severe ramifications and losses can occur if
they are not adhered to.
 Therefore they must be identified and evaluated.
STATUTORY AND COMMERCIAL REQUIREMENTS

 Statutory requirements include laws such as those relating to:

 Work Health and Safety
 Privacy
 Confidentiality
 Banking
 Reporting
 Commercial (business) requirements may include:
 Access to internal network
 Firewalls
 Passwords/logins to be used to access systems
 Encryption
 Integrity
STATUTORY DOCUMENTATION

 Specific statutory documentation may be required to be created, completed and kept, such as
registers, minutes of meetings, reports, various records and other documentation depending upon the
business type.
 This may require functioning software, hardware, resources and time.
 Wherever time and resources are involved, cost is usually involved too.
IT SECURITY ASSURANCE

 Information security is the protection of the integrity, confidentiality and availability of information.
 IT security assurance is a vital aspect in determining how reliable and trustworthy the IT system is.
 Security assurance specification incorporates the detailing of the measures taken during the design,
development and implementation of the system to assure compliance with security policies and
requirements.
ISO/IEC TR 15443

 ISO/IEC TR 15443-2012 is a professional international standard which is essentially a framework for

IT security assurance to assist IT professionals.
 It contains definitions and concepts for understanding IT security assurance.
 This standard also provides guidance on assessment methods and assurance evidence.
INTERPRET AND ANALYSE KEY WORKPLACE HEALTH AND SAFETY, LEGISLATIVE AND ORGANISATIONAL REQUIREMENTS RELEVANT TO THE TASK

 Whenever tasks are being completed, there are work health and safety (WHS) requirements which must be taken into
account.
 They include legislative and organisational WHS requirements.
LEGISLATIVE

 Legislative requirements will depend upon the tasks being performed and the industry.
 WHS legislation provides a foundation and structure with the aim of protecting the health and safety of people in the
workplace and others who may be affected by it.
 WHS legislation also incorporates laws for specific industries and tasks.
 Legislation and guidelines can be interpreted and analysed by perusing them to determine where they may relate to tasks
that will be performed for work purposes.
ORGANISATIONAL

 Organisational WHS requirements are contained within organisational policies and procedures.
 They are often based upon legal requirements.
 Interpreting and analysing organisational WHS requirements can be achieved through:
 Accessing and reading the policies and procedures which relate to the relevant department and tasks (such as disaster
recovery)
 Training sessions and workshops on organisational WHS procedures and how to complete tasks in accordance with
them
 TOPIC 2 - EVALUATE THREATS TO SYSTEM

 IDENTIFY THREATS TO THE SYSTEM, CONSIDERING SECURITY ANALYSIS AND INTERNAL AND
EXTERNAL BUSINESS ENVIRONMENT
 What documentation already exists?
 At the time each system began, there would usually have been a business case or proposal for it, which would have
incorporated a risk analysis.
 Documentation on risk analysis needs to be reviewed to determine what risk issues have already been identified.
 If there is no documentation, survey the business areas and arrange discussions and form completion with relevant
management to identify risks and potential issues which could result from them.
SECURITY RISK ANALYSIS

‘Knowing our risks provides opportunities to manage and improve our chances of
success.’ Roger VanScoy

 Risk analysis will need to be undertaken to determine the potential impact of risks and threats on ICT (information and
communication technology) systems.
 Risk analysis is a review of risks associated with particular events such as system downtime.
 It takes into account the likelihood of an event happening, and the consequences:
 Likelihood
 Consequences
 Once a security risk analysis is
conducted and the threats 1. Identify
systems
identified with their likelihood included in
analysis
and consequences, the risks can
then be ranked or prioritised. 6. Review costs 2. Risk
versus benefits. Assessment -
 Security risk analysis is crucial to Identify Threats
& Vulnerabilities
Implement Plan
the security of the system.
SECURITY
RISK
ANALYSIS

5. Identify Risk
3. Assess
Treatments to
Likelihood of
prevent or
event
recover from a
happening
risk

4. Assess
Consequences
 THREATS –INTERNAL AND EXTERNAL ENVIRONMENT

 All possible threats to the ICT system need to be identified and assessed.
 Internal threats come from within the organisation and may occur from hardware or software failure or deliberate or
accidental actions by staff or other insiders.
 Threats to ICT systems are constantly changing and increasing, and include:
 Malware
 Viruses (malicious software that replicates itself and infects other computers and programs)
 Hackers and sabotage
 Ransomware (renders files unreadable unless a set fee is paid)
SYSTEM VULNERABILITIES

 System vulnerabilities need to be identified as they make the system more prone to threats and those threats more likely to
succeed.
 Some examples of system vulnerabilities include software not being patched and updated, USB drives infecting the
network from inside a firewall, wireless access points, and sensitive data stored electronically is not encrypted.
 Vulnerability assessments can be conducted from different viewpoints:
 Outside looking in (e.g. hacker viewpoint)
 Inside looking around (e.g. employee viewpoint)
EVALUATE RISK MINIMISATION
ALTERNATIVES AGAINST SPECIFICATIONS
AND COST CONSTRAINTS

 Once threats have been identified and assessed, risk treatment strategies need to be formulated.
 This involves identifying strategies to minimise risks and then evaluating them against cost
constraints and specifications.
RISK MINIMISATION ALTERNATIVES

 Risk minimisation alternatives for critical systems can involve either:

 Prevention or;
 Recovery
 Some events can be prevented with advance planning, and others cannot. Preventative measures may
stop an event occurring entirely or may prevent the event being major, problematic and costly.
SPECIFICATIONS AND CONSTRAINTS

 When selecting options to minimise risk, the alternatives are evaluated against specifications and cost
constraints.
 Prevention of a risk is preferable wherever possible, however, if the cost outweighs the benefit, then
recovery might be a better option.
 Specifications (what is required) may come from a range of areas such as:
 Technical requirements
 Current system functionality
 User problem statement
 TOPIC 3 - FORMULATE PREVENTION AND
RECOVERY STRATEGY
 EVALUATE PREVENTION AND RECOVERY OPTIONS TO SUPPORT CRITICAL BUSINESS FUNCTIONS
AGAINST BUSINESS SPECIFICATIONS AND COST CONSTRAINTS

“Even a correct decision is wrong when it was taken too late.” Lee Iacocca
 

 Once critical business functions and systems and threats have been identified, prevention and recovery options need to be
evaluated.
 The choice of option will be dependent upon the particular threat being examined.
 Choice will also be impacted by cost constraints and specifications.
EVALUATE DISASTER RECOVERY PLAN STRATEGIES AND COMPONENTS

 Disaster recovery plan (DRP) strategies need to be developed and evaluated for selection.
 Strategies must be put in place to deal with many factors, including factors such as:
 Physical security
 Denial of service
 System failure – sabotage/hackers
 System failure – accident or power problems
FACTORS TO CONSIDER

 When evaluating alternative disaster recovery plan (DRP) strategies, factors including the following
are to be considered:
 How many risk events will the DRP strategy provide a solution for?
 Compare resources that are currently available against resources required to deal with identified
risk factors.
 Will the current IT infrastructure support implementation of the individual DRP strategy?
 Will current policies, procedures and controls support the DRP strategy?
RECOVERY

 Examples of risk minimisation through recovery:

 Hot site (a standby location/service off premises that allows a business to resume its operation
after a disaster at the original business site)
 Warm site (compromise between a hot and a cold site) – will have some degree of backup,
although data maybe a few days old and site will have hardware and connectivity.
 Cold storage - where inactive data or regular backups are stored securely offline –(helpful when
inactive data may still be required for compliance purposes and provides clean data for file
recovery)
PREVENTION

 Examples of risk minimisation though prevention:

 Fire extinguishers (to prevent or minimise hardware damage)
 Allocated user logins and access rights (to prevent unauthorised access)
 Password control (strong passwords for all users to prevent unauthorised access)
 Anti-virus software (to check for viruses and contain them)
BUSINESS SPECIFICATIONS AND COST CONSTRAINTS

 Prevention and recovery options need to be weighed up against business specifications and cost
constraints.
 Business requirements might also include things such as protecting their reputation (as a damaged
reputation from failing systems can cause severe financial loss).
 Cost-benefit comparisons can assist in making selections from options available.
 Different options for prevention and recovery can be compared through creating tables with columns
to provide scores for cost and business requirements.
COMPARE AND CONTRAST BACK UP METHODS

 Backup methodologies are an important part of disaster recovery and there are many varied options available.
 Effective backup strategies will include:
 Decide what data is critical and what needs to be backed up (identify data on desktop computers, network servers,
laptops, wireless devises and paper records)
 Maintain multiple copies of data
 Keep backups in multiple physical locations
 Back up methods can be compared and contrasted in relation to relevant factors such as cost, suitability, recovery speed,
ease of recovery, reliability, security and any other desired variable.
EVALUATE CURRENT SYSTEM FUNCTIONALITY AND SYSTEMS ENGINEERING

 It is important to consider individual systems in conjunction with how the overall system and data
flows in total.
 Individual systems may flow well, but the overall system may or may not be functioning well as a
whole.
 Systems engineering is an interdisciplinary approach and way to design, connect and manage all
different elements of a system to work together to solve problems and produce results.
REVIEW CURRENT OPERATIONAL PROCEDURES TO ENSURE ADEQUATE RISK SAFEGUARDS AND CONTINGENCY PLANS ARE IN PLACE

 Operational procedures will (or should) contain appropriate and effective risk safeguards and
contingency strategies.
 However, changes in the internal and external environment are always occurring, therefore current
operational procedures will need to be reviewed in order to ensure safeguards and contingency
strategies in place are sufficient.
 Threats to critical systems and risk minimisation alternatives must be identified.
CONTINGENCY PLANS

 The purpose of a contingency plan is to enable a timely and effective response to a significant future event.
 Contingency plans may vary in form and content, but all contingency plans must achieve the following:
 Identify current weaknesses/threats/vulnerabilities
 Minimise disruption to business operations
 Provide strategies to minimise risk (e.g. strategies to implement a disaster prevention program)
 Provide an organised approach (e.g. an organised approach to the disaster recovery process)
FORMULATE PREVENTATION AND RECOVERY STRATEGY

 Information gathered for prevention and recovery including data from risk analysis, plans and
evaluations needs to be organised into a suitable format to aid in decision making.
 A Risk Minimisation Strategy Report for disaster prevention and recovery, provides analysis and
recommendations.
 It essentially contains a proposed contingency plan in a report format. vention and recovery strategies
must be made and included.
 Refer to the resource for the Risk Minimisation Strategy Report for disaster prevention and recovery.
SUBMIT DISASTER RECOVERY AND
PREVENTION STRATEGY TO APPROPRIATE
PERSON FOR APPROVAL

 Proposed strategies need approval before they can be effectively implemented.

 Once the proposed disaster recovery and prevention strategy has been documented in a suitable
format such as a report, it needs to be submitted to the appropriate person for approval.
 Management may or may not require the strategy or report to be presented in person.
TOPIC 4 - DEVELOP DISASTER RECOVERY PLAN
TO SUPPORT STRATEGY

 IDENTIFY AND DOCUMENT RESOURCES REQUIRED FOR DISASTER RECOVERY ACCORDING TO

SPECIFICATIONS AND COST CONSTRAINTS
 After a disaster prevention and recovery (DPR) strategy proposal has been approved it can be implemented.
 An action plan is completed to begin the process.
 General actions required to implement a DPR strategy may include:
 Improving or altering hardware/software
 Implementing additional or new hardware/software
 Improving or altering procedures/policies
 Implementing new procedures/policies
RESOURCES

 After working out specific tasks to be done in order to implement the DPR strategy, the required
resources will become more easily identifiable.
 The current installed operating system may already be capable of performing encryption.
 Resources that may be required to implement DRP strategies include types of:
 Hardware
 Software
 Equipment
 Facilities
IDENTIFY AND DOCUMENT PROCESSES REQUIRED
FOR DISASTER STRATEGY ACCORDING TO
PROJECT STANDARDS

 Project standards are the rules by which the disaster recovery plan project will be conducted.
 Project standards may include:
 Organisational standards
 International standards (ISO, ISO/IEC)
 Australian Standards (AS)
 Standards for projects
STANDARDS

 Examples of standards which may be applicable to projects/documentation/IT security/ and disaster

recovery:
 ISO/IEC 27031 business continuity standard - provides guidelines for ICT readiness for business
continuity and provides guidance for IT disaster recovery
 The ISO/IEC 27000 family of standards covers providing requirements for information security
management systems so they are secure.
 ISO/IEC 27001:2013 includes a section on defining requirements for the control of records and
documents to ensure ISMS (information security management system) documents are controlled
PROCESSES ON HOW TO HANDLE SERIOUS DOWNTIME

 There are many processes that need to be documented for disaster strategy, and they must include clear and specific
directions on how to handle serious downtime.

‘Man is still the most extraordinary computer of all.’ John F.Kennedy

 Processes on how to handle downtime will vary depending upon the business, selected strategy and
situation.
 But processes on how to handle down time need to be clear and detailed and include:
 Relevant and clear policies and procedures on what to do if down time occurs
 Who is responsible for making the decision on when to initiate the disaster recovery plan and what happens if they
are absent
 Processes on how to identify when to cut over to the disaster recovery plan
PROCESSES MUST ADHERE TO REQUIRED STANDARDS

 Documented processes will need to adhere to any required standards for documentation relating to:
 Organisational templates
 Revision of documents and version control
 Storage of documents (electronic and printed copies)
 Distribution of documents
 Sign-off procedures
IDENTIFY CUT-OVER CRITERIA BEFORE INITIATING
DISASTER PLAN

 If the time it will take to restore

the system is greater than the
maximum downtime allowed,
then it is a disaster and it is time Criteria:
to initiate or switch over to the Time to restore
system is greater
disaster recovery plan. than maximum Time to
down time initiate
  The maximum allowable disaster
downtime must be specified recovery plan
clearly. +

Disaster
 DOCUMENT DISASTER RECOVERY PLAN
AND SUBMIT TO APPROPRIATE PERSON FOR
REVIEW AND SIGN-OFF

 The final step is to document the disaster recovery plan and submit it for review and sign off.
 The objective of a disaster recovery plan is to provide documented tasks or processes to recover and protect the business
from a disaster and enable it to resume normal operations.

‘One thing that makes it possible to be an optimist is if you have a

contingency plan for when all hell breaks loose.’ Randy Pausch
EXPLAIN THE BUSINESS PLANNING PROCESS RELEVANT TO THE
DEVELOPMENT OF INFORMATION AND COMMUNICATION TECHNOLOGY (ICT)
BUSINESS SOLUTIONS

 Although the planning process has been discussed throughout the unit, it is important to understand it overall.
 Business planning relevant for ICT solutions is detailed and logically structured.
 ICT planning processes involve taking into account many factors, including:
 Organisational direction and goals
 Current system use and functionality
 ICT objectives (short and long term)
SUMMARY

 Now that you have completed this unit, you should have the skills and knowledge to
analyse the impact of the system on the organisation and carry out risk analysis, disaster
recovery and contingency planning.