Assessment Brief

Qualification BTEC Level 5 HND Diploma in Computing

Unit number Unit 5: Security

Assignment title Security Presentation

Academic Year

Unit Tutor

Issue date Submission date

IV name and date Khoa Canh Nguyen, Michael Omar, Nhung 9th/01/2020

Submission Format
Part 1
The submission is in the form of an individual written report. This should be written in a concise, formal business
style using single spacing and font size 12. You are required to make use of headings, paragraphs, subsections and
illustrations as appropriate, and all work must be supported with research and referenced using the Harvard
referencing system. Please also provide a bibliography using the Harvard referencing system. The recommended
word limit is 2,000–2,500 words, although you will not be penalised for exceeding the total word limit.

Part 2
The submission is in the form of a policy document (please see details in Part 1 above).

Part 3
The submission is in the form of an individual written reflection. This should be written in a concise, formal business
style using single spacing and font size 12. You are required to make use of headings, paragraphs and subsections as
appropriate, and all work must be supported with research and referenced using the Harvard referencing system.
Please also provide a bibliography using the Harvard referencing system. The recommended word limit is 250–500
words, although you will not be penalised for exceeding the total word limit.
Unit Learning Outcomes

LO3 Review mechanisms to control organizational IT security.

LO4 Manage organizational security.

Assignment Brief and Guidance

You work for a security consultancy as an IT Security Specialist.
A manufacturing company “Wheelie good” in Ho Chi Min City making bicycle parts for export has called your
company to propose a Security Policy for their organization, after reading stories in the media related to security
breaches, etc. in organizations and their ramifications.

Part 1
In preparation for this task you will prepare a report considering:
1. The security risks faced by the company.
2. How data protection regulations and ISO risk management standards apply to IT security.
3. The potential impact that an IT security audit might have on the security of the organization.
4. The responsibilities of employees and stakeholders in relation to security.
Part 2
Following your report:
1. You will now design and implement a security policy
2. While considering the components to be included in disaster recovery plan for Wheelie good, justify why
you have included these components in your plan.
Part 3
In addition to your security policy, you will evaluate the proposed tools used within the policy and how they align with
IT security. You will include sections on how to administer and implement these policies

Learning Outcomes and Assessment Criteria

Pass Merit Distinction

LO3 Review mechanisms to control organisational IT security

P5 Discuss risk assessment
procedures.
P6 Explain data protection processes
and regulations as applicable to an
organisation.
M3 Summarise the ISO 31000 risk
management methodology and
its application in IT security.
M4 Discuss possible impacts to
organisational security resulting
from an IT security audit.
D2 Consider how IT security
can be aligned with
organisational policy, detailing
the security impact of any
misalignment.
LO4 Manage organisational security

P7 Design and implement a security
policy for an organisation.
P8 List the main components of an
organisational disaster recovery plan,
justifying the reasons for inclusion.
M5 Discuss the roles of D3 Evaluate the suitability of
stakeholders in the organisation the tools used in an
to implement security audit organisational policy.
recommendations.
Contents
Assessment Brief..................................................................................................................................................... 1
Part 1 .................................................................................................................................................................. 1
Part 2 .................................................................................................................................................................. 1
Part 3 .................................................................................................................................................................. 1
Part 1 .................................................................................................................................................................. 2
Part 2 .................................................................................................................................................................. 2
Part 3 .................................................................................................................................................................. 2
-Introduction- ......................................................................................................................................................... 7
LO3 Review mechanisms to control organisational IT security ............................................................................... 7
P5 Discuss risk assessment procedures. 1.Risk ....................................................................................................... 7
2.Risk assetment .................................................................................................................................................... 8
3.Asset .................................................................................................................................................................... 9
4.Threat ................................................................................................................................................................ 11
5. Risk Identification Procedures .......................................................................................................................... 13
6.Risk assetment procedures................................................................................................................................ 14
P6 Explain data protection processes and regulations as applicable to an organisation. ..................................... 18
1.Data protection ................................................................................................................................................. 18
2.Data protection process .................................................................................................................................... 18
1. Assessment of network security risks............................................................................................................. 18
2. Raise awareness about data security for employees ...................................................................................... 18
3. Data security management ............................................................................................................................ 19
4.Troubleshooting and problem management ................................................................................................... 19
5. Configure the system securely ....................................................................................................................... 19
6. Make sure the network is divided into separate zones ................................................................................... 20
7. Secure DN data by monitoring network security ............................................................................................ 20
8. Control of access ........................................................................................................................................... 20
9. Increased malware protection ....................................................................................................................... 21
10. Update patches regularly ............................................................................................................................. 21
11. Perform encryption ..................................................................................................................................... 21
3.The important of data protection regulations ................................................................................................... 22
P7 Design and implement a security policy for an organisation. .......................................................................... 23
1.Security policy ................................................................................................................................................... 23
2.Example of policy .............................................................................................................................................. 24
3.The most and should that must exist while creating policy. .............................................................................. 28
4.The element of security policy ........................................................................................................................... 30
5.Step in policy development ............................................................................................................................... 36
P8 List the main components of an organisational disaster recovery plan, justifying the reasons for inclusion. .. 38
1.Business continuity . .......................................................................................................................................... 38
2. The components of recovery plan. ................................................................................................................... 38
3. Steps to Building a Disaster Recovery Plan ....................................................................................................... 40
4. The policies and procedures that are required for business continuity. ........................................................... 45
Conclusion ............................................................................................................................................................ 47
References............................................................................................................................................................ 48
Figure 1,risk ............................................................................................................................................................ 8
Figure 2,type of threats ......................................................................................................................................... 12
Figure 3,risk assessment steps............................................................................................................................... 17
Figure 4,illustration ............................................................................................................................................... 19
Figure 5,control access .......................................................................................................................................... 21
Figure 6,conduct an asset inventory ...................................................................................................................... 40
Figure 7,Perform a risk assessment ....................................................................................................................... 41
Figure 8,Define criticality of applications and data ................................................................................................ 41
Figure 9,Define recovery objectives....................................................................................................................... 42
Figure 10,Test and practice your DR plan .............................................................................................................. 44
Figure 11,life cycle ................................................................................................................................................ 45
-Introduction-
Security is one of the most important challenges modern organisations face.

Security is about protecting organisational assets, including personnel, data, equipment and networks
from attack through the use of prevention techniques in the form of vulnerability testing/security
policies and detection techniques, exposing breaches in security and implementing effective responses.

The aim of this unit is to provide students with knowledge of security, associated risks and how security
breaches impact on business continuity.

Students will examine security measures involving access authorisation, regulation of use, implementing
contingency plans and devising security policies and procedures.

LO3 Review mechanisms to control organisational IT security

P5 Discuss risk assessment procedures.

1.Risk
Risk concept:

1.1 Negative school: risk is considered unlucky, loss, loss, danger ...

-Risk is unhealthy, bad, and unexpected.

-Risk (synonymous with risk) is unfortunate.

-Risk is the ability to be in danger or suffer from pain ...

Risks are unintended uncertainties occurring in the production and business process of an enterprise,
adversely affecting the existence and development of an enterprise.

In short, according to the traditional way of thinking, "risk is damage, loss, danger or factors associated
with danger, difficulty or uncertainty that can happen to a person".
Figure 1,risk

2.2 The neutral school

Risk is uncertainty that can be measured.

- Risk is uncertainty that may be related to the occurrence of unexpected events.

-The risk is currently unknown value and the outcome …

2.Risk assetment
-Risk assessment is a term used to describe the overall process or method where you:

+Identify hazards and risk factors that have the potential to cause harm (hazard identification).

+Analyze and evaluate the risk associated with that hazard (risk analysis, and risk evaluation).

+Determine appropriate ways to eliminate the hazard, or control the risk when the hazard cannot be
eliminated (risk control).

-A risk assessment is a thorough look at your workplace to identify those things, situations, processes,
etc. that may cause harm, particularly to people. After identification is made, you analyze and evaluate
how likely and severe the risk is. When this determination is made, you can next, decide what measures
should be in place to effectively eliminate or control the harm from happening.

The CSA Standard Z1002 "Occupational health and safety - Hazard identification and elimination and risk
assessment and control" uses the following terms:

Risk assessment – the overall process of hazard identification, risk analysis, and risk evaluation.

Hazard identification – the process of finding, listing, and characterizing hazards.

Risk analysis – a process for comprehending the nature of hazards and determining the level of risk.
Notes:
(1) Risk analysis provides a basis for risk evaluation and decisions about risk control.
(2) Information can include current and historical data, theoretical analysis, informed opinions, and the
concerns of stakeholders.
(3) Risk analysis includes risk estimation.

Risk evaluation – the process of comparing an estimated risk against given risk criteria to determine the
significance of the risk.

Risk control – actions implementing risk evaluation decisions.

Note: Risk control can involve monitoring, re-evaluation, and compliance with decisions.

3.Asset
An asset is a resource with economic value that an individual, corporation, or country owns or controls
with the expectation that it will provide a future benefit. Assets are reported on a company's balance
sheet and are bought or created to increase a firm's value or benefit the firm's operations. An asset can
be thought of as something that, in the future, can generate cash flow, reduce expenses, or improve
sales, regardless of whether it's manufacturing equipment or a patent.

 An asset is a resource with economic value that an individual, corporation, or country owns or
controls with the expectation that it will provide a future benefit.

 Assets are reported on a company's balance sheet and are bought or created to increase a firm's
value or benefit the firm's operations.

 An asset can be thought of as something that, in the future, can generate cash flow, reduce
expenses or improve sales, regardless of whether it's manufacturing equipment or a patent.

Understanding Assets:
An asset represents an economic resource for a company or represents access that other individuals or
firms do not have. A right or other access is legally enforceable, which means economic resources can be
used at a company's discretion, and its use can be precluded or limited by an owner.

For an asset to be present, a company must possess a right to it as of the date of the financial
statements. An economic resource is something that is scarce and has the ability to produce economic
benefit by generating cash inflows or decreasing cash outflows.

Assets can be broadly categorized into short-term (or current) assets, fixed assets, financial investments,
and intangible assets.

Personal Assets

Personal assets are things of present or future value owned by an individual or household. Common
examples of personal assets include:

 Cash and cash equivalents, certificates of deposit, checking, and savings accounts, money market
accounts, physical cash, Treasury bills

 Property or land and any structure that is permanently attached to it

 Personal property – boats, collectibles, household furnishings, jewelry, vehicles

 Investments – annuities, bonds, the cash value of life insurance policies, mutual funds, pensions,
retirement plans, (IRA, 401(k), 403(b), etc.) stocks

Your net worth is calculated by subtracting your liabilities from your assets. Essentially, your assets are
everything you own, and your liabilities are everything you owe. A positive net worth indicates that your
assets are greater in value than your liabilities; a negative net worth signifies that your liabilities exceed
your assets (in other words, you are in debt).

Business Assets

For companies, assets are things of value that sustain production and growth. For a business, assets can
include machines, property, raw materials and inventory - as well as intangibles such as patents,
royalties, and other intellectual property.

The balance sheet lists a company's assets and shows how those assets are financed, whether through
debt or through issuing equity. The balance sheet provides a snapshot of how well a company's
management is using its resources. There are two types of assets on a typical balance sheet.1

Current Assets
Current Assets are assets that can be converted into cash within one fiscal year or one operating cycle.
Current assets are used to facilitate day-to-day operational expenses and investments.

Examples of current assets include:

 Cash and cash equivalents: Treasury bills, certificates of deposit, and cash

 Marketable securities: Debt securities or equity that is liquid

 Accounts receivables: Money owed by customers to be paid in the short-term

 Inventory: Goods available for sale or raw materials

Fixed Assets

Fixed assets are non-current assets that a company uses in its production or goods, and services that
have a life of more than one year. Fixed assets are recorded on the balance sheet and listed as property,
plant, and equipment (PP&E). Fixed assets are long-term assets and are referred to as tangible assets,
meaning they can be physically touched.

Examples of fixed assets include:

 Vehicles (such as company trucks)

 Office furniture

 Machinery

 Buildings

 Land

The two key differences with business assets are non-current assets (like fixed assets) cannot be
converted readily to cash to meet short-term operational expenses or investments. Conversely, current
assets are expected to be liquidated within one fiscal year or one operating cycle.

4.Threat
Define: A potential for violation of security, which exists when there is an entity, circumstance,
capability, action, or event that could cause harm.

Cyber threats are sometimes incorrectly confused with vulnerabilities. Looking at the definitions, the
keyword is “potential”. The threat is not a security problem that exists in an implementation or
organization. Instead it is something that can violate the security. This can be compared to a vulnerability
which is an actual weakness that can be exploited. The threat always exist, regardless of any
countermeasures. However, countermeasures can be used to minimize the probability of it being
realized.

Types of threats

The NIST definition above states that a threat can be an event or a condition. An event, in this case, also
includes natural disasters, fire, and power outage. It is a very general concept. In cybersecurity, it is more
common to talk about threats such as viruses, trojan horses, denial of service attacks.

Phishing emails is a social engineering threat that can cause, e.g., loss of passwords, credit card numbers
and other sensitive data. Threats to information assets can cause loss of confidentiality, integrity or
availability of data. This is also known as the CIA triad.

The CIA triad, together with three other well known security concepts, is the basis for the STRIDE threat
model. When listing possible threats, it is convenient to use an existing classification as a starting point.
STRIDE is the most well-known classification, proposed by Microsoft in 1999. The name comes from the
initial letters of the different categories, which also makes it easier to remember them.

Figure 2,type of threats

Examples of threats
Recall that a threat is very general. It does not include how to realize it, or even if it is possible in the
current system. Here are a few examples.

+A malicious user reads the files of other users.

+An attacker redirects queries made to a web server to his own web server.

+An attacker modifies the database.

+A remote attacker runs commands on the server.

Each of these examples can easily be mapped to a category in STRIDE. Other examples would be
malware, trojans and worms.

5. Risk Identification Procedures

Risk Identification Procedures include:

1. Risk Integrated Product Team (IPT) identifies list of potential risk items. There are variety
methods of identifying risks. Risk can be identified from:

-Lessons Learned

-Subject Matter Experts (SME)

-Prior Experiences

-Technology Readiness Level (TRL) determination

-Programmatic Constraints

-Brain Storming

-Work Breakdown Structure (WBS)

2. Risks are determined to be acceptable or not. Not all risk items identified in step 1 are accepted.

3. Accepted risks should be recorded and put into a Risk Register

4. Identify root causes for each identified risk

5. Risk analysis should examine each identified risk to refine the description of the risk, isolate the
cause, determine the effects and aid in setting risk mitigation priorities. (Risk Reporting Matrix)
 6. Risk Mitigation Planning should address each risk with action items and due dates.

7. Risk Integrated Product Team (IPT) meets regularly (every 2 weeks) to assess risks and add new
risk items, if necessary.

8. Risks are closed when all the actions to close the risk have been taken. Some risk items are closed
quickly; others are open for a long time. Some are considered watch items and the action plan
doesn’t kick in until certain negative events happen.

9. Closed risks remain in the database for future learning.

Common risk identification methods are:

*Objectives-based risk identification: Organizations and project teams have objectives. Any event that
may endanger achieving an objective partly or completely is identified as risk.

*Scenario-based risk identification: In scenario analysis different scenarios are created. The scenarios
may be the alternative ways to achieve an objective, or an analysis of the interaction of forces in, for
example, a market or battle. Any event that triggers an undesired scenario alternative is identified as
risk.

*Taxonomy-based risk identification: The taxonomy in taxonomy-based risk identification is a breakdown

of possible risk sources. Based on the taxonomy and knowledge of best practices, a questionnaire is
compiled. The answers to the questions reveal risks.

*Common-risk checking: In several industries lists with known risks are available. Each risk in the list can
be checked for application to a particular situation.

6.Risk assetment procedures

1.Risk assessment in practice :

A risk assessment is a careful examination of what, in the workplace, could cause harm to people; to
facilitate an evaluation of any precautions in place and whether further preventative measures are
required. Risk assessment is a pro-active process by which:

• Hazards are identified;

• The risks associated with the hazard are evaluated;

• Appropriate methods to eliminate or control the hazard evaluated.

2.Definitions :
A hazard is something with the potential to cause harm, such as chemicals, working from ladders,
electricity, excessive noise and moving parts of machinery. The risk is the likelihood of that hazard
occurring, combined with the impact of the occurrence i.e. the severity of the potential harm involved.

Step 1: Identify hazards, i.e. anything that may cause harm.

Employers have a duty to assess the health and safety risks faced by their workers. Your employer must
systematically check for possible physical, mental, chemical and biological hazards.

This is one common classification of hazards:

 Physical: e.g. lifting, awkward postures, slips and trips, noise, dust, machinery, computer
equipment, etc.

 Mental: e.g. excess workload, long hours, working with high-need clients, bullying, etc. These are
also called 'psychosocial' hazards, affecting mental health and occurring within working
relationships.

 Chemical: e.g. asbestos, cleaning fluids, aerosols, etc.

 Biological: including tuberculosis, hepatitis and other infectious diseases faced by healthcare
workers, home care staff and other healthcare professionals.

Step 2: Decide who may be harmed, and how.

Identifying who is at risk starts with your organisation's own full- and part-time employees. Employers
must also assess risks faced by agency and contract staff, visitors, clients and other members of the
public on their premises.

Employers must review work routines in all the different locations and situations where their staff are
employed. For example:

 Home care supervisors must take due account of their client's personal safety in the home, and
ensure safe working and lifting arrangements for their own home care staff.

 In a supermarket, hazards are found in the repetitive tasks at the checkout, in lifting loads, and in
slips and trips from spillages and obstacles in the shop and storerooms. Staff face the risk of
violence from customers and intruders, especially in the evenings.

 In call centres, workstation equipment (i.e. desk, screen, keyboard and chair) must be adjusted to
suit each employee.

Employers have special duties towards the health and safety of young workers, disabled
employees, nightworkers, shiftworkers, and pregnant or breastfeeding women.
Step 3: Assess the risks and take action.

This means employers must consider how likely it is that each hazard could cause harm. This will
determine whether or not your employer should reduce the level of risk. Even after all precautions have
been taken, some risk usually remains. Employers must decide for each remaining hazard whether the
risk remains high, medium or low.

Step 4: Make a record of the findings.

Employers with five or more staff are required to record in writing the main findings of the risk
assessment. This record should include details of any hazards noted in the risk assessment, and action
taken to reduce or eliminate risk.

This record provides proof that the assessment was carried out, and is used as the basis for a later
review of working practices. The risk assessment is a working document. You should be able to read it. It
should not be locked away in a cupboard.

Step 5: Review the risk assessment.

A risk assessment must be kept under review in order to:

 ensure that agreed safe working practices continue to be applied (e.g. that management's safety
instructions are respected by supervisors and line managers); and

 take account of any new working practices, new machinery or more demanding work targets.
Figure 3,risk assessment steps
P6 Explain data protection processes and regulations as applicable to an organisation.

1.Data protection
Data protection is the process of safeguarding important information from corruption, compromise or
loss.

The importance of data protection increases as the amount of data created and stored continues to
grow at unprecedented rates. There is also little tolerance for downtime that can make it impossible to
access important information.

Consequently, a large part of a data protection strategy is ensuring that data can be restored quickly
after any corruption or loss. Protecting data from compromise and ensuring data privacy are other key
components of data protection.

2.Data protection process

Before you go into data security for your business, you need to define exactly what data your business
needs to protect. Businesses themselves often do not know exactly what data needs to be protected, or
only know a part of it.

1. Assessment of network security risks

Once you've got all of the data your business has in mind, you need to make an assessment of the risks
your business data might face:

- In case of a network security problem.

- In case of incidents of natural natural disasters such as fires, earthquakes, etc.

-Assessing your data's cybersecurity risks can be done by your company's dedicated cybersecurity staff
or by consulting with a network security specialist. They have the knowledge and experience to point out
potential hazards to business data that you may not be aware of.

-After you have identified risks to the data to be protected, you need to undertake security assessments
of the corporate network. This will allow you to know exactly what security risks are and may have
happened to the corporate network in general, and the data security of the business in particular. From
there, take measures to patch, protect the system or deploy security solutions in accordance with the
model, finance and requirements of the business.

2. Raise awareness about data security for employees

-One of the most potential dangers to corporate data security is the people factor. Therefore, the
implementation of measures to train and raise awareness among employees in the agency on data
security is one of the leading and most effective measures to ensure data safety in Your Business.

- Enterprises need to organize programs of awareness, training of data security for enterprises and
network security periodically. It is the most important solution to minimize enterprise data breaches,
save money from hiring external security services. At the same time, enterprises (enterprises) need to
have documents and documents on data security policies and work processes, using data in the company
to apply management standards and ensure safety. data such as ISO 27001, PCI DSS. These documents
will also be used for awareness training and the application of enterprise data security policies.

3. Data security management

Security risks to corporate data are always present. Therefore, it is not possible to implement security
measures in a short time, but need to do it regularly and continuously. If possible, each business should
have a dedicated leader or individual with knowledge of corporate data security and confidentiality
responsible for monitoring the implementation of security measures and processes. ensure data safety.
This will help reduce the risks of network security for businesses, business data.

4.Troubleshooting and problem management

Figure 4,illustration

Documents about the process of responding to security incidents to the network and corporate data are
essential, helping to minimize the damage caused by network security incidents to the business. .

Alternatively you can also think about hiring professional ANM assessment and troubleshooting units.
These units will be responsible for consulting the response process and coordinating troubleshooting,
helping your business minimize damage when incidents occur.

5. Configure the system securely

All components within the system (including software and hardware) configured to meet security policy
requirements are also an effective way to keep your business data safe. .

Normally, businesses should have standards on configuration for each device before putting it into use.
These standards can be password policies, accounts, services or system configuration, etc.

Some businesses often have a habit of using pre-installed versions for all devices in the system. However,
pre-installed versions often contain old vulnerabilities, not patched regularly, and thus are vulnerable to
system attacks by hackers. Additionally, the security of these installations is not guaranteed (it is possible
that the installation contains malware or vulnerabilities in the first place).

6. Make sure the network is divided into separate zones

- In the event of network security incidents, the separation of separate network areas will help isolate
and minimize the harm caused by cyber security threats such as corporate data leakage, infection.
malicious code, etc.

- Using additional firewalls between untrusted external networks (Internet zones) and local area
networks, the DMZ zone also helps to control access between different network zones. This allows you
to prevent connections from unsecured areas to secure network areas.

- Carry out periodic intrusion testing to ensure that the access policy between network zones is always
implemented correctly.

7. Secure DN data by monitoring network security

Using systems to monitor network traffic both inside and outside the network is essential to control and
detect network data anomalies early, thereby maximizing detection and prevention. early blocking
attacks. The solutions commonly used by businesses today are IDS (intrusion detection system), IPS
(Intrusion Prevention System) and SIEM (Network Security Surveillance System).

8. Control of access
Figure 5,control access

Decentralization and access control policies are indispensable for an enterprise's network. These policies
help to control access inside and outside the system effectively.

To do this, you need to ask the user for only the permissions necessary to do their job. Priority accounts
must be strictly restricted to primary systems, the role of the database administrator or key system. User
activity, especially with respect to sensitive information, that data and that user's account must be
recorded and strictly managed. Keep in mind at the same time - Set strong passwords to protect your
data.

Physical security measures related to access control to corporate buildings and private offices
(commuters, sirens and magnetic card systems, security guards, etc.) are also important. management of
enterprise data access

9. Increased malware protection

Enterprises should also deploy solutions to prevent and protect data against the risk of malicious code.
Currently, there are many solutions to prevent the risk of malware infection at different levels: individual
anti-malware solution for users, centralized anti-malware solution or anti-malware solution at gateway.
etc However, the financial condition and the size of the business let you choose a reasonable solution for
your business.

10. Update patches regularly

More and more new attack methods are coming, so no system can be said to be always secure.
Therefore, updating operating system and software patches is an indispensable job, helping to protect
corporate data, minimizing the risk of attacks on enterprise systems. Of course, to ensure the highest
level of system security, businesses need to synchronously deploy many security solutions and combine
different security policies.

11. Perform encryption

Finally, do the encryption of the data before sending. This is a necessary job to help protect the safety of
business data. In the event of data loss (due to a network security attack or being compressed on the
transmission line), encrypting the data helps you protect important information that falls into the
attacker's hands. You should also use strong encryption to protect your data (preferably using
asymmetric ciphers). The base64 weak encryption methods are insecure and can be easily decoded by
hackers.

3.The important of data protection regulations

Data is becoming more and more valuable. Also, skills and opportunities for retrieving different types of
personal data are evolving extremely fast. Unauthorized, careless or ignorant processing of personal data
can cause great harm to persons and to companies.

Firstly, the purpose of personal data protection isn’t to just protect person’s data, but to protect the
fundamental rights and freedoms of persons that are related to that data. Whilst protecting personal
data it is possible to ensure that persons’ rights and freedoms aren’t being violated. For example,
incorrect processing of personal data, might bring about a situation where a person is overlooked for a
job opportunity or, even worse, loses current job.

Secondly, not complying with the personal data protection regulations can lead to even harsher
situations, where it’s possible to extract all the money from a person’s bank account or even cause a life-
threatening situation by manipulating health information.

Thirdly, data protection regulations are necessary for ensuring and fair and consumer friendly commerce
and provision of services. Personal data protection regulations cause a situation, where, for example,
personal data can’t be sold freely which means that people have a greater control over who makes them
offers and what kind of offers they make.

If personal data is leaked, it can cause companies significant damage to their reputation and also bring
along penalties, which is why it’s important to comply with the person data protection regulations.

To ensure that personal data is secure, it’s important to know what data is being processed, why it’s
being processed and on what grounds. In addition, it’s important to identify which safety and security
measures are in use. All of this is possible through a thorough data protection audit, which identifies the
data flow and whether the data protection regulations are being followed. The audit can be carried out
by answering a set of specific questions that have been prepared for that purpose. The results will give a
clear overview of the procedures and possible data leaks, which can then be stopped.
P7 Design and implement a security policy for an organisation.

1.Security policy
An IT Security Policy identifies the rules and procedures for all individuals accessing and using an
organization's IT assets and resources.

An Information Technology (IT) Security Policy identifies the rules and procedures for all individuals
accessing and using an organization's IT assets and resources. Effective IT Security Policy is a model of
the organization’s culture, in which rules and procedures are driven from its employees' approach to
their information and work. Thus, an effective IT security policy is a unique document for each
organization, cultivated from its people’s perspectives on risk tolerance, how they see and value their
information, and the resulting availability that they maintain of that information. For this reason, many
companies will find a boilerplate IT security policy inappropriate due to its lack of consideration for how
the organization’s people actually use and share information among themselves and to the public.

The objectives of an IT security policy is the preservation of confidentiality, integrity, and availability of
systems and information used by an organization’s members. These three principles compose the CIA
triad:

 Confidentiality involves the protection of assets from unauthorized entities

 Integrity ensures the modification of assets is handled in a specified and authorized manner

 Availability is a state of the system in which authorized users have continuous access to said
assets

The IT Security Policy is a living document that is continually updated to adapt with evolving business and
IT requirements. Institutions such as the International Organization of Standardization (ISO) and the U.S.
National Institute of Standards and Technology (NIST) have published standards and best practices for
security policy formation. As stipulated by the National Research Council (NRC), the specifications of any
company policy should address:

1. Objectives

2. Scope

3. Specific goals

4. Responsibilities for compliance and actions to be taken in the event of noncompliance.

Also mandatory for every IT security policy are sections dedicated to the adherence to regulations that
govern the organization’s industry. Common examples of this include the PCI Data Security Standard and
the Basel Accords worldwide, or the Dodd-Frank Wall Street Reform, the Consumer Protection Act, the
Health Insurance Portability and Accountability Act, and the Financial Industry Regulatory Authority in
the United States. Many of these regulatory entities require a written IT security policy themselves.

An organization’s security policy will play a large role in its decisions and direction, but it should not alter
its strategy or mission. Therefore, it is important to write a policy that is drawn from the organization’s
existing cultural and structural framework to support the continuity of good productivity and innovation,
and not as a generic policy that impedes the organization and its people from meeting its mission and
goals.

2.Example of policy
Data security policy: Workstation Full Disk Encryption

Using this policy

This example policy is intended to act as a guideline for organizations looking to implement or update
their full disk encryption

control policy. Adapt this policy, particularly in line with requirements for usability or in accordance with
the regulations or data

you need to protect.

Background to this policy

Full disk encryption is now a key privacy enhancing technology which is mandated my many regulatory
guidelines.

1.0 Purpose

<Company X> must protect restricted, confidential or sensitive data from loss to avoid reputation
damage and to avoid adversely

impacting our customers. A collection of global regulations (such as <complete as appropriate>) also
require the protection of a

broad scope of data, which this policy supports by restricting access to data hosted on <complete as
appropriate> devices.

As defined by numerous compliance standards and industry best practice, full disk encryption is required
to protect against

exposure in the event of loss of an asset. This policy defines requirements for full disk encryption
protection as a control and
associated processes.

2.0 Scope

1. All <Company X> workstations – desktops and laptops (depending on the type of data you hold and
physical security some

organizations adjust this just to cover laptops).

2. All <Company X> virtual machines.

3. Exemptions: Where there is a business need to be exempted from this policy (too costly, too complex,
adversely impacting

other business requirements) a risk assessment must be conducted being authorized by security
management. See Risk

Assessment process (reference your own risk assessment process).

3.0 Policy

1. All devices in scope will have full disk encryption enabled.

2. <Company X’s> Acceptable Use Policy (AUP) and security awareness training must require users to
notify <complete as

appropriate> if they suspect they are not in compliance with this policy as per the AUP.

3. The AUP and security awareness training must require users to notify <complete as appropriate> of
any device which is lost

or stolen.

4. Encryption policy must be managed and compliance validated by <complete as appropriate>.

Machines need to report to the

central management infrastructure to enable audit records to demonstrate compliance as required.

5. Where management is not possible and a standalone encryption is configured (only once approved by
a risk assessment), the

device user must provide a copy of the active encryption key to IT.

6. <Complete as appropriate> has the right to access any encrypted device for the purposes of
investigation, maintenance or
the absence of an employee with primary file system access. <complete as appropriate, AUP and security
awareness training

will advise users of this requirement. (Depending on your AUP, or agreement with employees you will
want to alter the stance

of this policy requirement).

Sample Data Security Policies

7. The encryption technology must be configured in accordance with industry best practice to be
hardened against attacks.

8. All security related events will be logged and audited by <complete as appropriate> to identify
inappropriate access to

systems or other malicious use.

9. The <complete as appropriate> help desk will be permitted to issue an out-of-band

challenge/response to allow access

to a system in the event of failure, lost credentials or other business blocking requirements. This
challenge/response

will be provided only in the event that the identity of the user can be established using challenge and
response attributes

documented in the password policy.

10. (Some enterprises may have a requirement to practice a tiered approach to data security. This may
involve a set of users that

have particularly sensitive data and require greater security. You can remove this if this is not a
requirement of your business).

A group of sensitive data/VIP users will be identified by the restricted data policy. Users in this group will
require a member

of <complete as appropriate> (e.g. Senior Management or IT) authorization for key changes or challenge
response. The help

desk will not be permitted to access said systems without authorization. These systems are identified as
having access to
highly sensitive, restricted use data and have a requirement for separation of duty. Where identified by
the authentication and

restricted data policy, a system/user will be required to use two factor authentications in accordance
with the <complete as

appropriate> defined standard. The authentication will occur in the pre boot environment.

11. Configuration changes are to be conducted through the <complete as appropriate> change control
process, identifying risks

and noteworthy implementation changes to security management.

4.0 Technical guidelines

Technical guidelines identify requirements for technical implementation and are typically technology
specific.

1. <Complete as appropriate> is the standard product.

2. Strong, industry best practice defined cryptographic standards must be employed. AES-256 is an
approved implementation.

3. The BIOS will be configured with a secure password (as defined by password policy) that is stored by
IT. The boot order

will be fixed to the encrypted HDD. If an override is required by a user for maintenance or emergency
use, the helpdesk can

authenticate the user and then provide the password for the BIOS. The objective being to avoid an
attacker cold booting and

attacking the system.

4. Synchronization with Windows credentials will be configured so that the pre boot environment is
matched to the user’s

credentials and only one logon is required.

5. A pre boot environment will be used for authentication. Credentials will be used to authenticate the
user in compliance with

<complete as appropriate>password security policy. (Some enterprises have a requirement to use two
factor, and this should
be reflected here as required).

5.0 Reporting requirements

1. A monthly report that identifies the % of encrypted systems versus assets in scope

2. A monthly report that identifies the compliance status of managed, encrypted systems

3. A monthly report that identifies the number of lost assets and validation that lost devices have been
handled appropriately.

3.The most and should that must exist while creating policy.
1: Ensure that there is a policy on policies

It sounds a little redundant, but it's important to work within a predefined and agreed upon framework
even when it comes to policy formation. Creating a simple policy on policies that defines the
organization's process for creating new policies is an important first step in maturing policies. This "meta
policy" should include guidance as to what situations constitute the need for a new policy, the format
that new policies should use, and the process that needs to be followed for a new policy to be approved.
If you don't have a process and framework around policy formation, you risk having significant
inconsistency in the outcomes and inconsistency in the creation, which can lead to poor or difficult
enforcement.

2: Identify any overlap with existing policies

This one is simple. Before you create a new policy, check to see if the policy you're planning to create
already exists or if portions of it exist in other policies. If so, consider revising existing policies rather than
creating a brand new one.

3: Don't develop the policy in a vacuum

I've seen individuals sit behind their desks and create policies that they felt were necessary and that
were developed wholly on their own. Most often, this has happened in organizations lacking any kind
of policy governance structure. In most cases, the policies lacked key factors and were slanted in ways
that were not positive for the organization. As you might expect, the policies did good things for the
person developing them, though.

I'm of the opinion that policies need to be developed with input from those that will be affected by
them. While the final policy may ultimately not reflect all opinions, it's important that all stakeholders be
heard to minimize the potential for unintended consequences. Further, policies need to be complete and
additional opinions can help close any gaps that may exist.

4: Step back and consider the need

Are you creating a policy because one is needed or because someone did something you didn't like?
There is a big difference and, again, I have seen policies put into place out of spite and as retribution.
Obviously, that kind of activity wouldn't happen in a reasonable organization. But it also won't happen in
one that has a strict policy on policies, as the policy will generally go through multiple levels for approval
and somewhere along the way, someone will step back and ask the question, "Why do we need this?"

Policies should be enacted when there is a clear need and a clear problem to solve.

5: Use the right words so there is no misunderstanding intent

Policies must be understood to be effective. Use of clear and unambiguous grammar aids in this effort.
Use simple and specific terminology that can be easily understood by everyone. Use the words "must" or
"will" rather than "should" in the body of the policy. The later implies that the action is optional, which
makes the need for the policy questionable. If something is optional, use the word "should" -- but not
when it's a requirement.

Always use an office, department, unit, or job title instead of an individual's name. Examples: "The CIO's
office is responsible for..."; "Contact the assistant to the CFO to..."

Contact emails should always be general department addresses or a Web page that gives further contact
information. Avoid using individual email addresses to prevent the policy from needing updates when
personnel changes occur.

Do not underline subheadings or words that need to be stressed in a sentence. Rather, set subheadings
in bold or italics if a word needs to be stressed. Underlined words can be mistaken for hyperlinks when
the policy is posted online.

6: When possible, include an exceptions process

For every rule, there is an exception... at least in most cases. It's much easier to define in advance how
an exceptions process is to operate before the policy goes into force. Before you say, "I will never allow
exceptions," think again. At some point, a situation will arise that requires an exception. Since policies
are implemented to control behavior and are supposed to level the playing field, it's critical that
exceptions also be granted in a way that is fair and equitable. If you play loose with the exceptions
process, the entire policy could be called into question.

7: Allow some shades of gray

So you've created an absolutely airtight policy and defined an exceptions process that no one can
question. That's a good goal, but it's tough to get there for every policy. This is the point that might get
the most criticism since policies are supposed to create equitable conditions. But I believe that some
policies need to leave a little ambiguity for people to make decisions. That's not to say that the policy
should just let people do whatever they want, but it seems that there are simply too many instances in
which people are allowed to use "that's policy" or "zero tolerance" excuses to avoid doing the right
thing. If your policy leaves a little bit a gray so that a person can make an on-the-fly decision, that's okay.

8: Define policy maintenance responsibility

Most policies require periodic review to ensure their continued applicability. Further, as questions are
raised about the policy, someone needs to be able to provide clarifying information. Make sure that you
always identify the office -- not the individual person -- that is responsible for the policy. You don't
identify individuals since they come and go.

9: Keep senior executives out of the routine when possible

I mentioned the need to identify an exceptions process for policies when that's possible. In one
organization I worked for, that automatically fell to the CEO. Frankly, that was a waste of his time. The
exceptions process that is put into place should empower someone within the organization to handle
exceptions. The identified person does not need to be a VP or the CEO, except when it's required due to
regulation or law. Further, don't expect senior executives to develop every policy. That said, the senior
team should hold responsibility for reviewing new policies before they go into production.

10: Establish a policy library with versioning

There are all kinds of tools out there these days, such as SharePoint, that enable you to store versions of
documents. Every employee should be able to access all appropriate policies all the time. If employees
can't get access to policies, how can they be expected to follow them? When it comes to versioning, as
policies evolve, it's good to see their history to track what has changed over time.

4.The element of security policy

1.Introduction

Small businesses, like all businesses, increasing depend on computer systems and networks to do
business. Email has become a critical communications tool for many small businesses. Websites are
important marketing channels, and for businesses with eCommerce sites important sales producers.
With the increasing dependency on computer systems comes and increasing need to secure them, just
as the door locks and safes secure the brick and mortar and the valuables and secrets of businesses. The
Honeynet Project has researched the security implications of hooking a computer to the Internet
through a modest broadband connection of the type many small businesses employ. Windows and Linux
systems installed without provisions for security were typically scanned, attacked, and compromised
within a week. In addition, from May 2000 through February 2001 the project saw a 100% increase in the
number of scans, indicating that the security threat is growing rapidly. Even if too pessimistic by an order
of magnitude, these findings indicate a serious threat to information security from connections to the
Internet.

Few small businesses, outside of computer consulting and security firms, are inherently or particularly
interested in security, network or otherwise. Security and its associated activities is a drain on resources.
Those resources are needed for the purpose of the business, or represent the profits the business is
intended to generate. Information security is for the most part intangible, its most conspicuous elements
less visible than a lock on the door or a safe. In a paper written for GIAC certification, Greg Bassett
describes an approach for convincing management of the need for computer security. This paper
addresses the considerations that should be made when drawing up a security policy, the foundation
document for information security.

2.Security Policy Document

A security policy document has several functions. As the term suggests, it documents security policies. It
does more than just document them. It provides a framework within which policies can be written,
modified, and assessed. A security policy document should also provide the context that relates the
policies to the business. Internet Security Systems, Walker and Cavanaugh, and many other sources
available in books or on the Internet provide outlines for security policy documents. They give guidance
for writing introductions as well as individual security policies. Guidelines vary in the specific content and
emphasis they recommend. Every security policy document should have an extensive introduction as
well as the individual security policies.

3.Introductory Elements

The introductory section of a security policy document sets the policies in the context of the business
they are intended to protect. The introduction should be tailored to the business, but should address at
least these areas: the purpose of the document; the scope of the document and policies; specific
organizational responsibilities; general and specific objectives of the organization in terms of security
policy; and a threat and risk assessment.

4.Purpose

The purpose of a security policy document, while somewhat standard, can be influenced by the extent to
which the business deals with confidential information, and the means by which systems and networks
are administered, either dedicated in-house staff, additional duties for other staff, or outsourced.

5.Scope
The scope definition should clearly delineate what is covered in the policies, and should resolve
ambiguity about what is not covered. In particular, a small business must decide whether the security
policies cover acceptable use policies and disaster recovery policies. Many sources recommend they do.
For small businesses these may not be necessary. For a small group of employees acceptable use may be
determined by group consensus. For some small businesses the redundancy required for a full disaster
recovery or business continuity plan is financially prohibitive. For others, these and other policies may be
supplemental documents, as the Joint Information Systems Committee in the UK suggests.

6.Responsibilities

Every organization must consider and assign the responsibilities for security. Responsibilities can be
assigned to individuals or to positions within the organization.

7.Objectives

The overall objective of security and security policy is often cited as the triangle of confidentiality,
integrity, and availability of information resources. This definition can be found in the European ITSEC
security criteria of 1991, but its elements are much older than that. For the purposes of a specific
business's security policy the objectives should be enunciated as confidentiality, integrity, and
accessibility of specific resources which are important to the business.

8. Threat and Risk Assessment

The threat and risk assessment is one of the most important elements of the security policy document.
The threat assessment identifies what the policies are intended to protect against. Some threats are
standard, for example the threat of attacks from the Internet and the Honeynet Project research shows.
Other sources of threat may be of less concern to small businesses, such as threats from insiders. The
risk assessment allows management to prioritize the threats to security, which allows the limited
resources that a small business can devote to security to be spent judiciously. It provides a basis for
auditing the document. All policies should address threats identified in this section. If policies are
formulated which do not it indicates more threat assessment is needed. The converse is not true, some
threats may not justify policies if their risks are low. The risk assessment is very specific to the business
and its unique situation.

9.Policy Attributes

Each policy should define a common set of attributes. The business should decide what attributes each
policy should have, and should create a template for security policies which provides a framework for
these attributes. The following sections discuss commonly used attributes. These attributes may be
tailored to fit the business's preferences, but the information they contain ought to be found
somewhere in the security policy document.

10.Identification

Each security policy should have a unique identification. Policies need to be easy to reference both
within the security policy document, in supplemental external documents, and in audit tools such as
coverage matrices. Policy IDs can be numeric, alphanumeric, or textual. Many documents use both a
unique number and a textual name to identify each policy.

11.Policy Statement

The policy statement defines the policy. It should be clear, concise, and unambiguous. The statement
should convey management's intent, but should not be over generalized.

12.Elaboration

It can be useful to elaborate upon the policy statement, providing the thinking behind it, clarifying its
intent, and discussing its limits.

13.Threat addressed

Every policy should be mapped to at least one threat identified in the threat and risk assessment. Many
policies address multiple threats, but if a policy cannot be tied to at least one identified threat then
either the policy should be dropped or the threats reassessed.

14. Exceptions

Like many business policies, security policies are not necessarily absolute. The policy should identify any
foreseeable exceptions. The circumstances of exceptions should be clearly defined, as should the limits.

15.Violations

Every business should consider what actions should be taken when security policies are violated. The
policy framework should provide a means of documenting actions to be taken in response to violations.
While disciplinary policies belong in a personnel manual rather than in the security policy document, the
severity of response for violating particular security policies should be considered and guidelines for
dealing with violations should be documented with them.

16.References
 Some policies stand on their own. Some policies have meaning only when they override, extend, or
complement other policies. The framework should provide a standard way of documenting these
relationships.

17. History

Since policies can change over time, the policy framework needs to allow for tracking the changes to
individual policies. The modification history of policies is important for audits.

18.Areas of Coverage

The areas a security policy document addresses should correspond to the threats identified in the
introductory section. However, individual policies are much more narrowly construed, a single threat can
give rationale for many policies. Many guidelines can be used to identify areas a business's security
policies should cover. The National Infrastructure Protection Center tips and the SANS Top Twenty
Internet security vulnerabilities identify areas which should be considered when writing any security
policy document. While every security policy document will be different, the following sections
enumerate areas that probably need coverage in most of them.

19.Physical Security Policies

Physical security policies are concerned with physical access to server rooms, computers, and other
resources which can be appropriated. These policies may address the security of media such as backup
tapes, emergency recovery diskettes, and printouts; and might address administrative password escrow
notebooks. For businesses that deal with highly sensitive documents the policies might specify handling
and discarding of printouts, CDs, and diskettes.

20.Network Security Policies

Network security policies are typically the most numerous and important since networks are vulnerable
to both internal and external threats if not secured properly. Network security policies cover firewalls,
Virtual Private Networks, wireless access, modem usage, installation of devices on the network, and
anything else concerned with connections to the network. These policies may also address network
monitoring, logging, and intrusion detection.

21.Host Security Policies

Policies regarding the configuration of individual computer systems or hosts may be a part of network
security policies, but usually are distinctive enough to warrant their own classification. Host policies may
cover the configuration of servers, standardization of workstations, allowable software, required
software such as virus protection programs, and what data may be stored on what types of host. Since
unauthorized control of individual host computers is a frequent security threat host policies may address
both intrusion detection that reveals when a host has been compromised, and backup policies which
allow recovery from a compromise. Host security policies may cover a broad range, from high risk
servers exposed on the Internet to what information may be carried on laptops while travelling.

22.User Security Policies

User security policies may cover both what is expected of users in terms of behavior which enhances
security, and how users are treated. User actions can greatly influence the effectiveness of security
policies, for example choosing good passwords and protecting them from inadvertent disclosure. User
security policies should also cover how users are given access to systems and documents, and how users
are grouped for security purposes.

23.Document Security Policies

For any business which deals with sensitive information, document classification will be frequently
referenced in other security policies. Document handling policies may also be needed. Encryption
policies may be a part of document security policies.

24. Documentation Policies

Documentation is not always identified as a key area of security policy, but having adequate procedure
and network documentation greatly enhances the ability to implement policy, to audit for security, and
to insure that policy implementation remains effective as personnel change.

25.Incident Handling Policies

While thorough implementation of good security policies can greatly reduce the likelihood of a security
incident, no action can guarantee an incident will not take place. Defining incident handling policies in
the security policy document is the first step in effective incident handling. Incident handling policies
should express management priorities in responding to security incidents, such as preservation of
evidence verses restoration of services. Such decisions are best contemplated before they are needed.

26.Audit Policies

Audit policies specify the frequency and intensity of various types of security audits. Security is an
ongoing process. Over time threats change, security countermeasures change, the network changes, and
the business changes. Periodic reassessments are necessary to adapt to these changes. The security
policy document itself should be assessed from time to time. The systems and procedures put in place to
implement security policies should be audited to insure they are providing the security intended. Audit
policies should also specify who will carry out different audits, whether employees or external auditors.

27.Conclusion
 The security policy document is the foundation upon which security procedures and practices are built.
It must be a living document, growing and changing over time as the business activities and threats
change. A strong document framework and good security policy templates facilitate the creation of a
thorough, useful security policy document, and provide the flexibility and control needed for effective
modifications. Small businesses need flexibility in creating and modifying security policies in order to
align the needs of the business and the resources available for security with the threats.

5.Step in policy development

1 Identify and define the problem or issue that necessitates the development of a policy

The organisation also needs to know and understand the purpose of policies and to recognise that the
issue or problem can be effectively dealt with by the creation or modification of a policy.

2 Appoint a person or person(s) to co-ordinate the policy development process

The policy development process may take place over several months. There needs to be someone or
perhaps a committee who is "driving" the process.

3 Establish the policy development process

The process requires research, consultation and policy writing tasks. The co-ordinator should develop a
plan of what tasks need to be done, by whom and when.

4 Conduct research

Read policy documents created by other organisations on the same topic

Research legislation on the Internet

Conduct a meeting with staff and other people with experience

Survey participants or a particular group of participants such as coaches

Read minutes of management committee meetings (if allowed)

Read other documents such as annual reports or event reports

Read industry magazines and journals

Seek legal advice

5 Prepare a discussion paper

The purpose of the discussion paper is to explain the nature of the problem or issue, to summarise
 information yielded by research and to suggest a number of policy options. The discussion paper will be
an important tool in the process of consultation.

6 Consultation - Stage 1

Circulating the discussion paper to all stakeholders (interested parties) is a first step in the consultation
process. It may also be necessary to telephone stakeholders and send notices to remind stakeholders to
read the discussion paper. It is then important to gain as much feedback from stakeholders as possible.
This may be effected through workshops, open meetings, your web site and by meetings with
individuals. Several months may be required to ensure that this stage of consultation is thorough.

7 Prepare a draft policy

When there has been sufficient time for consultation processes to be completed the next step is to
prepare a draft policy.

8 Consultation - Stage 2

When the draft policy is completed it should be circulated to key stakeholders, published in the
organisation's newsletter and web site, discussed in further meetings and forums. At this stage it is
necessary to seek help from stakeholders to fine tune the wording, clarify meaning and make
adjustments to the policy before it is finalised.

9 Adoption

When the co-ordinator of the policy development process is reasonably satisfied that all issues and
concerns about the policy have been aired and dealt with, it is time to finalise the policy. The final policy
document needs to be formally adopted by the management of the organisation (management
committee) with an appropriate record entered in to the minutes.

10 Communication

Following formal adoption of the policy it should be communicated far and wide throughout the
organisation and stakeholders. Training sessions may need to be conducted to ensure that organisation
personnel are fully informed and able to implement the policy. If the policy is not well communicated it
may fail.

11 Review and evaluate

The implementation of the policy should be monitored. The policy may still require further adjustments
and furthermore the reasons for the policies existence may change. A general practise is to set a date
 for the policy to be reviewed, this might be one a year or once in every three years. It just depends on
the nature of the policy.

P8 List the main components of an organisational disaster recovery

plan, justifying the reasons for inclusion.

1.Business continuity .
Business continuity is an organization’s ability to ensure operations and core business functions are not
severely impacted by a disaster or unplanned incident that take critical systems offline. Business
continuity planning is the interdepartmental process, often led by information technology, of
implementing the tactics used to restore normal business in a set amount of time, define the amount of
data loss acceptable to the business, and communicate critical information to organizational
stakeholders during and following incidents.

Implementing redundant IT infrastructure and contingency plans were once prohibitively expensive for
all but the largest of organizations, but new economical, on-demand cloud technologies are putting
robust business continuity strategies within reach for millions of businesses.

Common technology services designed for business continuity consist of cloud data backups, cloud-
based disaster recovery as a service (DRaaS) for infrastructure outages, and managed security plans that
protect against increasingly sophisticated cyberattacks.

2. The components of recovery plan.

-Communication plan and role assignments.
When it comes to a disaster, communication is of the essence. A plan is essential because it puts all
employees on the same page and ensures clearly outlines all communication. Documents should have all
updated employee contact information and employees should understand exactly what their role is in
the days following the disaster. Assignments like setting up workstations, assessing damage, redirecting
phones and other tasks will need assignments if you don’t have some sort of technical resource to help
you sort through everything.

-Plan for your equipment.

It’s important you have a plan for how to protect your equipment when a major storm is approaching.
You’ll need to get all equipment off the floor, moved into a room with no windows and wrapped securely
in plastic so ensure that no water can get to the equipment. It’s obviously best to completely seal
equipment to keep it safe from flooding, but sometimes in cases of extreme flooding this isn’t an option.

-Data continuity system.

As you create your disaster recovery plan, you’ll want to explore exactly what your business requires in
order to run. You need to understand exactly what your organization needs operationally, financially,
with regard to supplies, and with communications. Whether you’re a large consumer business that needs
to fulfill shipments and communicate with their customers about those shipments or a small business to
business organization with multiple employees – you should document what your needs are so that you
can make the plans for backup, business continuity and have a full understanding of the needs and
logistics surrounding those plans.

-Backup check.
Make sure that your backup is running and include running an additional full local backup on all servers
and data in your disaster preparation plan. Run them as far in advance as possible and make sure that
they’re backed up to a location that will not be impacted by the disaster. It is also prudent to place that
backup on an external hard drive that you can take with you offsite, just as an additional measure should
anything happen.

-Detailed asset inventory.

In your disaster preparation plan, you should have a detailed inventory of workstations, their
components, servers, printers, scanners, phones, tablets and other technologies that you and your
employees use on a daily basis. This will give you a quick reference for insurance claims after a major
disaster by providing your adjuster with a simple list (with photos) of any inventory you have.

-Pictures of the office and equipment (before and after prep).

In addition to the photos that you should have of individual inventory items, you’ll want to take photos
of the office and your equipment to prove that those items were actively in use by your employees and
that you took the necessary diligence to move your equipment out of harms way to prepare for the
storm.

-Vendor communication and service restoration plan.

After a storm passes, you’ll want to begin running as quickly as possible. Make sure that you include
vendor communication as part of your plan. Check with your local power provided to assess the
likelihood for power surges or outages while damage is repaired in the area. You’ll also want to include
checking with your phone and internet providers on restoration and access.

These considerations are a great foundation for a complete disaster recovery plan, but make sure that
you are paying attention to the details within each section of your plan. The logistics of testing backups
and performing as many backups as possible before the storm are also important in addition to the
grainy details of how you’ll communicate with vendors, account for your assets and ensure that you’re
back up and running as quickly as possible. If you’re a little overwhelmed in considering these details you
can engage an external resource to help you put a disaster plan in place so that you’re prepared for any
storms that might come our way for hurricane season.

3. Steps to Building a Disaster Recovery Plan

1. Conduct an asset inventory

A plan to recover from a disaster should always start with an inventory of all your IT assets. This is
necessary to untangle the complexity of your environment. Start by listing all the assets under IT
management, including all servers, storage devices, applications, data, network switches, access points,
and network appliances. Then map where each asset is physically located, which network it is on, and
identify any dependencies. Here is an example:

Figure 6,conduct an asset inventory

2. Perform a risk assessment

Once you have mapped out all your IT assets, networks, and their dependencies, go through each and list
the internal and external threats to each of those assets. Imagine the worst case scenario — and be
thorough. These threats could include natural disasters or mundane IT failures.

Next, include the probability that that event may happen and the impact it would likely have if that event
were to occur. How will it affect business continuity if each scenario were to occur? This is also a good
time to enlist the help of your colleagues. Just remember to emphasize the fact that mundane events
happen much more frequently than natural disasters. Move the conversation away from earthquakes
and hurricanes and more toward the higher probability that the location will experience a power outage
or IT hardware failure. Here is an example:
Figure 7,Perform a risk assessment

3. Define criticality of applications and data

Before you begin to build out your IT disaster recovery plan, you’ll need to classify your data and
applications according to their criticality. Start by speaking to your colleagues and support staff to
determine the criticality of each application and data set.

Look for commonalities and group them according to the criticality to your business continuity,
frequency of change, and retention policy. You do not want to apply a different technique to every
individual application or dataset that you have. Grouping your data into classes with similar
characteristics will allow you to implement a less complex strategy to recover.

Classifying data in a vacuum based on assumptions may come back to haunt you. Be sure to involve
other business managers and support staff in this planning exercise. You will undoubtedly have to make
some trade-offs to limit the number of data classes you have. For medium-sized businesses, the number
of classes should likely be between three and five. Here is an example:

Figure 8,Define criticality of applications and data

4. Define recovery objectives

Different classes will have different recovery objectives. For instance, a critical e-commerce database
may be critical to recover and have very aggressive recovery objectives because the business simply can’t
afford to lose any transactions or be down for long. On the other hand, a legacy internal system may
have less stringent recovery objectives and be less important to recover since the data doesn’t change
very often and it’s less critical to get back online.

This is the step where many IT professionals fall short. Setting recovery objectives without consulting the
business line managers is the number one cause for misalignment. It’s imperative that you involve them
in this process to ensure the business can recover properly during a disaster.
Here is a sample list of questions you can ask your business colleagues:
• What applications and data do your department use?
• What is your tolerance for downtime for each?
• What is your tolerance for data loss for each?
• Are there times when these applications are not being used by employees partners or customers?
• Would you ever need to restore data that is older than 90 days old? How about 6 months old? How
about 1 year old?
• Are there any requirements (internal or external [i.e industry or regulatory]) for the organization to
retain the data for a designated period of time?
• Are there any requirements (internal or external [i.e industry or regulatory]) that prevent us from
moving the data from one geographical region to another?
• Are there any requirements (internal or external [i.e industry or regulatory]) with regard to security
and encryption?

The key here is to understand business needs and provide a differentiated level of service availability
based on priority. Now that you have that information hand, it needs to be translated into recovery
objectives to be included in your disaster plan.

Figure 9,Define recovery objectives

Recovery time objective (RTO) — What is the acceptable time any of your data and production systems
can be unavailable? This is your recovery time objective. To calculate the RTO for an application,
consider how much revenue your organization would lose if the application went down for a given length
of time. For example, how much would you lose if your customer portal went down for an hour, or a
day? How much cost would be incurred if none of your employees can work because email is down?

Calculating your RTO is necessary for determining the features you need in your data protection systems
and products. For example, if you have a very high RTO (say, more than four hours), you will probably
have time to back up from tape, but if you have a very low RTO (such as just a few minutes), you need to
use host-based replication or a disk-based backup with continuous data protection features.

Recovery point objective (RPO) — What is the acceptable amount of data your organization can afford to
lose? That is your recovery point objective. If your organization has a high tolerance for data loss, your
recovery point objective (RPO) can be high, from hours to days. If your business can’t afford to lose any
data, or very little, your RPO will be seconds.
The RPO you set will determine the minimum frequency for backing up your data. If you can only afford
to lose an hour’s worth of data, you should back up the data at least every hour. That way, if an outage
begins, for example, at 2:30 p.m., you can recover the 2:00 p.m. backup and meet the RPO requirement.

5. Determine the right tools and techniques

Once you have identified all your IT assets, mapped their dependencies, and grouped them together
based on their criticality and recovery objectives, it’s now time to choose what tools and techniques to
use.

The good news is that a wide array of solutions is on the market today. Just make sure that what you
choose offers the appropriate level of protection. Over-protection can cost the company needless money
and introduce unnecessary complexity. (Complexity is the enemy of productivity and will likely increase
the possibility for human error.) Under-protection can be equally bad since it will put your business
continuity at risk.

For instance, nightly backups using traditional (file-based) methods are more than sufficient for low-
impact data, but would be inappropriate for high-impact data and applications. A CDP solution is great
for high-impact data and systems, but it can add overhead to production servers and storage costs.

Perhaps the most critical component of your backup and disaster recovery plan is offsite protection. This
should be used regardless of the type of data backup method you choose. The method (be it tape
vaulting service or replication to the cloud) should be commensurate to your recovery objectives. Make
sure your data is sent to a location that is far enough away that it is not in the same geographic risk zone.
Typically, this is at least 25 miles away from the primary location.

Finally, automate and streamline the recovery process as much as you can. In the event of a disaster, key
IT staff may be unavailable. Automation also lessens the risk of human error.

6. Get stakeholder buy-in

Go beyond the walls of the data center and involve key stakeholders in all your business units (i.e.
application owners and business managers). They need to be involved in the planning phase. And they
should agree with you about the company’s priorities and service level agreements (SLAs) your team will
provide.

Also, consult your strategic partners and vendors to make sure you’re getting the most out of your DR
solution and/or services. When two servers failed at the Orleans Parish in New Orleans, causing the loss
of critical conveyance and mortgage records dating back to the 1980s, IT staff hadn’t been keeping in
close contact with the parish’s cloud backup / DRaaS provider. Similarly, when web hosting provider
DreamHost had an outage, the company identified the source of the problem to the vendor that
manages its data center. Be sure not to make that mistake and stay in close contact with any vendor you
employ.

Once you have consulted all of the key stakeholders, enlist an executive-level sponsor who will get
behind you and the project. The importance of collaboration, consensus and executive support to your
disaster plan’s success cannot be emphasized enough.

7. Document and communicate your plan

In a disaster scenario, you need a documented strategy for how to get back to a working state. This
document should be written for the people who will use it.

Communicate your plan. All too often, only one person in the organization really knows the whole
picture, leaving the organization vulnerable if that one person is unavailable during a disaster. In
addition, be sure to store your DR strategy where it can be accessed during a disaster — not on public
share in your Exchange folders. Ideally, it should be printed and posted in multiple locations.

8. Test and practice your DR plan

People often say, “Practice makes perfect.” A better saying might be, “Practice makes progress.” No
organization ever gets to perfection with its disaster plan, but practice will help you find and rectify
problems in your plan, as well as enable you to execute it faster and more accurately. Make sure that
everyone who has a role to play attends the practice sessions, even if you hold them, for example, on
Saturdays.

You do not need to practice executing the full disaster recovery plan every time. It’s perfectly acceptable
to carve out pieces of your plan to test. Here is an example:

Figure 10,Test and practice your DR plan

9. Evaluate and update your plan

A DR plan should be a living document. It’s especially important to regularly review your plan given the
shifting sands of an ever-changing business environment. Tolerance for downtime and data loss may
decline. Key personnel may go on leave or terminate their employment. IT might migrate to new
hardware or operating systems. The company might acquire another company. Your planning needs to
reflect the current state of the organization.

4. The policies and procedures that are required for business continuity.

Figure 11,life cycle

This policy provides a standard process for the development, testing and maintenance of initial response,
business continuity and business recovery plans at VCU. This policy incorporates all aspects of the
business continuity plan (BCP) lifecycle as follows:

1. Risk Assessment. During the risk assessment step, each university department will identify, assess and
rank various hazards based on the probability of occurrence and the level of disruption that will be
caused to the department's operation, and consider how each hazard may affect property, business, and
people working in the department and any clients they may serve, as well as the university at large.
Hazards will be reviewed by the Director of Emergency Preparedness who will provided context though
definitions, recent events, and various threat scenarios. This will result in a range of outcomes that may
require significant business impact analysis (BIA) and recovery strategies to be developed and supported
with resources. University departments will conduct an analysis of the risk assessment information to
develop a prioritized list of the mission essential functions (MEFs), with the most critical at the top.

2. Understanding the Organization: Business Impact Analysis (BIA). The BIA refers to the process of
determining, assessing and evaluating the potential effects of an interruption or stoppage of critical
operations, functions and processes of the business due to an accident, emergency, or disaster. It is a
systematic method of predicting the possible and probable consequences of these disruptions, usually
with a worst-case scenario perspective. The BIA is considered to be at the center of disaster recovery
planning, particularly for the minimization of risks in case operational interruptions or disruptions
resulting from disasters and similar incidents.

a. Each department is to determine the MEFs and essential resources of the department. Essential
functions are those services, programs, or activities that are necessary to on-going business and would
directly affect the success of the department if they were to stop for an extended period of time. MEFs
will serve as a guide for how to restart operations following a disaster or major disruption. In general,
there should be four to six essential functions, more if it is a highly complex department or unit.

b. Each department is responsible for the administration of university MEFs and are expected to be as
thorough as possible in outlining requirements and identifying interdependencies for each function.
Consider how the function may need to be altered or modified in the event of a significant disruption
from any of the top hazards described in the risk assessment.

c. Each department is to conduct a BIA for each MEF to assess and document potential impacts and
negative consequences of a disaster or major disruption on the function. A BIA is completed for each
mission essential function to help assess and document potential impacts and negative consequences of
a disaster or major disruption on the function. Completing a BIA also helps establish recovery priorities,
and recovery time objectives (RTOs) by looking at dependencies, peak periods, harmful consequences,
and financial risks.

d. Each department is to consider the human and technology resources required to maintain optimal
level of operations.

e. Each department is to establish and finalize the RTOs, or the length of time needed to recover the
process or function and bring the business operations back to normal, or as close to it as possible.

3. Determining the BCP Recovery Strategies:

Recovery strategies are alternate means to restore business operations to a minimum acceptable level
following a business disruption and are prioritized by the RTO developed during the business impact
analysis. Recovery strategies require resources including people, facilities, equipment, materials and
information technology. An analysis of the resources required to execute recovery strategies must be
conducted by each department to identify gaps. Each department must:

a. Perform an identification of risk, and develop risk treatment strategies across business areas.
Determine internal causes of interdependencies can include line of business dependencies,
telecommunication/IT links, and/or shared resources.

b. Document strategies and procedures to maintain, resume, and recover critical business functions and
processes.
c. Describe the immediate steps to be taken during an event in order to minimize the damage from a
disruption, as well as the action necessary to recover.

4. Develop and Implement the BCP:

VEOCI, a crisis management and software solution will be used to, develop university business continuity
plans, and keep the plans up to date, ensuring the readiness of mission essential functions across the
university. Once the planning (BIA and risk assessment) and meetings are complete, each Business
Continuity Plan (BCP) will be entered into VEOCI by the responsible department designee. Contact the
VCU director of emergency preparedness for access to VEOCI. Training is available. Each department
must:

a. Describe the types of events that would lead up to the formal declaration of a disruption and the
process for invoking the BCP.

b. Determine the format of the BCP, i.e. executive summary, objectives and scope, summary of findings,
recovery activities.

5. Exercising, Maintaining and Reviewing:

Once the BCP is finalized, training and testing will be conducted by the director of emergency
preparedness to ensure all department staff are familiar with it. A continuity planning committee
consisting of personnel who would be involved during, and after a disaster or major disruption will be
formed by the director of emergency preparedness. The BCP will be adjusted by each department as
needed following training and/or actual events.

a. Timely Review and Maintenance: Reviewing all BCPs and related documentation will occur on
an annual basis and is the responsibility of each department plan owner. The purpose of reviewing is to
ensure the plan remains current and up to date, and to maintain a state of readiness. The maintenance
schedule will be overseen by the VCU director of emergency preparedness.

b. Training and Exercises: Annual testing will be coordinated by the director of emergency preparedness
for all departments. Testing methods vary from minimum preparation (no notice drills) and resources to
the most complex (full scale). Each has its own characteristics, objectives, and benefits. The type of
testing employed should be determined by its experience with business continuity planning, size,
complexity, and nature of its business. Examples of testing methods in order of increasing complexity
include tabletop exercises, functional exercises and full scale exercises.

Conclusion
-To summary, this assignment about The security risks faced by the company .How data protection
regulations and ISO risk management standards apply to IT security. The potential impact that an IT
security audit might have on the security of the organization. The responsibilities of employees and
stakeholders in relation to security. Evaluate the proposed tools used within the policy and how they
align with IT security include sections on how to administer and implement these policies

References
1- Ccohs.ca. 2020. Risk Assessment : OSH Answers. [online] Available at:
<https://www.ccohs.ca/oshanswers/hsprograms/risk_assessment.html#:~:text=What%20is%20a%20risk%20assessm
ent,analysis%2C%20and%20risk%20evaluation).> [Accessed 24 August 2020].

2- SearchDataBackup. 2020. What Is Data Protection And Why Is It Important? Definition From Whatis.Com. [online]
Available at: <https://searchdatabackup.techtarget.com/definition/data-protection> [Accessed 24 August 2020].

3- NSW Industrial Relations. 2020. Workplace Policies And Procedures Checklist - NSW Industrial Relations. [online]
Available at: <https://www.industrialrelations.nsw.gov.au/employers/nsw-employer-best-practice/workplace-
policies-and-procedures-checklist/> [Accessed 24 August 2020].

4- Worksmart.org.uk. 2020. What Are The Five Steps To Risk Assessment? | Worksmart: The Career Coach That Works
For Everyone. [online] Available at: <https://worksmart.org.uk/health-advice/health-and-safety/hazards-and-
risks/what-are-five-steps-risk-assessment> [Accessed 24 August 2020].

5- Cityofglasgowcollege.ac.uk. 2020. [online] Available at:

<https://www.cityofglasgowcollege.ac.uk/sites/default/files/hs-risk-assessment-procedure.pdf> [Accessed 24
August 2020].

6- SecurityBox. 2020. Hướng Dẫn Từng Bước Bảo Mật Dữ Liệu Trong Doanh Nghiệp - Securitybox. [online] Available
at: <https://securitybox.vn/1281/huong-dan-tung-buoc-bao-mat-du-lieu-trong-doanh-nghiep/> [Accessed 24
August 2020].
7- Ibm.com. 2020. IBM Knowledge Center. [online] Available at:
<https://www.ibm.com/support/knowledgecenter/ssw_ibm_i_74/rzamv/rzamvdevelopsecpol.htm> [Accessed 24
August 2020].

8- 2020. [online] Available at: <https://www.inap.com/blog/business-

continuity/#:~:text=Business%20continuity%20is%20an%20organization's,that%20take%20critical%20systems%20of
fline.> [Accessed 24 August 2020].

9- Leoisaac.s446.sureserver.com. 2020. Policy Development: Steps In Policy Development. [online] Available at:
<http://leoisaac.s446.sureserver.com/policy/top132.htm> [Accessed 24 August 2020].

10- Entech. 2020. 7 Key Elements Of A Business Disaster Recovery Plan - Entech. [online] Available at:
<https://entechus.com/7-key-elements-of-a-business-disaster-recovery-plan/> [Accessed 24 August 2020].

11- Virginia Commonwealth University. 2020. Commitment To Privacy. [online] Available at:
<https://policy.vcu.edu/universitywide-policies/policies/business-continuity-management.html> [Accessed 24
August 2020].

12- WARD IT SECURITY. 2020. Threat Identification - WARD IT SECURITY. [online] Available at:
<https://warditsecurity.com/threat-
identification/#:~:text=Identifying%20System%20Threats,organization%20to%20take%20preemptive%20actions.>
[Accessed 24 August 2020].

13- Softchoice. 2020. 9 Steps To Building A Disaster Recovery Plan. [online] Available at:
<https://www.softchoice.com/blogs/advisor/uncategorized/9-steps-to-building-a-disaster-recovery-plan>
[Accessed 24 August 2020].

14- Durhamlimited.com. 2020. GDPR - Data Protection Procedure. [online] Available at:
<https://www.durhamlimited.com/legal/gdpr-data-protection-
procedure/2.aspx#:~:text=The%20Data%20Protection%20Laws%20give,data%20and%20sensitive%20personal%20d
ata.> [Accessed 24 August 2020].