<Previous Lesson

Information Systems

Next Lesson>


Control Analysis

Organization uses water Fire, negligent persons
sprinklers to suppress fire
and tarpulins to protect
Terminated employees’ Terminated Employees
system ID’s are not
removed from the system
Vulnerability Threat Source

Control Analysis
This phase includes assessment of controls already been implemented or planned, probability that
they can be broken, assessment of potential loss despite such controls existing. Controls are also
classified as non-technical controls also called management controls and technical controls –
software, hardware controls. The output of this step is current or planned controls used for the IT
system to measure the likelihood of vulnerability being exercised and reduce the impact of loss.

37.1 Likelihood Determination
This phase determines that a potential vulnerability could be exercised by a given
threat-source. Following table will help us to define and understand the likelihood
The input to this phase is
Threat source motivation
Threat capacity
Nature of vulnerability
Current Controls
The output to this phase is a likelihood rating to be used further in the risk assessment process.

37.2 Impact Analysis
This phase determines the adverse impact resulting from a successful threat exercise of
vulnerability. Following information is required before conducting an impact analysis.
1. System mission e.g. the process performed by IT system.
2. System and data criticality e.g. the system’s value or importance to an organization
3. System and data sensitivity
The information can be obtained from existing organizational documentation.
The threat source lacks motivation
or capability or controls are in
place to prevent or at least
significantly impede the
vulnerability from being exercised.
The threat source is motivated and
capable but controls are in place
that may impede the successful
exercise of the vulnerability.
The threat source is highly
motivated and sufficiently capable
and controls to prevent the
vulnerability from being exercised
are ineffective
Likelihood level Likelihood Definition
Impact needs to be measured by defining certain levels. E.g. high medium low as qualitative
categories or quantifying the impact by using probability distribution.
Mission Impact Analysis
Assess criticality assessment
Data criticality
Data sensitivity
The output of this phase is impact rating.

37.3 Risk Determination
The purpose of this step is to assess the level of risk to the IT system. The determination of
particular threat can be expressed as a function of
1. The likelihood of a given threat-source’s attempting to exercise a given vulnerability
(system flaw)
2. The magnitude of the impact should a threat source successfully exercise a vulnerability
3. The adequacy of planned or existing security controls for reducing or eliminating risk.
This phase also presumes the definition of risk levels in order to classify the risks. The is more of a
discretionary act on part of the management. Levels can be defined as high medium low and
allocating various probability ranges. Risk levels are made to compare them with the ranges of
Once the risk of loss has been determined using probability of occurrence and level of impact,
such risk amounts may then be classified at the discretion of management.
1. Risk scale Low if loss is less than Rs. 1,000
2. Risk scale medium if loss is less than > Rs. 1,000 but < Rs. 5,000
3. Risk scale high if loss is less than > Rs. 5,000

The inputs of to this phase are
1. Likelihood of threat exploitation
2. Magnitude of impact
3. Adequacy of planned and current controls
High – 6,000 30,000 60,000
Medium – 3,000 15,000 30,000
10,000 5,000 10,000
x10% =
Low –
High Rs.
Low Rs.
Level of Impact
The output is the determination of risk and associated risk levels.

Control Recommendations
In this phase, controls that could mitigate or eliminate the identified risks appropriate to the
organization’s operations. The control recommendations are the results of the risk assessment
process. The control recommendations is actually the risk mitigation process.

37.4 Results Documentation
In this phase, results should be documented in a report or briefing.

Example-Risk Management
The IS security manager carries out a risk assessment. The company employs 18 computer
terminals in a two-storey building, containing typical office furniture and equipment. The focus of
the security manager is to see how the computer assets can be protected against possible threats.
The approach followed by the manager may include searching the web pages, organizational leaflet
and more general publications, to learn where hazards can occur. He may walk around the office
observing what might pose a risk. He may choose to talk to supervisors and staff to learn from
their more detailed knowledge of areas and activities, and to get concerns and opinions about ITrelated
After the initial information seeking phase, the manager then wrote down how computer
equipment could be harmed by the hazards and how. For each hazard, the manager recorded what
controls, if any, were in place to manage these hazards. She then compared these controls to the
good practice guidance commonly available on web or followed by other organizations. Putting the
risk assessment into practice, the manager decided and recorded who was responsible for
implementing the further actions and when they should be done. When each action was completed
it was ticked off and the date recorded.
At an office meeting, the security manager will discuss the findings with the staff and gave out
copies of the risk assessment. The manager decided to review and update the assessment at least
annually, or straightaway when major changes in the workplace occurred. This example of risk
assessment is intended to show the kind of approach we expect a small business to take. Every
business is different and there is a need to think through the hazards and controls required in that
particular business.

37.5 Implementation
Once the controls for managing risk have been devised, reported and accepted, the next phase is to
prepare for implementation. Making controls part of the information systems is a challenging task
as it requires the display of a sense of ownership and priority to the task in hand by the
management who act as the drivers for the implementers and the users.

37.6 Monitoring and evaluation
Once the controls have been implemented, their effectiveness needs to be monitored. An
evaluation should also be made on regular basis to see no. of threats neutralized, threats not
properly dealt with and the threats identified but not taken action against. Analyses like these can
be conducted so as to determine, whether the cycle needs to be repeated.

<Previous Lesson

Information Systems

Next Lesson>


Lesson Plan


Go to Top

Next Lesson
Previous Lesson
Lesson Plan
Go to Top