Subject : Construction Risk Management
Subject Specialist : Sir Guillermo O. Bernabe
Submitted by : Juana L. Abetria
Deadline of Submission : January 13,2019
Assignment No : 02
1. Explain ISO 31000:2009 Risk Management
To understand ISO 31000:2009, it is imperative to understand that it is
a standard dealing with risk management and that it is not another tool to do
risk analysis or risk assessment. It is also very important to understand the
definition of risk proposed in this standard. However, when truly understood
and implemented, ISO 31000:2009 will connect risk management with decision
making at all levels of an organization. As such, the use of the ISO 31000
process will ensure that the appropriate risk information is used at the required
levels in the organization, over time building a risk oriented organizational
culture.
Risk is the effect of uncertainty on objectives. Therefore, managing risk is about
managing objectives, managing the effects on objectives (which can be
positive, negative or both!) and also managing the uncertainties that go
together with it. (i.e. managing the uncertainty regarding the objectives and
the effects that can affect those objectives)
Therefore, managing risk according ISO 31000:2009 should be about:
Become very clear about your objectives and avoid conflicting objectives
Increase the value of positive effects & Decrease the value of negative
effects on objectives
Make positive effects on objectives more certain and make negative
effects on objectives less certain
The three parts are:
A set of guiding principles, indicating what is helpful when managing risk
in organizations.
A framework, that helps to understand what is necessary when one aims
to implement risk management in an organization. The most important
parts of the framework are: a clear leadership commitment and a (risk
management) plan on how to implement the use of the ISO 31000:2009
process in the entire organization. The framework then needs a follow-up
of that plan and its implementation in a PDCA style process.
A risk management process, that can be used for any kind of risk related
to any kind of issue in order to come to a better understanding of the
issue, its objectives, possible effects and uncertainties and how to deal
with them. Accordingly, the purpose is to take better decisions on how to
deal with these issues. The process is therefore to be seen as a way on
how to get and use the best available information to come to the best
possible decisions, involving all relevant stakeholders and resources in an
appropriate way.
The way these three elements are designed allows for a simple start, but by
continuous improvement of the use of risk management in organizations when
implemented, this will eventually lead to better decisions and more and better
creation and protection of value in the entire organization.
In fact, to understand ISO 31000:2009 it is enough to understand the following
pictures:
Risk assessment = traditional field of risk managers
Establishing the context & Risk treatment = domain of the managers
Communication & Consultation + Monitoring & Review = domain of all
relevant stakeholders
A crucial element missing in the standard is a definition of the concept
“objectives”. When one truly wants to understand ISO 31000:2009, objectives has
to be understood as anything individuals, organizations or societies value or need.
Increasing and protecting that “value” is what risk management according ISO
31000 is about.
As such, all sorts of management systems (project, quality, supply chain, etc.) are
tools to manage the risks of specific objectives, such as safety, quality, specific
project objectives, supply chain objectives, etc.
At the same time, risk management can also be part of these tools in managing
the risks related to the very specific sub-objectives related to these overarching
objectives. As such it is a generic guidance standard that helps to use specific
tools, but it is not a standard of tools dealing with the assessment of specific risks.
Any tool can be used to execute and implement the guidance in this standard.
As a conclusion, the answer is not in understanding the standard alone. It is also
about understanding what the standard conveys and then take action to apply
the knowledge gained with the understanding. Without action, the
understanding is just a nice to have tick in the box.
Sounds easy, but it isn’t. It will require an aligned and sustained effort on all levels
of the organization, starting at the top, with a clear vision on how to implement
this standard and providing the necessary resources to do so. When these two
conditions are not met, it will become a really hard task to achieve the desired
result.
In some way, the plainest way I can express/explain it is constantly asking, “What
if?” in a cost over benefit manner. Given it also equivalences to the quality
movement, dissemination of information, building a culture of compliance and
enterprise-wide realization of benefits is not an outstanding priority for executive
leadership compared to many other important matters so a personal practice
would be good and less resource intensive.
2. Explain ISO/IEC 27005:2008 Information technology - Security techniques -
Information security risk Management
ISO/IEC 27005:2008 provides guidelines for information security risk
management. It supports the general concepts specified in ISO/IEC 27001 and
is designed to assist the satisfactory implementation of information security
based on a risk management approach. Knowledge of the concepts, models,
processes and terminologies described in ISO/IEC 27001 and ISO/IEC 27002 is
important for a complete understanding of ISO/IEC 27005:2008. ISO/IEC
27005:2008 is applicable to all types of organizations (e.g. commercial
enterprises, government agencies, non-profit organizations) which intend to
manage risks that could compromise the organization's information security.
As per research, the standard has been updated, albeit 3 years late and
almost unchanged from the previous edition.
The updated introduction says it is based on the asset, threat and vulnerability
risk identification method, lamely noting that there are some other methods
that can be used. It goes on to state that the standard does not contain direct
guidance on the implementation of the ISMS (Information System
Management Security) requirements given in ISO/IEC 27001. It isn’t really a risk
assessment or management method as such, more of a meta-method, an
approach to choosing methods that are appropriate for your organization.
The standard “supports the general concepts specified in ISO/IEC 27001 and is
designed to assist the satisfactory implementation of information security
based on a risk management approach”, so make of that ambiguity what you
will.
The draft fourth edition’s working title “Guidance on managing information
security risks and opportunities” gives a strong hint that it will directly support
section 6.1 of ISO/IEC 27001:2013 (“Actions to address risks and opportunities”),
mostly concerning the risks in fact: whether ‘opportunities’ and ISO 31000 get
much of a look-in remains to be seen. Regarding ISO/IEC 27001 section 6.1,
merely it is believed that the section is intended to have addressed risks and
opportunities for the management system, not for information or even
information security, a crucial distinction. If that’s true, and if the fourth edition
of 27005 explicitly supports 6.1, then logically it ought to concern the
management of risks and opportunities to the ISMS, not to information.
However, the 6.1 boiler plate wording imposed on all the management
systems standards is ambiguous.
Talking of opportunities, rewriting 27005 presents a golden opportunity for SC
27 to reframe it as a standard on information risk management where
‘information risk’ might be defined along the lines of “risk pertaining to
information”. Among other things, that would remove references to
‘information security risk’, a curiosity of the current standards. What is that,
exactly? It is not explicitly defined as a term. A note to the definition of risk in
ISO/IEC 27000 refers to it as the “effect of uncertainty on information security
objectives”. A note to the definition of objective says, rather enigmatically,
“information security objectives are set by the organization, consistent with the
information security policy, to achieve specific results.” So, stitching those two
together, information security risk is defined as “the effect of uncertainty on
information security objectives set by the organization, consistent with the
information security policy, to achieve specific results”. Frankly I’m none the
wiser, if anything more confused by the tortuous and unhelpful explanation.
A re-framed standard on information risk management could underpin all of
ISO/IEC 27001, not just section 6.1. Given that the entire ISO27k approach is
supposedly risk-aligned, identifying, evaluating and treating information risks is
a fundamental element, hence a standard on information risk management
is fundamental. There are lots of areas where it could offer useful advice e.g.
Explain what ‘information risk’ is, for starters - defining it formally (properly),
clearly, helpfully and without the torture and ambiguity of the current
gibberish, and then explaining it in more accessible and understandable
terms;
Outline the organizational/business context for information risk management -
how it relates to the management of other kinds of risk, and how risk
management supports management and governance of the organization;
3. Explain the description of alternative process models
Broadly speaking, when assessing risk management for any industry, in one of
its organizational processes there are different categories of risk that can be
compiled using a list or a certain factor. These factors and it significant effect
can change depending on the model or the approach to handle such
process you are using. This factors and sometimes entire process can then be
“weighed” differently for risk exposure, by then an alternative process model
shall already be made or considered.
For instances, if a process is determined “at risk”, some measures can be
considered. Example is as follows:
A. Your company is facing a lawsuit. Question that may arise is as follows:
a) Questions Asked:
a. With whom? (It is government or a private a company?
b. What kind? (It is quality matters or fraud, etc.)
c. Is the public aware (How Bad?)
d. Others.
b) Propose alternative solutions: After digging into the organization's
objectives and specific problems, several solutions may have been
discovered. However, alternate proposals may still come from
interviewing employees, clients, suppliers, and/or consultants. Insight
may also be gained by researching what competitors are doing.
c) Cost benefit analysis: Analyze and describe the costs and benefits of
implementing the proposed changes. In the end, the ultimate
decision on whether to leave the system as is, improve it, or develop
a new system will be guided by this and the rest of the preliminary
analysis data.
By then we can come up to answer each question and derived an alternative
solution with cost benefit analysis. The goal in general is to come to an
actual/numeric data to prove/make an argument with your old process to your
alternative process
At some point from the very beginning, we can already have possible solutions or
contingency plan to what will possibly be a problem which is derived through
factual, quantitative and historical data.
General Information in connection for Item No. 4 and 5
The systems development life cycle (SDLC), also referred to as the application
development life-cycle, is a term used in systems engineering, information systems
and software engineering to describe a process for planning, creating, testing,
and deploying an information system. The systems development lifecycle
concept applies to a range of hardware and software configurations, as a system
can be composed of hardware only, software only, or a combination of both.
There are usually six stages in this cycle: analysis, design, development and testing,
implementation, documentation, and evaluation.
The system development life cycle framework also provides a sequence of
activities for system designers and developers to follow. It consists of a set of steps
or phases in which each phase of the SDLC uses the results of the previous one
If a business determines a change is needed during any phase of the SDLC, the
company might have to proceed through all the above life cycle phases again.
The life cycle approach of any project is a time-consuming process. Even though
some steps are more difficult than others, none are to be overlooked. An oversight
could prevent the entire system from functioning as planned.
Source: [Link]
4. Explain the acquirer application to the system acquisition life cycle.
Defining First the key Words:
Acquirer- to come into possession or control of often by unspecified
means; to get as one's own.
An acquirer application is involved all through the SDLC (System
Development Life Cycle) form initiation up to disposal phase.
5. Explain the supplier application to the system development life cycle
Supplier- to supply or to add as supplement; the quantities of goods or
services offered for sale at a particular time or at one price; the act or
process of filling a want or need
A supplier application in that sense is the acquirer partner in delivering the
work. They are the one the get the job done for the client/acquirer
requirement because they are the ones with available resources,
knowledge, expertise and capabilities. In that case per se, they can be
found in all the phases stated below as follows:
Initiation, system concept development, planning-Knowledge and
expertise to pre-planning and planning stage.
Design to disposition-Knowledge and expertise together with their
actual project output.