This document outlines a risk assessment methodology for organizations. It discusses how risk assessments are often not implemented formally or do not provide practical advice. The presented method uses foundation documents, risk evaluation criteria, and a multi-round review process called the Delphic Technique to provide a standardized risk assessment. It recommends developing reusable templates, defining assessment scope and objectives, using the methodology to identify and evaluate risks, and creating formal treatment plans. Time is included as a variable to show changing risks over time. The goal is for assessments to identify practical risk reduction options.

1. Layer One conference
Hands on: IT Risk Assessment
George D. Delikouras,
CISM, CGEIT, C-RISK
Athens International Airport S.A.
Head Information security
IT&T Business Unit
george.delikouras@aia.gr
3rd DATA CENTER INFRASTRUCTURES
NETWORKING & CABLING CONFERENCE,
ATExcelixi, October 11, 2013

2. Key Findings from the industry
• Despite risk assessment being specified in
certain regulations and numerous de facto
standards, many organizations have not
implemented formal risk assessment processes
for reasons that include a lack of demonstrated
benefit and a lack of skilled personnel.
• Risk assessments do not address risks at a
sufficiently granular level and seldom deliver
pragmatic, implementable advice to resource
owners.

3. Key Findings from the industry
• Risk and security teams are looking for a
simple risk assessment method that makes
low time demands on IT and business
personnel.
• The method we present, provides a standard
approach to IT risk assessments and resolves
the stumbling blocks to performing formal,
regular risk assessments.

4. Recommendations
• Develop business-focused evaluation criteria and
reusable templates and reference tables for consistency
and standardization.
• Define the scope and objectives of your risk assessments
to focus the risk-assessment process.
• Use Risk Assessment Methodology to identify and
evaluate risks.
• Develop formal treatment plans for treatment tracking
and reporting.

5. Analysis - Definitions
Risk management is the process of identifying risk,
assessing risk and taking steps to reduce risk to an
acceptable level. The risk management process — when
effectively applied — enables organizations to balance
the financial and operational costs of control measures
with the level of risk caused by exposure to threats that
could adversely affect the achievement of business
objectives.

6. Analysis - Definitions
Risk Combination of the probability of an event and its
consequence
Probability Extent to which an event is likely to occur
Risk assessment Overall process of risk analysis and risk evaluation
Risk control Actions implementing risk management decisions
Risk reduction Actions taken to lessen the probability, negative
consequences, or both, associated with a risk
Mitigation Limitation of any negative consequence of a particular
event
Risk transfer Sharing with another party the burden of loss or benefit of
gain, for a risk
Residual risk Risk remaining after risk treatment
Risk acceptance Decision to accept a risk

7. What people think we do

8. What usually happens
An assessment may be performed on IT as a
whole or on specific processes to determine IT's
risk profile or its criticality to the organization.
In reality, risk assessments tend to be
performed in an ad hoc manner, usually at a
high level, to satisfy corporate operational risk
reporting requirements, rather than to derive
practical treatment options to reduce risks.

9. Overcoming Objections
Understanding the objections, real and perceived,
that limit the adoption of risk assessment is the
first step toward implementing risk assessment as
a formal, measurable process that adds value to
the business. Objections are usually based on
negative experiences from past assessments,
which were time-consuming and did not result in
practical actions to address risk.

10. Other objections
• Risk Security personnel have to be taken away from
normal operational activities (often from departments
that are short-staffed) to perform risk assessments.
• Risk and security personnel are concerned about the
potentially repetitive and tedious nature of the process.
• Involvement of business personnel in a process in which
they do not see business benefit.
• The perception that risk assessments are too subjective
to provide anything more than conceptual information.
Always remember: Perception is stronger than reality

11. Justification for Risk Assessments
Risk assessments provide a formal, standardized,
repeatable process for identifying and treating a wide
range of risks, including risks to efficient and effective
operations, and strategic risks, such as reputation damage.
The value of a formal, repeatable method is in consistent
risk measurement and comparative reporting across
business divisions, the use of standard terminology, and
the ability to record risk information for current
management and to obtain historical perspectives.

12. Practical reasons for risk assessment
• Gaining a better understanding of the organization's
IT risk profile
• Addressing IT and information security risks
• Providing management assurance that IT risks are
managed
• Identifying critical IT resources
• Complying with regulations and policies
• Risk, security and business continuity planning
• Prioritizing spending on risk control complying with
regulations and policies

13. Foundation Documents I
Risk Assessment is a methodology that can be applied to
achieve multiple risk assessment objectives and meet
diverse risk reporting requirements.
The method uses a foundation comprising risk evaluation
criteria, threat tables, impact control tables, statements of
materiality, statements of acceptable risk and data
classification to ensure the consistent assessment of risks.

14. Foundation Documents II
An initial set of artifacts is developed, which is refined after
each assessment to create a complete set for streamlining
ongoing assessments.
Certain artifacts, such as risk scenarios, will be defined
during the assessment phase and refined over time.
The artifacts are consolidated in a single repository or risk
catalog. The risk catalog also holds a history of past
assessments and the current risk register to facilitate risk
reporting

15. Foundation process
Process Artifact Description
Build/review
foundation
Risk evaluation
criteria
Define/refine the criteria against which risk will be evaluated,
statements of materiality, definition of acceptable risk, data
classification and definitions of probability.
Threats and impacts Define/refine a list of plausible threats and impacts to the
business.
Risk register The risk register documents risks that have been identified for
treatment in order of priority.
Risk catalogue The risk catalog is a central repository for risk-related
information, including all related artifacts and past risk
treatment activities.
Controls Define/refine a table of existing controls and evaluate control
maturity.
Data classification Define/refine data classes and an associated, required security
baseline.
Resource owners Define/refine resources and resource owners.

16. The Delphic Technique
A team of people having knowledge of the subject being
assessed is appointed to iteratively review scenarios,
incorporating threats, impacts, probabilities and time.
A member of the risk and security team develops the first-
pass scenarios from previously defined threat/impact and
control tables.
The scenarios are sent to individual team members three
times for review and comment, each iteration having an
updated version of the scenarios with consolidated
responses from the preceding round and with a different
focus.

17. Phase 1: Develop scenario
Subprocess/Task Description
Scope and
objectives
■ Define the purpose (for example, risk reporting, risk reduction,
risk and security planning, IT processes and so on).
■ Define the resources in scope (for example, specific
application, platform, data, IT process and so on).
■ Define the deliverable (for example, treatment plan,
prioritization of resources for detailed assessment or risk status
report).
Appoint evaluation
team
■ Appoint a review team of four to six experts, depending on the
assessment type.
■ Appoint an administrator.
Scenario
development
■ Based on the scope and objectives, develop a set of scenarios
for review.

18. Phase 2: Risk evaluation
Subprocess/Task Description
Plausible scenarios are developed and distributed to the evaluation team for
anonymous responses. Team will review threats, impacts, probabilities and controls.
Pass 1: Scenario
evaluation
■ Distribute scenarios with questions to team for review and
response.
■ Consolidate responses from Pass 1.
Pass 2: Risk
modelling
■ Distribute updated scenarios with questions relating to
impacts and probabilities.
■ Consolidate responses from Pass 2.
Pass 3: Controls
review
■ Distribute updated scenarios with questions relating to
controls.
■ Consolidate responses from Pass 3.

19. Phase 3: Prepare response
Subprocess/Task Description
Develop the risk treatment plan.
Address
consensus
failure
■ Resolve consensus issues with resource owner or assessment
sponsor.
Develop a
treatment
plan
■ Define a residual risk statement for acceptance by the
resource owner.
■ If the residual risk is unacceptable, then develop a risk
treatment proposal.
■ On acceptance of the proposal, develop a treatment action
plan.
Develop a final
deliverable
■ For assessments that do not require a treatment plan, produce
the final assessment report in the required format.

20. Phase 4: Plans and documentation
Subprocess/Task Description
Develop the risk treatment plan.
Address
consensus
failure
■ Resolve consensus issues with resource owner or assessment
sponsor.
Develop a
treatment
plan
■ Define a residual risk statement for acceptance by the
resource owner.
■ If the residual risk is unacceptable, then develop a risk
treatment proposal.
■ On acceptance of the proposal, develop a treatment action
plan.
Develop a final
deliverable
■ For assessments that do not require a treatment plan, produce
the final assessment report in the required format.

21. Using Time
… as the Basis for a Continuous Risk Program
Time is included as a variable in the risk scenarios to show
the change in risk over time.
Impacts and the probability of impact change for various
reasons, for example, the value of the resource to the
business could change, causing any loss to have a higher
impact, or the value of the resource to competitors could
increase, causing the probability of loss to rise.
The threat itself may change because of societal, legal or
environmental shifts.

22. Example of annual risk planning

23. Hands-on IT risk assessment
• Examples on risk assessment for IT systems
• Examples on risk assessment for IT projects
• The phases:
– Initiation: Identify the threats
– Phase 1: Assess the impact
– Phase 2: Assess the probability
– Phase 3: Assess the control over threats
– Calculate and present the risks

24. Probability: The subjective factor
• Scale selection is critical for the exercise success!
• A scale from 1 to 5 is the best choice
• The middle of the scale, 3 represents absolute
uncertainty. Probability is 50% (heads or tails)
• The basis of the scale, 1 represents absolute certainty
that the threat will NOT occur
• The top of the scale, 5 represents absolute certainty that
the threat will occur
• Then it is relatively easy to choose between 2 and 4!

25. An IT project example
Risk assessment form (step 1 of 5: Identify the threats)
Project name: Decision support system roll-out
Step 1: Identify the threats Risk ID
Project definition (scope-objectives-deliverables) is not clear or not exists 1
Time plan does not exist or problematic 2
No or poor progress reporting 3
No or poor financial reporting 4
Steering Committee not defined or inactive 5
Budget does not exist or is not secured 6
Contractor is not in position to continue the project because of dispute with 7
Delays due to resource shortage/unavailability from contractor 8
Delays due to resource shortage/unavailability from customer 9
Delays due to technical problems as a result of inefficient design during 10
Delays due to slow decision making process from steering committee or 11
Communication problems between project team members (for contractors in 12
Communication problems due to language differences 13
(all the above are indicative threats, replace with actual)

26. An IT project example
Risk assessment form (step 2: Assess the impact)
Project name: Decision support system roll-out
Step 2: Assess the impact of each threat Impact factor
Expert 1 Expert 2 Expert 3 Expert 4 Expert 5 Expert 6
Project definition (scope-objectives-deliverables) is not clear or not exists 4 4 2 2 3 4
Time plan does not exist or problematic 2 4 3 3 3 3
No or poor progress reporting 2 3 2 2 2 3
No or poor financial reporting 2 3 2 2 2 3
Steering Committee not defined or inactive 3 3 3 3 4 3
Budget does not exist or is not secured 4 4 5 4 4 4
Contractor is not in position to continue the project because of dispute with customer 5 5 4 4 4 5
Delays due to resource shortage/unavailability from contractor
Delays due to resource shortage/unavailability from cuctomer 4 4 3 3 4 3
Delays due to technical problems as a result of inefficient design during development
phase 4 4 4 3 3 4
Delays due to slow decision making process from steering committee or customer 4 4 3 4 4 3

27. An IT project example
Risk assessment form (step 4: Assess the probability)
Project name: Decision support system roll-out
Step 3: Assess the probability for each threat Probability
Expert 1 Expert 2 Expert 3 Expert 4 Expert 5 Expert 6
Project definition (scope-objectives-deliverables) is not clear or not exists 3 3 2 3 2 1
Time plan does not exist or problematic 3 3 1 1 2 2
No or poor progress reporting 2 2 3 1 2 1
No or poor financial reporting 2 2 2 2 2 1
Steering Committee not defined or inactive 2 2 2 2 2 1
Budget does not exist or is not secured 2 2 2 2 2 1
Contractor is not in position to continue the project because of dispute with customer 2 2 1 1 2 1
Delays due to resource shortage/unavailability from contractor
Delays due to resource shortage/unavailability from customer 3 3 3 2 3 2
Delays due to technical problems as a result of inefficient design during development
phase 2 2 1 1 2 2
Delays due to slow decision making process from steering committee or customer 4 4 3 3 3 4
Communication problems between project team members (for contractors in consortia) 2 2 2 1 2 2
Communication problems due to language differences 3 3 2 1 2 2
Delays due to budget limitations from cuctomer part 3 3 2 2 2 2
Delays due to contractual/administrative/legal disputes with cuctomer 3 3 3 5 3 4
Delays due to compliance issues (change management failure, failover procedure not
clear) 2 2 2 2 2 1
Procurement delays for equipment from vendors 1 1 1 1 1 1

28. An IT project example
Risk assessment form (step 3: Assess the control)
Project name: Flight information system roll-out
Step 3: Assess the control over each threat Control
Expert 1 Expert 2 Expert 3 Expert 4 Expert 5 Expert 6
Project definition (scope-objectives-deliverables) is not clear or not exists 3 3 2 3 2 1
Time plan does not exist or problematic 3 3 1 1 2 2
No or poor progress reporting 2 2 3 1 2 1
No or poor financial reporting 2 2 2 2 2 1
Steering Committee not defined or inactive 2 2 2 2 2 1
Budget does not exist or is not secured 2 2 2 2 2 1
Contractor is not in position to continue the project because of dispute with cuctomer 2 2 1 1 2 1
Delays due to resource shortage/unavailability from contractor
Delays due to resource shortage/unavailability from cuctomer 3 3 3 2 3 2
Delays due to technical problems as a result of inefficient design during development phase 2 2 1 1 2 2
Delays due to slow decision making process from steering committee or cuctomer 4 4 3 3 3 4
Communication problems between project team members (for contractors in consortia) 2 2 2 1 2 2
Communication problems due to language differences 3 3 2 1 2 2
Delays due to budget limitations from cuctomer part 3 3 2 2 2 2
Delays due to contractual/administrative/legal disputes with cuctomer 3 3 3 5 3 4
Delays due to compliance issues (change management failure, failover procedure not clear) 2 2 2 2 2 1
Procurement delays for equipment from vendors 1 1 1 1 1 1

29. An IT project example
1,83
2,33
1,501,67
2,67
2,33
3,83
0,00
4,50
2,00
3,50
2,502,33
2,50
5,00
2,17
3,00
2,83
4,00
5,00
4,00
0,00
5,00
4,67
3,33
3,50
4,00
0,000,00
2,33
0,00
5,00
10,00
15,00
20,00
25,00
0,00 1,00 2,00 3,00 4,00 5,00
Risk
Control
Risk assessment
High risk
but good
Low risk
and good
Low risk but
not good
High risk
and no
Column A Column B
Product AXB (Impact) X (Probability) Risk control
13,55 7,39 1,83
14,00 6,00 2,33
6,42 4,28 1,50
7,13 4,28 1,67
15,48 5,81 2,67
17,82 7,64 2,33
25,88 6,75 3,83
0,00 0,00 0,00
42,00 9,33 4,50
12,22 6,11 2,00
44,92 12,83 3,50
11,46 4,58 2,50
11,80 5,06 2,33
14,58 5,83 2,50
78,75 15,75 5,00
11,92 5,50 2,17
10,50 3,50 3,00
33,06 11,67 2,83
40,00 10,00 4,00
30,56 6,11 5,00
10,00 2,50 4,00
0,00 0,00 0,00
28,89 5,78 5,00
45,50 9,75 4,67
29,63 8,89 3,33
44,72 12,78 3,50
56,00 14,00 4,00
0,00 0,00 0,00
0,00 0,00 0,00
19,96 8,56 2,33
29,56 9,33 3,17
24,50 7,00 3,50
10,39 5,19 2,00
19,56 7,33 2,67
All values above 31,25 in the column "Product AXB" indicate risks that need risk management

30. Impact assessment example

31. Impact assessment example

32. Probability assessment example

33. Probability assessment example

34. Risk control assessment example

35. Risk control assessment example

36. Recommendations
• Develop business-focused evaluation criteria and
reusable templates and reference tables for consistency
and standardization.
• Define the scope and objectives of your risk assessments
to focus the risk-assessment process.
• Use Risk Assessment methodology to identify and
evaluate risks.
• Develop formal treatment plans for treatment tracking
and reporting
• Consolidate risk information in a data repository for risk
reporting, ongoing risk management and maintaining a
history of risk management activities.

37. Athens International Airport S.A.
Thank you for your
attention!
George D. Delikouras
CISM, CGEIT, C-RISK
Athens International Airport S.A.
IT&T Business Unit
george.delikouras@aia.gr