Governance, Risk Management and Compliance
Introduction Dr. Yeffry Handoko Putra, M.T
Universitas Komputer Indonesia
Governance, Risk and Compliance (Separately Meaning)
❖
Governance, setting business strategy & objectives, determining risk appetite, establishing culture & values, developing internal policies and monitoring performance.
❖
Risk Management - identifying and assessing risk that may affect the ability to achieve objectives, applying risk management to gain competitive advantage and determine risk response strategies and control activities.
❖
Compliance - operating in accordance with objectives and ensuring adherence with laws and regulations, internal policies &
procedures, and stakeholder commitments.
❖
!2
Governance, Risk and Compliance
GRC provides a framework and a
methodology to enable those responsible for managing the business to give confidence to those who are accountable to shareholders and to regulators that corporate objectives are being met.
❖
Business drivers for an integrated
approach to Governance, Risk and Compliance
!4
Governance Risk and Compliance Increasing
Regulation
Increased
complexity due to
globalisation Increased Competitive
Pressure
Ethical and Financial Scandal
Transparency and accountability
Demand Increased
Demand
from stakeholder
Integrity-driven performance
expectation
New
Technology
Definition of Risk
•
“ Risk is a measure of future uncertainties in achieving
program performance goals and objectives within defined cost, schedule, and performance constraints.”[1]
• “...an uncertain event or condition that, if it occurs, has a positive or negative effect on a project objective.” [2]
[1] Risk Management Guide for DoD Acquisition, Sixth Edition DoD, DAU, August 2006 [2] Project Management Institute PMBOK®, 2008, Fourth Edition
❖
Likelihood of an event occurring. The consequence if such and event occurred
Enterprise Risk and Compliance-Drivers and Trends
Drivers:
• Multiplicity of risk and regulations
• Distributed operations and relationships
• Interdependency of risk
• Increased accountability
• Fragmentation and duplication of effort
❖
!6
Trends:
•
Establishment of risk and compliance architecture
•
Development of risk intelligence
•
Implementation of GRC platforms
•
Centralized communication and training on corporate policies and procedures
•
Continued evolution of the CxO responsible for GRC
•
Risk Sensors
Risk Sensors can provide automated inputs from low level data;
• to demonstrate compliance to legislation and regulation (and non-compliance)
• to demonstrate working controls (and not working controls)
• to highlight risks / threats
• to identify incidents
• to highlight possible data leakage
• identify potential reputation damage
• + many more...
❖
Example of Sensors
,
❖
!8
Sensors to detect events
• System monitors
• Vulnerability assessment, configuration and policy compliance
Network traffic monitors
• Intrusion detection, Intrusion prevention, Firewalls, Routers
Access and identity monitors
• Failed logins, privilege escalation, Bio- metric identities
Web site monitors
• Pages visited, referred from,
End point monitoring
• Data leakage
• Anti-virus, anti-phishing, Malware detection
Others
• Event and Audit log collection – OS,
Infrastructure, applications • CMDB systems
• Incident management
• Backup software, Business continuity management
• IT Security Information (intelligence feeds)
Emerging
• Virtualised environments / ‘Cloud’
computing
Governance, Risk Management, Compliance
Integrating in GRC Dr. Yeffry Handoko Putra, M.T
Universitas Komputer
Indonesia
What is GRC
!10
GRC is a MANAGEMENT MODEL that promotes the criteria unification, as well as communication and collaboration
between different stakeholders in the management and control
of the organisation Governance
Manage the risks to the execution of the company strategy as well as the risks from the chosen strategy
Risk Management
Determine the area exposed to potential risks
Compliance
Is the tactical action to mitigate risks
Governance - Strategy
- Goals and Objective - Policies and Procedure - Structures and process
Risk Management - Identify Risks - Risk Analysis - Risk Profiles
- Risk Monitoring
- Achievement of objectives
Compliance
- Comply with policy and procedures
- Laws and regulations
- Controls
- Activities
GRC Concept
Governance
Risk
Management Compliance
Operations Managed and
supported through GRC
Internal Policy
Risk Appetite
External Regulations Strategy
Process People
Technology
- Strong Ethics - Efficiency
- Improved Effectiveness
Strategic Link
!12
Strategy
Strategy Plan
System, Process
GRC Framework
What Management and monitoring structures
are in place?
Where do we want to go ?
How do we plan to get there?
What is in place to achieve the
plans?
GRC - Governance Concept
Accountability
- Stokeholder
- Government
- Public Accountants
- Investor & Creditors
- Customers
Controls
- Legislation
- CEO Instruction
- SOx, GAAP & COBIT
- Values and Code of Conducts
Performance
- Internal Reporting including SEC reports, annual reports and industries news
- External reporting including boards performance reports, budget analysis, and
internal audit
Strategic Framework
- Corporate & Business plan
- Risk Management Plan
- Business Continuity plan
- IT & Network Framework
- Internal Audit Plans
Executive
Group
GRC - Risk Management Process
!14
1. Identify Risk
- Identify risk factors - Prioritize risk factors
- Profile risk opportunities
2. Assesses risks
3. Exploit &
Develop Risk Strategies
- Quantify risk impacts - Mitigate identified risks - Consider financial factors
- Analyzes opportunities
- Develop risk management plans - Implement strategies
4. Risk Monitoring
- Monitoring changes - Risk factors
- Environment &
organization
- Reevaluate prior steps
GRC - Risk Management Process
(other model from AS/ANZ 4360-1999)
!15
!16
5
Risk Ignorance
(c) OCEG, 2008
6
Risk Intelligence and Integrated GRC
(c) OCEG, 2008
Enables SOA architectures for
interoperability Enhances reporting
transparency by using publicly developed
taxonomies Facilitate data
exchange by using open standards
Risk Intelligent Enterprise TM - Deloite
A GRC approach focuses on maintaining the right balance between risk and reward. An effective risk management program focuses
simultaneously on value protection and value creation. Deloitte refer to an organisations that has attained an advanced state of risk
management capability as a “Risk Intelligent Enterprise
TM”
❖
!18
Risk Intelligent Enterprise TM - Deloitte
Deloitte's Nine Principles
for building a Risk Intelligent Enterprise, 2013
Common Definition of Risk Common Risk Framework
Roles & Responsibilities
Transparency for Governing Bodies
Common Risk Infrastructure
Executive Management Responsibility Objective Assurance and Monitoring
Business Unit Responsibility Support of Pervasive Functions
Scope of Compliance
!20
SCOPE OF
COMPLIANCE AREA FOR CONSIDERATION
STRATEGY
- As an organizations develop strategy, it must determine which regulations are relevant
- Compliance sustainability needs to be an integral part of any compliance strategy
Organizations
- The organization structure must be established to meet the specific requirement (or intent) of each regulation e.g. Sarbanes-Oxley
recommends the Chief Executive Officer and President be two different people.
Process
- Key process must be documented and practiced
- Audit or reviews must take place to ensure documented processes are effectively being used to address compliance /regulation requirements
Scope of Compliance
SCOPE OF
COMPLIANCE AREA FOR CONSIDERATION
Application and Data
- Application must designed, implemented and continuously tested to support the requirement of each regulation
- Data must be properly protected and handled according to each regulation
Facilities
- Facilities must be designed and available to meet the needs of each regulation i.e. some regulations may require records to be readily available at an off-site locations
!22
GRC stakeholders
Source: Deloitte – May 2013
The Value of GRC
GRC promote the criteria unification , the effort coordination and collaboration between different characters involved in the direction of the
organisations through:
•
The integration of the organs / government officials, administration and risk management, internal control compliance
•
Role and responsibility assignation to key personnel
•
Communication channels formalisation
•
Applying a risk-based approach
•
The implementation of compliance program
Is there any Question?
Time break for 5 minutes
Why are organisations seeking a better approach to GRC:
Source: Institute of Chartered Accountant in Australia / KPMG - 2012
•
Uncertainty due to ECONOMIC INSTABILITY
•
Concern about the risk
environment-greater focus on EFFECTIVENESS and
ADEQUACY OF INTERNAL CONTROL
•
Rise in complexity and regulation
•
Business performance
•
Sustainability
•
Stakeholder demands
•
Integrated approach supports
decision making
!26
GRC
Convergence of GRC in evolving:
a. Response to market uncertainty and complexity b. Not about a technology tool
c. Different way of thinking
d. Drive maximum value from complementary activities e. Information to drive performance and achieve
compliance
f. Audit / risk committees play pivotal role:
• Key sponsors
• Alignment to strategy
• Integrated framework supports GRC requirements
GRC
Integrating GRC:
•
Strategic Approach
•
Improved alignment to GRC components
•
Link GRC Components to strategy
•
Risk component critical
•
Common language, methodology and
approach to risk identification and assessment
•
Risk appetit e - helps focus GRC efforts and
concentrate compliance and assurance activities
!28
GRC
Implementing a strategic approach to GRC:
• Consider the big picture first
• Form a cross - functional team / committee
• Define roles and responsibilities early in the process
• Beware of building another silo
• Get the process worked out before investing in the technology
• Seek out overlaps and build efficiencies
• Create a common language and understanding around risk
• Don't lose the detail in the convergence process
• Remember that GRC is a gradual process
Thank you for your
attention
Governance, Risk Management and Compliance
A RISK-BASED APPROACH TO ASSESS INTERNAL
CONTROL OVER FINANCIAL REPORTING (ICFR) Dr. Yeffry Handoko Putra, M.T
Universitas Komputer Indonesia
A RISK-BASED APPROACH TO ASSESSING ICFR
!31
The Security and Exchange Commission (SEC) and the Public Company Accounting
Oversight Board (PCAOB) in the United States have repeatedly stressed that companies should apply a top-down/risk-based approach to assessing Internal Control Over
Financial Reporting (ICFR) for Sarbanes-Oxley (SOX) Section 404
An Institute of Management Accountants (IMA) research project completed in 2006 titled COSO (Committee of Sponsoring Organizations) 1992 Control Framework and Management Reporting on Internal Control: Survey and Analysis of Implementation Practices indicated that SEC registrants, their advisers, and auditors have widely
divergent views on how to actually complete a top-down/risk-based review of ICFR
This disparity of definition and application of “risk-based” was confirmed in
numerous comment letters sent to the SEC and PCAOB in response to their December 2006 exposure drafts relating to management and auditor assessments of ICFR for SOX To provide a solid basis for discussion on this topic, the IMA drafted and exposed for
comment a paper titled “ A Global Perspective on Assessing Internal Control over
Financial Reporting.
Key Step in Risk Based Approach
!32
Statements of
desired end results. They can relate to
customer service, product quality, cost control, revenue maximization, regulatory compliance, fraud prevention,
safety, reliable business information, and others.
Business/Quality Objectives
Threats to Achievement?
Control Portfolio— the controls selected:
(consciously or unconsciously)
These are
possible problems or situations that could result in non achievement of an
Controls are methods,
procedures, equipment, or other things that provide additional assurance objectives will be
achieved.
Residual Risk Status
Information that helps decision makers assess
the acceptability of residual risk. Status data includes indicator data, impact information, impediments, risk transfer/insurance
information, and any concerns.
Acceptable?
Portfolio Optimized?
Risk Transfer/
Insurance
Is the residual risk status acceptable to the work unit? Management? The board? Other key stakeholders?
Yes No
Reexamine control design and/or business/quality
objectives and develop an action
plan.
Yes- Move on No
Is this the lowest- cost set of controls given
our risk tolerance?
Determine Key Stakeholders
Goal of Sarbanes- Oxley Act 2002:
To protect investors by improving the accuracy and reliability of corporate disclosures made pursuant to
securities laws, and for other purposes.
All security regulators around the world that want to ensure the fairness and attractiveness of their capital markets share this goal
Capital market investors, venture capitalists, banks and other lenders, credit rating agencies, employees, pensioners, suppliers, customers, and many others rely to varying degrees on information contained in
external financial disclosure
the senior management team of all organizations should care whether their internal accounting processes are producing reliable information for investors externally and for resource allocations and strategic
decision making internally.
Risk Criteria—Big Picture Corporate Level
!34
1. Implications to the company’s credit rating 2. Implications to the company’s reputation
3. Implications to the company’s cost of capital.
4. Personal implications to senior executives and board 5. Audit firm resignations/refusals
6. Impact on the company’ s share price
7. Personal philosophy of the company’s CEO, CFO, and board
8. Likelihood external auditor opinion on financial
Risk Management Process (AS/ANZ 4360:1999)
AS/NZS 4360:1999 Risk Management
Determine existing controls
Estimate level of risk
Assess risks
Establish the context
Analyse risks
Evaluate risks
Yes No
Treat risks
Communicate and consult Monitor and review
■ The strategic context
■ The organisational context
■ The risk management context
■ Develop criteria
■ Decide the structure
■ Identify treatment options
■ Evaluate treatment options
■ Select treatment options
■ Prepare treatment plans
■ Implement plans
■ Compare against criteria
■ Set risk priorities
Accept risks Determine
likelihood
Determine consequences Identify risks
■ What can happen?
■ How can it happen?
Figure 4.1 Risk management process
Licensed to Ken Madill on 15 Sep 2003. 1 user personal user licence only. Storage, distribution or use on network prohibited.
Risk Rating and Risk Identification
!36
Risk Rating (AS/NZ 4360)
help refine the accounts/ areas in a company that would most benefit from more rigorous and
formal risk and control assessment.
Example :
Risk Identification (AS/NZ 4360):
the process of determining what, where, when, why, and how something could happen.
Technique for identification
• Research and observation, finding common risk from public company from magazine, web (www.auditanalytic.com)
• Company-specific history, learning from fault history and maturity
• Experience of senior level staff
• Industry-specific Scenario Analysis, using all three technique above when currently control can no mitigate.eg. Basel II doing scenario analysis to detect and prevent next big
disclosure disaster that has not happened yet elsewhere
• Risk Source Analysis, using list of potential source risk e.g. Card menu model
!37
Semi-Quantitative Analyze (AS/ANZ 4360:1999)
Risk Analyze and Sensitivity Analyze
Qualitative Analyze (AS/ANZ 4360:1999)
Qualitative analysis uses word form or descriptive scales to describe the magnitude of potential consequences and the likelihood that those consequences will occur. These scales can be adapted or adjusted to suit the circumstances, and different descriptions may be used for different risks.
In semi-quantitative analysis, qualitative scales such as those described above are given values. The number allocated to each description does not have to bear an accurate relationship to the actual magnitude of consequences or likelihood.
Sensitivity Analyze (AS/ANZ 4360:1999)
Since some of the estimates made in quantitative analysis are imprecise, a sensitivity analysis should be carried out to test the effect of changes in assumptions and data.
Quantitative Analyze (AS/ANZ 4360:1999)
Quantitative analysis uses numerical values (rather than the descriptive scales used in qualitative and semi-quantitative analysis) for both consequences and likelihood using data from a variety of sources
!38
TREAT RISKS USING COBIT/ISO 17799/
ITIL
1. Software programs do not correctly calculate/
allocate/handle transactions that impact on the financial statements.
2. Accidental or intentional unauthorized/
inappropriate modifications are made to software programs.
3. There is unauthorized/inappropriate/
fraudulent modification of data in the system that is used to calculate/process accounting entries.
4. Unauthorized/inappropriate/fraudulent
creation and submission of data is made to the accounting system.
5. Spreadsheets used to feed or produce
accounting entries or notes are inaccurate/
unreliable/not secure.
TREAT RISKS USING COSO 1992 CONTROL CRITERIA
1. Develop a universe of ICFR assurance context, auditor-certified financial state- ments are
reliable at the corporate level. It can optionally be done separately for the assurance context of preventing fraud-related financial statement misstatement
2. Develop and apply a system to risk rate each of the subcomponent assurance contexts
identified.
3. Identify and analyze risks that threaten the assurance contexts selected for formal review.
4. Identify and analyze risks that threaten the assurance contexts selected for formal review.
Analyze and Evaluate Risks
Is there any Question?
Time break for 5 minutes
!40
Example using Card Model
❖
RISK
Senior management (Chief Executive Officer [CEO] and/or Chief Financial Officer [CFO]) overrides controls and improperly manipulates/falsifies financial statements
❖
Risk level rating assigned by management: high (i.e., extreme consequence with a moderate likelihood)
!42
MITIGATING CONTROLS
• CEO/CFO hiring practices—Element 4.4: Capability/Continuous Learning: Hir- ing and Selection Procedures
• Audit committee oversight—Element 8.6: Process Oversight: Audit Commit- tee/Board Oversight
• Confidential concerns reporting line—Element 6.7: Indicator/Measurement: Inte- grity Concerns Reporting Mechanisms
• Internal audit reviews—Element 8.2: Process Oversight: Internal Audits External auditor audit of financial statements—Element 8.3: Process Oversight:
• External Audits; Element 6.1: Indicator/Measurement: Results and Status Reports/Reviews
Identify, Assess, And Report On Residual Risk Status
❖
Residual risk is defined in the AS/NZ 4360 Risk Management standard as “the risk remaining after implementation of risk treatment.”
Inherent risk - mitigating control = residual risk
❖
Type of Residual Risk :
Concerns: (also known as issues or review findings) are real or potential situations that have been identified where the current controls in place do not, or might not, mitigate one or more risks in whole or in part.
Indicator Data. This is information about how well a given assurance context is being met.
(Note: This is not whether controls were performed as described but rather the degree to which the controls are actually mitigating risks to the assurance context being assessed.)
Impact Data. This is information that helps decision makers understand the consequences that will or could flow from specific errors in the company’s financial statements.
Impediment Data. In some situations there may be risks that threaten the reliability of
accounting disclosures that are very difficult, expensive, or even impossible to mitigate to a tolerable level because of one or more circumstances
Thank you for your
attention
!45
Risk Treatment Process
(AS/ANZ 4360:1999)
AS/NZS 4360:1999 Risk Management
Evaluated and ranked risk
Accept
Communicate and consult (clause 4.7) Monitor and review (clause 4.6)
Reduce
likelihood Reduce
consequences Transfer in full
or in part Avoid
Reduce
likelihood Reduce
consequences Transfer in full
or in part Avoid Part retained Part transferred Recommend treatment strategies
Select treatment strategy
Prepare treatment plans acceptableRisk Yes
No
Retain acceptableRisk Yes
No
Consider feasibilty costs and benefits Identify
treatment options
Prepare treatment plans
Implement treatment plans Assess treatment options
Figure 4.2 Risk treatment process
Licensed to Ken Madill on 15 Sep 2003. 1 user personal user licence only. Storage, distribution or use on network prohibited.
Risk Treatment
!46
i) audit and compliance programs;
ii) contract conditions;
iii) formal reviews of requirements,
specifications, design, engineering and operations;
iv) inspection and process controls;
v) investment and portfolio management;
vi) project management
vii) preventative maintenance;
viii) quality assurance, management and standards;
ix) research and development, technological development;
x) structured training and other programs;
xi) supervision;
xii) testing;
xiii) organizational arrangements; and xiv)technical controls.
Actions to reduce or control likelihood
i) contingency planning;
ii) contractual arrangements;
iii) contract conditions;
iv) design features;
v) disaster recovery plans;
vi) engineering and structural barriers;
vii)fraud control planning;
viii)minimizing exposure to sources of risk;
ix) portfolio planning;
x) pricing policy and controls;
xi) separation or relocation of an activity and resources;
xii)public relations; and xiii)ex gratia payments.
Procedures to reduce or control
consequences
Example Risk Analyze
!48
Copyright Appendix D: Generic sources of risk and their areas of impact 33
AS/NZS 4360:1999 Risk Management
Table D1 Example of risk identification template
note:
Sources of risk and areas of impact should be adapted to suit the individual organization or activity.Sources of Risk
Area of impact
Select as applicable from Paragraph D3*
* * * * * *
Commercial and legal relationships Economic Human behaviour Natural events Political circumstances Technology/technical issues Management activities and controls Individual activities
Licensed to Ken Madill on 15 Sep 2003. 1 user personal user licence only. Storage, distribution or use on network prohibited.
•
Desease
•
Ecocomic
•
Environmental
•
Financial
•
Human
•
Natural Hazards
•
Occupational Health and safety
•
Product liability
•
Profesional liability
•
Property Damage
•
Public liability
•
Security
•
Technology
Example Qualitative Analysis
!50
Appendix E: Examples of risk definition and classification Copyright
34
AS/NZS 4360:1999 Risk Management
E Examples of risk definition and
classification
Table E1 Qualitative measures of consequence or impact
note: Measures used should reflect the needs and nature of the organization and activity under study.
Table E2 Qualitative measures of likelihood
note: These tables need to be tailored to meet the needs of an individual organization.
Level Descriptor Example detail description
1 Insignificant No injuries, low financial loss
2 Minor First aid treatment, on-site release immediately contained, medium financial loss
3 Moderate Medical treatment required, on-site release contained with outside assistance, high financial loss
4 Major Extensive injuries, loss of production capability, off-site release with no detrimental effects, major financial loss
5 Catastrophic Death, toxic release off-site with detrimental effect, huge financial loss
Level Descriptor Description
A Almost certain Is expected to occur in most circumstances B Likely Will probably occur in most circumstances
C Possible Might occur at some time
D Unlikely Could occur at some time
E Rare May occur only in exceptional circumstances
APPENDIX
(Informative)
Licensed to Ken Madill on 15 Sep 2003. 1 user personal user licence only. Storage, distribution or use on network prohibited.
Appendix E: Examples of risk definition and classification Copyright
34
AS/NZS 4360:1999 Risk Management
E Examples of risk definition and
classification
Table E1 Qualitative measures of consequence or impact
note:
Measures used should reflect the needs and nature of the organization and activity under study.Table E2 Qualitative measures of likelihood
note:
These tables need to be tailored to meet the needs of an individual organization.Level Descriptor Example detail description
1 Insignificant No injuries, low financial loss
2 Minor First aid treatment, on-site release immediately contained, medium financial loss
3 Moderate Medical treatment required, on-site release contained with outside assistance, high financial loss
4 Major Extensive injuries, loss of production capability, off-site release with no detrimental effects, major financial loss
5 Catastrophic Death, toxic release off-site with detrimental effect, huge financial loss
Level Descriptor Description
A Almost certain Is expected to occur in most circumstances B Likely Will probably occur in most circumstances
C Possible Might occur at some time
D Unlikely Could occur at some time
E Rare May occur only in exceptional circumstances
APPENDIX
(Informative)
Licensed to Ken Madill on 15 Sep 2003. 1 user personal user licence only. Storage, distribution or use on network prohibited.
!52
Copyright Appendix E: Examples of risk definition and classification 35
AS/NZS 4360:1999 Risk Management
Table E3 Qualitative risk analysis matrix—level of risk
note:
The number of categories should reflect the needs of the study.Legend
E: extreme risk; immediate action required
H: high risk; senior management attention needed
M: moderate risk; management responsibility must be specified L: low risk; manage by routine procedures
Likelihood
Consequences
Insignificant Minor Moderate Major Catastrophic
1 2 3 4 5
A (almost certain) H H E E E
B (likely) M H H E E
C (moderate) L M H E E
D (unlikely) L L M H E
E (rare) L L M H H
Licensed to Ken Madill on 15 Sep 2003. 1 user personal user licence only. Storage, distribution or use on network prohibited.
Example of quantitative risk
expressions
Appendix F: Examples of quantitative risk expressions Copyright
36
AS/NZS 4360:1999 Risk Management
F Examples of
quantitative risk expressions
F1 Risk of financial loss or gain
The financial loss (or gain) multiplied by the annual frequency of loss (or gain) gives the expected value in dollars per annum.
F2 Fatality risk
The fatality risk from an activity may be calculated as:
F3 Natural or man-made disasters
Consequences can be modeled using computerized simulations and likelihood estimated from historical data, fault trees or other systems engineering techniques.
F4 Health risks
Health risks are commonly expressed in the following different ways:
a) The number of new ill-health cases per annum in an exposed population compared with the total of that population, i.e. five new cases in an exposed population of 100 000 is a risk of 5 x 10-5 per exposed person, per year.
APPENDIX
(Informative)
Number of deaths per annum from activity Exposed population
Licensed to Ken Madill on 15 Sep 2003. 1 user personal user licence only. Storage, distribution or use on network prohibited.
Risk management documentation (Appendix H from AS/ANZ 4360-1999)
❖ Policy :
•The objectives of the policy and rationale for managing risk;
•the links between the policy and the organization’s strategic/corporate plan;
•the extent, or range of issues to which the policy applies;
•guidance on what may be regarded as acceptable risk;
•who is responsible for managing risks;
•the support/expertise available to assist those responsible for managing risks;
• the level of documentation required; and
•the plan for reviewing organizational performance in regard to the policy.
• Compliance and due diligence statement
• Risk Register
• Risk treatment schedule and action plan*
• Monitoring and audit documents
Section H: Risk management documentationCopyright42 AS/NZS 4360:1999Risk Management
Risk register
Date of risk review...
Compiled by ... Date ...
Reviewed by ... Date ...
Ref
The risk:
what can happen and how it can happen
The consequences of an
event happening Adequacy of
existing controls Consequence
rating Likelihood
rating Level
of risk Risk priority Consequences Likelihood
Function/activity...
Licensed to Ken Madill on 15 Sep 2003. 1 user personal user licence only. Storage, distribution or use on network prohibited.
Copyright Section 4.5: Risk treatment 19
AS/NZS 4360:1999 Risk Management
In many cases, it is unlikely that any one risk treatment option will be a complete solution for a particular problem. Often the organization will benefit substantially by a combination of options such as reducing the likelihood of risks, reducing their consequences, and transferring or retaining any residual risks. An example is the effective use of contracts and risk financing supported by a risk reduction program.
Where the cumulative cost of implementing all risk treatments exceeds the available budget, the plan should clearly identify the priority order in which individual risk treatments should be implemented. Priority ordering can be established using various techniques, including risk ranking and cost-benefit analysis. Risk treatments which cannot be implemented within the limit of the available budget must either await the availability of further financial resources or, if for whatever reason any or all of the remaining treatments are considered important, a case must be made to secure additional finances.
Risk treatment options should consider how risk is perceived by affected parties and the most appropriate ways to communicate to those parties.
4.5.3 Preparing treatment plans
Plans should document how the chosen options shall be implemented.
The treatment plan should identify responsibilities, schedules, the expected outcome of treatments, budgeting, performance measures and the review process to be set in place.
note: Refer to Part H5, Appendix H, for details.
The plan should also include a mechanism for assessing the implementation of the options against performance criteria, individual responsibilities and other objectives, and to monitor critical implementation milestones.
Figure 4.3 Cost of risk reduction measures
Cost of reducing risk ($) 0
Implement reduction measures
Use judgement
Uneconomic
Level of risk (Risk value)
Licensed to Ken Madill on 15 Sep 2003. 1 user personal user licence only. Storage, distribution or use on network prohibited.
Cost of risk reduction measures
Thank you for your
attention
Open Compliance
and Ethics Group
!60 8
What is OCEG?
▪ Guidelines and Standards – what should we do?
– Process standards (key concepts, components, and terminology) – Technical standards (key systems and integration points)
– DEVELOPED by experts and PUBLICLY vetted to ensure quality
▪ Evaluation Criteria and Metrics – how are we doing?
– Effectiveness and performance evaluation (suitable criteria) – Reporting and disclosure guidance
– Tools and technologies to appropriately benchmark
▪ Community of Practice – how/what is everyone else doing?
– Discover, create, and evolve guidelines – Use online tools and resources
– Collaborate with peers in a NUMBER of professions
OCEG has o ver 15,000
members in 46 countries representing
66 GRC disciplines
OCEG is the leading nonprofit that helps organizations drive principled
performance™ with a global community of skilled practitioners focused on
improving governance, risk management, and compliance processes.
9
Mission: The Integration of Disciplines
▪ Governance
▪ Risk Management
▪ Compliance/Legal Management
▪ Human Capital Management
▪ Change Management
▪ Ethics Management
▪ Internal Audit
▪ Security
▪ Quality Management
▪ Project Management
▪ Information Technology
▪ Financial and Resource Planning
OCEG brings together disciplines and professions to collaborate and pursue a common mission: to refine and improve the practice of GRC
10
Elements of the OCEG GRC Capability Model
(c) OCEG, 2008
ORGANIZE AND OVERSEE
O1 – Outcomes and Commitment O2 – Roles and Responsibilities O3 – Approach and Accountability
INFORM AND INTEGRATE
I1 – Information Management and Documentation
I2 – Internal and External Communication I3 – Technology and Infrastructure
ASSESS AND ALIGN A1 – Risk Identification A2 – Risk Analysis A3 – Risk Optimization
PREVENT AND PROMOTE P1 – Codes of Conduct
P2 – Policies
P3 – Preventive Process Controls P4 – Awareness and Education P5 – Human Capital Incentives P6 – Human Capital Controls P7 – Stakeholder Relations and
Requirements
P8 – Preventive Technology Controls P9 – Preventive Physical Controls P10 – Risk Financing/Insurance DETECT AND DISCERN
D1 – Hotline and Notification D2 – Inquiry and Survey D3 – Detective Controls MONITOR AND MEASURE
M1 – Context Monitoring
M2 – Performance Monitoring and Evaluation M3 – Systemic Improvement
M4 – Assurance
CONTEXT AND CULTURE C1 – External Business Context C2 – Internal Business Context C3 – Culture
C4 – Values and Objectives
RESPOND AND RESOLVE
R1 – Internal Review and Investigation
R2 – Third-Party Inquiries and Investigations R3 – Crisis Response and Recovery
R4 – Remediation and Discipline
!62
GRC Capability Context and Culture Elements
❖
Using their coding letter C, there are four element to this section of model:
C1 External Business Context C2 Internal Business Context C3 Culture
C4 Values and Objectives
❖
The GRC capability model defines a set of subelements for each of these. For example, for C3, the model contains the following subelements:
❖
C3.1 Analyze Ethical Culture
❖
C3.2 Analyze Ethical Leadership
❖
C3.3 Analyze Risk Culture
❖
C3.4 Analyze Board Involvement
❖
C3.5 Analyze Governance Culture and Management Style
❖
C3.6 Analyze Workforce Engagement
GRC Capability Organize and Oversee Elements
❖
O1 Outcomes and Commitment
‣
O1.1 Define GRC System Scope
‣
O1.2 Define GRC System Styles and Goals
‣
O1.3 Obtain Commitment to the GRC System
❖
O2 Roles and Responsibilities
‣
O2.1 Define and Enable GRC System Oversight Rules and Accountability
‣
O2.2 Define and Enable Management Roles and Responsibilities
‣
O2.3 Define and Enable Leadership Roles and Responsibilities
‣
O2.4 Define and Enable GRC System Operational Rules
‣
O2.5 Define and Enable Assurance Roles and Accountability (e.g., internal audit)
❖
O3 Approach and Accountability
‣
O3.1 to O3.5 define further system processes to build the GRC function and establish management approaches to make this an effective business function.
!64
GRC Capability Organize and Oversee Elements
O2.4.01 Define roles and responsibilities for the following key GRC activities:
Methodology, policy/procedures, standards, vocabulary, and maintenance.
Risk and requirements identification, analysis, and optimization.
Initiative implementation/project portfolio management. & Stakeholder relations.
Helpline/hotline.
Investigation and resolution.
Performance measurement.
Communications, including public relations.
Information management.
Technology.
✦ &
GRC Capability Prevent and Promote Elements
!66
Interestingly, P5 here covers an area that IS NOT
adequately addressed in COSO ERM, HUMAN CAPITAL INCENTIVES, with objectives to:
P5.1 Foster Ethical Leadership
P5.2 Develop Incentive-Based Evaluation and Promotion Decisions
P5.3 Develop Compensation Plans That Consider Conduct Expectations P5.4 Develop Reward Programs
✦ &
OCEG Technology Council Overview
The Technology Council
▪ The OCEG Technology Council was formed to help address strategic, operational and technical issues that professionals face when applying Information Technology (IT) to governance, risk management, compliance (GRC) and ethics management.
▪ Technology Council members meet monthly in specialized working groups focused on GRC technology architecture, standards, and implementation tools. These Work Groups include the GRC Blueprint
TM, GRC Roadmap
TM, and GRC-XML
TMprograms.
▪ The entire council convenes quarterly to review the progress of the individual working
groups, discuss key issues facing GRC professionals, and to identify new GRC technology alignment programs for OCEG.
▪ The OCEG Technology Council engages 37 of the world's leading GRC software, services,
and content providers and user organizations in the development of strategic and technical
resources that help IT and business professionals improve the practice of GRC within their
organizations.
12
OCEG Technology Council Members
!68
The OCEG GRC Integrated Technology Model
Industry Process Applications
GRC Core Applications Business Applications
Technology Infrastructure
Industry-Specific Requirements
GRC Management Requirements
Internal and External Content Specialists
(e.g., law firms, consultants, departmental staff, directors, managers)
Role and Context Applications (e.g., compliance processes and reporting; risk, quality, audit,
legal, and contract management)
Organizational Functionality (e.g., ECM, BPM, BI, LMS, ERP)
IT infrastructure
(e.g., identity management, Databases, Information Security)
Bu si ne ss R eq uire me nts IT D eli ve ry
!69
17
OCEG GRC-XML (XBRL) Program Management Process
▪ OCEG
– Owns the initiative
– Is an official member of XBRL International – Provides “vision” and program governance – Promotes final schema adoption
▪ Technology Council - Jurisdiction
– Encourages Member Contributions and Participation – Drives the production schedule
– Provides the Work Group Members
– Provides technology, technical skills, and methodology
▪ Work Group – Steering Committee
– Executes the development methodology – Develops and reviews all deliverables – Builds schema consensus
– Creates and delivers the Business Object Documents
OCEG
Technology Council
GRC-XML Work Group
!70
Is there any Question?
Time break for 5 minutes
14
Member A Case:
GRC-XML (XBRL) Components (Case Management)
1. Supporting interchange of help line data from content providers for this domain
2. Supporting interchange of current case management data
3. Supporting interchange of education status (i.e. courses taken by employees to mitigate risk)
A. (1) and (2) are ways of communicating the result of an incident
B. (1) and (2) demand a unified solution so that a help line incident shares as much structure with a case management incident as possible
C. For (1) and (2) we are leveraging and extending taxonomy in the following domains:
I. Data Security II. Risk classification
III. Performance-based controls IV. Message Processing
V. Geographical Location VI. User identity
VII. Data Privacy
D. Area (3) is necessary to communicate actions taken to prevent incidents
!72
Member B Case:
GRC-XML (XBRL) Components (Controls)
1. Identification of business control point(s)
A. Process, sub-process, control name, and ID B. Financial account(s) impacted
C. Process owner details (name, address, business unit …)
2. Risk assessment
A. ID, business risk(s) addressed by the control point, other mitigating controls
I. Approval, version, effective date II. Related file attachments
3. Control testing activities
A. Test plans (header-level)
I. ID, objectives, budget, person responsible II. Approval, version, effective date
III. Related file attachments
B. Tests (detail)
I. ID, objectives addressed, test type, selection method, source population details, test procedure II. Approval, version, effective date
III. Related file attachments
!73
16
Member B Case:
GRC-XML (XBRL) Components (Continued)
4. Exceptions (related to one or many detail tests)
A. ID, description, owner, reviewed, resolution (plan) , resolution (actual), status
I. Approval, version, effective date II. Related file attachments
5. Control deficiencies (related to one or many detail tests, related to one or many control points)
A. ID, description, found by test(s), impacts control(s), severity, category
I. Approval, version, effective date II. Related file attachments
6. Control point assessment
A. ID, operating effectiveness (pass/conditional pass/fail), evidenced by control deficiencies, resolution (plan), resolution (actual)
I. Approval, version, effective date II. Related file attachments
B. Operational information which may impact the assessment (for example, whistle-blower reports) – According to Member A’s taxonomy for incidents
C. Vendor applications will manage specific test plans, as XBRL governs common criteria, standardized control language for incidents, defines related control values
!74
