How to Make Enterprise Governance Risk and Compliance (eGRC) Work for You Kevin Novak

How to Make Enterprise Governance
Risk and Compliance
(eGRC) Work for You
Kevin Novak
CISO/IT Risk Manager
Northern Trust
h
Agenda
•
•
•
•
•
•
•
•
•
Introduction
GRC Defined, and its Alignment with COBIT 5
Managing GRC with Technology
Establishing the CORE Architecture
Managing Risk with Effective Controls
Constructing the Core
Assessing Risk
M
Managing Risk with Effective Controls
i Ri k i h Eff i C
l
Archer Demo
My background with Governance, Risk, and Compliance
INTRODUCTION
Introduction
Kevin Novak is Chief Information Security Officer, and IT Risk Manager at Northern Trust Kevin is a member of the Northern Trust
Manager at Northern Trust. Kevin is a member of the Northern Trust Corporate Risk Group. He is responsible for the security of Company and Client information and for the management of information technology risks across Northern Trust's global business. Kevin joined Northern Trust in August 2011.
Prior to assuming the role of Chief Information Security Officer at Northern Trust, Kevin spent 5 years at Discover Financial managing their Information Security, Records Management, and Enterprise Risk Management programs, as Chief Operating Officer and Director of Consulting Services at Neohapsis, a Chicago based information security consultancy, and as a senior technology consultant at Ciber Network Services, a global IT consulting services provider.
IT consulting services provider. Prior to joining Ciber Network Services, Kevin was a financial auditor and tax accountant for Best Travel and Tours, and Ameritech Credit Corporation
Introduction
• What pushed me into considering GRC
What pushed me into considering GRC
– Enterprise Drivers to Better Understand Risk
– Demand for Process Efficiencies
Demand for Process Efficiencies
– Audit Fatigue
– Strong Desire to Tear Down Enterprise Silos
St
D i t T D
E t
i Sil
– Confusion Over Authoritative Sources
– The Federal Reserve: “We must see linkage!”
Th F d l R
“W
li k !”
Governance, Risk and Compliance & COBIT 5
GOVERNANCE, RISK, AND COMPLIANCE
,
,
GRC Defined
GRC Defined
• A system of people, processes, and technology that enables an organization to:
– Understand and prioritize stakeholder expectations
– Set business objectives that are congruent with values and risks
– Achieve objectives while optimizing risk profile and protecting value
– Operate within legal, contractual, internal, social, and ethical b
boundaries
d i
– Provide relevant, reliable, and timely information to appropriate stakeholders
– Enable the measurement of the performance and effectiveness Enable the measurement of the performance and effectiveness
of the system
Open Compliance and Ethics Group (OCEG) GRC Capability Model Red Book 2 0 (April 2009)
Open Compliance and Ethics Group (OCEG)‐GRC Capability Model, Red Book 2.0 (April 2009) COBIT 5 and GRC
COBIT 5 and GRC
• COBIT
COBIT 5 brings together the five principles 5 brings together the five principles
that allow the enterprise to build an effective governance and management framework
governance and management framework based on a holistic set of seven enablers that optimizes information and technology
optimizes information and technology investment and use for the benefit of stakeholders.
stakeholders
Source: “COBIT
Source: COBIT 5 and GRC
5 and GRC” PowerPoint Presentation –
PowerPoint Presentation ISACA
COBIT 5 and Governance
COBIT 5 and Governance
• The COBIT 5 process reference model subdivides the IT‐related practices and activities of the enterprise into two main areas: ti
d ti iti
f th
t
i i t t
i
Governance and Management. Management is further divided into domains of processes
• The GOVERNANCE domain contains five processes; within each The GOVERNANCE domain contains five processes; within each
process, the Evaluate, Direct, and Monitor (EDM) practices are defined
1.
2.
3.
4.
5
5.
Ensure governance framework setting and maintenance
Ensure benefits delivery
Ensure risk optimization
Ensure resource optimization
E
Ensure stakeholder transparency
k h ld
• The four MANAGEMENT domains are in line with the responsibility areas of Plan, Build, Run and Monitor (PBRM)
Source: “COBIT
Source: COBIT 5 and GRC
5 and GRC” PowerPoint Presentation –
PowerPoint Presentation ISACA
COBIT 5 and Governance
COBIT 5 and Governance
Source: COBIT® 5, figure 16. © 2012 ISACA® All rights reserved.
COBIT 5 and Risk
COBIT 5 and Risk
• The GOVERNANCE domain contains five governance processes, one of which focuses on stakeholder risk‐related objectives:
– EDM03 Ensure risk optimization
EDM03 Ensure risk optimization
• Process Description
– Ensure that the enterprise’s risk appetite and tolerance are understood, articulated and communicated, and that risk to
understood, articulated and communicated, and that risk to enterprise value related to the use of IT is identified and managed.
• Process Purpose Statement
– EEnsure that IT‐related enterprise risk does not exceed risk th t IT l t d t
i i kd
t
d ik
appetite and risk tolerance, the impact of IT risk to enterprise value is identified and managed, and the potential for compliance failures is minimize
Source: “COBIT
Source: COBIT 5 and GRC
5 and GRC” PowerPoint Presentation –
PowerPoint Presentation ISACA
COBIT 5 and Risk (cont.)
COBIT 5 and Risk (cont.)
• The MANAGEMENT Align, Plan and Organize e
G
g , a a d O ga e
domain contains a risk‐related process: APO12 Manage risk
– Process Description
• Continually identify, assess and reduce IT‐related risk within levels of tolerance set by enterprise executive management
y
p
g
– Process Purpose Statement
• Integrate the management of IT‐related enterprise risk with overall ERM and balance the costs and benefits of managing
overall ERM, and balance the costs and benefits of managing IT‐related enterprise risk
Source: “COBIT
Source: COBIT 5 and GRC
5 and GRC” PowerPoint Presentation –
PowerPoint Presentation ISACA
COBIT 5 and Risk
COBIT 5 and Risk
Source: COBIT® 5, figure 16. © 2012 ISACA® All rights reserved.
COBIT 5 and Compliance
COBIT 5 and Compliance
• The MANAGEMENT Monitor, Evaluate and Assess domain contains a compliance focused process: MEA03 Monitor, evaluate and assess compliance with external requirements
q
– Process Description
• Evaluate that IT processes and IT‐supported business processes are compliant with laws, regulations and contractual requirements. Obtain assurance that the requirements have been i
t Obt i
th t th
i
t h
b
identified and complied with, and integrate IT compliance with overall enterprise compliance.
– Process Purpose Statement
Process Purpose Statement
• Ensure that the enterprise is compliant with all applicable external requirements
Source: “COBIT
Source: COBIT 5 and GRC
5 and GRC” PowerPoint Presentation –
PowerPoint Presentation ISACA
COBIT 5 and Compliance
COBIT 5 and Compliance
S
Source:
COBIT® 5,
5 fifigure 16.
16 © 2012 ISACA® All rights
i ht reserved.
d
COBIT 5 and GRC ‐ Summarized
COBIT 5 and GRC • The COBIT 5 framework includes the necessary guidance to support enterprise GRC objectives and supporting activities:
– Governance activities related to GEIT (5 processes)
( p
)
– Risk management process—and supporting guidance for risk management across the GEIT space
– Compliance
Compliance—aa specific focus on compliance activities specific focus on compliance activities
within the framework and how they fit within the complete enterprise picture
• Inclusion
Inclusion of GRC arrangements within the business of GRC arrangements within the business
framework for GEIT helps enterprises to avoid the main issue with GRC arrangements—silos of activity
Source: “COBIT
Source: COBIT 5 and GRC
5 and GRC” PowerPoint Presentation –
PowerPoint Presentation ISACA
Using technology to help you manage your enterprise GRC
MANAGING GRC WITH TECHNOLOGY
Why use a technology tool for GRC
Why use a technology tool for GRC
• Technology can help you manage your GRC programs:
gy
py
g y
p g
Automate Processes
Aggregate data from multiple sources
Perform quantitative analysis
f
l
Use aggregated data for qualitative analysis
Create Reports and Produce Metrics (KRI/KPI) based on
Create Reports and Produce Metrics (KRI/KPI) based on enterprise, business unit, or cost center
– Measure enterprise alignment with regulatory requirements and industry standards
requirements and industry standards
– Demonstrate clear linkage between enterprise processes, risks and controls
–
–
–
–
–
Setting Expectations
Setting Expectations • An enterprise GRC solution will not:
p
– Help you cut costs – Save you money
– Help you reduce headcount
H l
d
h d
t
• An enterprise GRC solution Will / Can:
– Require dedicated staff
Require dedicated staff
– Help you streamline/automate processes • (don’t expect this to = a reduction in headcount)
–H
Help you bring disparate pieces of risk information l
b i di
i
f i ki f
i
into a single location
– Be difficult to define and implement
Setting Expectations
Setting Expectations • When it comes to managing enterprise risk, one tool will not fit all
• No matter what any solution provider tells you, a one week class and becoming a certified GRC Solution Administrator will NOT give you the skills to go it alone, unless you…
–
–
–
–
–
–
can dedicate resources full time
know exactly what you want
aren’t being held to a strict timeline
are ok with a long learning curve
don’t mind a lot of mistakes up front
p
are willing to pay for external support
• Every phase of this project is going to take dedicated time. Do NOT underestimate, or undersell this fact
,
Getting Started
Getting Started
• Think
Think BIG and start and start small
• Understand what you REALLY want before you choose a technology solution
• Learn what you don’t already know
L
h
d ’ l d k
• Find out who your REAL stakeholders are and gain their support and cooperation, not just their acknowledgement
• Develop a strategic working group/committee
• Define top level roles and responsibilities
• Compile a list of top requirements
Compile a list of top requirements
• Find the top vendors that meet your requirements and bring them in‐house
Build with the end in mind
Build with the end in mind
• When
When considering an eGRC solution, you have considering an eGRC solution you have
to think BIG PICTURE. You'll want to start small of course but you need to think BIG This is
of course, but you need to think BIG. This is not generally the type of system you'll be replacing any time soon and you want to put
replacing any time soon, and you want to put considerable time into defining your long term goals. goals
Understand what you really want
Understand what you really want
• Before you can choose a product, you must answer a number key questions:
– Who is asking for the solution, and what is their goal?
– What is the company’s long‐term vision?
• Is it for reporting enterprise risk or for process automation?
• Will you manage all enterprise risk (CP/VM/OR/Liq./Cr.), or do you have a set of specific needs (e.g., SOX/RCSA/VM)?
– Do
Do you want the solution to adapt to your processes, or can you you want the solution to adapt to your processes or can you
adapt your processes to suit the tool?
– Are you under any time frame limitations?
– Who will coordinate/manage overall direction, and who will Who will coordinate/manage overall direction and who will
manage/develop the system?
– How much are you willing to spend…capital vs. expense?
– Does your company already have a GRC in
Does your company already have a GRC in‐house?
house?
Learn what you don’tt already know
Learn what you don
already know
• If the concept of governance, risk, and compliance are new/foreign to you, or you have never developed/managed /
/
an eGRC solution, do your homework…learn what you don’t know before you start
–
–
–
–
–
–
–
Visit peers/associates that already use a solution
/
Read books on governance, risk, and compliance
Read regulatory guidelines such as BASEL II/III
Read Industry guidelines such as COBIT, ISO:27005, and RMM
Read Vendor/Expert Whitepapers
Bring in vendors to provide demonstrations
Talk to your Risk Counterparts internally
Who Are Your Stakeholders?
Who Are Your Stakeholders?
• If
If you
you’ve
ve asked the right questions, you should asked the right questions, you should
have an idea of what your enterprise wishes to manage with the proposed eGRC solution. If you are still unsure, now is the time to figure it out. • Once you know WHAT, you can answer the question of WHO
• Form a strategic GRC committee to establish requirements and set direction My Stakeholders
My Stakeholders
• Since my solution involves many solutions, the following groups are members of the CORE Architecture Workgroup:
–
–
–
–
–
–
–
–
BCP
Vendor Management (e.g., procurement)
Human Resources
Corporate Risk
Audit
Information Technology
Compliance
Legal
g
• Each solution team (e.g., Vendor Management, BCP, InfoSec.) has its own workgroup to define and execute that p
particular solution
Roles and Responsibilities
Roles and Responsibilities
• Who
Who will lead the eGRC charge and essentially will lead the eGRC charge and essentially
coordinate activities of all interested parties?
• Who will define detailed requirements?
Who will define detailed requirements?
– CORE
– Modules/Solutions/Applications
M d l /S l i /A li i
• Who will code/configure the solution?
• Who will administrate users and access?
Roles and Responsibilities (cont.)
Roles and Responsibilities (cont.)
• Personal Experience:
Personal Experience:
Enterprise Risk M
Management
Information
Technology
Stakeholders
(Finance, Internal
Audit, IT Controls, Audit, IT
Controls,
Procurement)
System Owner
A
R
I
Application Owner
AR
S
I
Define Requirements
AR
SC
S
Implement Solutions
AR
S
I
Perform Testing
f
AR
SC
R
Maintain Application
AR
SC
I
Role (RACSI)
Roles and Responsibilities (cont.)
Roles and Responsibilities (cont.)
• Lessons Learned and Current Model:
Lessons Learned and Current Model:
Enterprise Risk M
Management
Information
Technology
Stakeholders
(Finance, Internal
Audit, IT Controls, Audit, IT
Controls,
Procurement)
System Owner
A
R
I
Application Owner
A
R
R
Define CORE
AR
SC
R
Define Point Solutions
AR (for own)
CI (for others)
CI (for others)
SC
AR (for own)
Implement Solutions
SC
AR
SC
AR (for own)
SC
AR (for own)
I
AR
I
Role (RACSI)
Perform Testing
Maintain Application
Roles and Responsibilities (cont.)
Roles and Responsibilities (cont.)
• Using Consultants
Using Consultants‐Things
Things to consider: to consider:
• Consultants don’t necessarily have the answers either • Unless you are using your solution out of the box, you y
gy
,y
will need to be FULLY engaged throughout the process
• You will NOT be able to offload the definition component. You MUST be heavily involved regardless of Y MUST b h il i l d
dl
f
who brings it all together
• Document your requirements and have the consulting Document your requirements and have the consulting
firm sign off on their acknowledgement of those requirements
Roles and Responsibilities (cont.)
Roles and Responsibilities (cont.)
• Using Consultants‐Things to consider: g
g
• Depending on the solution and the consulting firm, you may be limited by what they have a comfort level for
• Do you have the right skills to do it in house? – To define GRC requirements?
– To Code/Configure the solution?
• Do you have enough time to properly manage the definition and execution alone?
d
ti
l
?
• Make them follow your SLDC … unless theirs is better!
• Do NOT let a consultant tell you that detailed requirements (including wireframes and story boards) aren’tt necessary (including wireframes and story boards) aren
necessary
unless you have a lot of patience for rework and failure
Remember, if you can’t see it end‐to‐end, don’t trust it
Define Top Requirements
Define Top Requirements
• Compile a list of your top priorities…for example:
– Must be able to manage the following risk areas/processes: Vendor, IT, InfoSec., Policy , Credit, Counterparty, Audit, and Compliance Risk
– Must be an In‐house (not cloud) solution
– Must be able to perform deep quantitative as well as qualitative analysis Must be able to perform deep quantitative as well as qualitative analysis
– Must be able to create complex decision/approval flows
– Must be highly flexible/configurable so that it can adapted to our processes, not visa‐versa
– Must be supported on our preferred OS, and DB
– Must be Highly Available
– Must support concurrent access by 4000+ users
• Filter your list of available vendor solutions • Bring them in for a full demo
Refine and Select
Refine and Select
•
•
•
•
•
Refine your requirements Refine
your requirements
Go out to bid
Pick 2 to 3 of the absolute best and do POCs
i k2 3 f h b l
b
d d OC
Choose best solution
Hang tight and get ready for a long ride
So You’ve picked a solution…now what?
ESTABLISHING THE CORE ARCHITECTURE It’ss all about the Core
It
all about the Core
•
•
•
•
What is the Core?
What
is the Core?
Why is it important?
What are the consequences of doing it wrong?
h
h
fd i i
?
How can I do it right?
What is the Core?
What is the Core?
• The
The base configuration of your GRC Solution base configuration of your GRC Solution
upon which all of your systematic processes will depend
will depend
• The Core includes the following:
– Organizational Hierarchy
O
i ti
l Hi
h
– Users and Accounts
– Risk and Control Libraries & Taxonomies
k d
l b
Why is the Core Important?
Why is the Core Important?
• All risk applications will leverage the Core
s app cat o s
e e age t e Co e
– Will establish the dissection points by which queries and reports can be run
– Will provide the foundation for quantifying and reporting risk across all risk applications
– Will establish linkage between:
Will establish linkage between:
•
•
•
•
•
Organizational units
Processes
Risks and their respective Controls
Policies and Standards
p
q
Compliance requirements
Rotten to the Core
Rotten to the Core
• What are the consequences of a poorly designed at a e t e co seque ces o a poo y des g ed
Core architecture?
– Inability to correlate risk information from various risk applications
– Inability to realize the efficiencies you expected, and the introduction of new inefficiencies
the introduction of new inefficiencies
– Considerable re‐work and possible downtime when management decides to do it right
– Lack of linkage between organizational units, processes, risks and controls, policies and standards, and compliance requirements
and compliance requirements
How Can I Build the Core Right?
How Can I Build the Core Right?
• Bring the right teams to the table
Bring the right teams to the table
• Where possible, leverage or create sources
– Asset Libraries
A t Lib i
– Risk and Control Taxonomies
– Organizational Hierarchies
• Think BIG Picture…this part doesn’t change
• Go into the weeds and talk about the details
What is your end‐game?
What is your end
game?
• Go
Go to the end and work backwards...What do to the end and work backwards What do
you want to get out of the solution?
– Metrics/Analytics
– Reports
– KRIs/KPIs
• Who will, or could eventually want them?
• How do they need to be dissected?
Organizational Hierarchy
Organizational Hierarchy
• Ideally an enterprise would have one organizational hierarchy but this is rarely the case. • This is one of the most important decisions you can make in defining your GRC
• It will establish your dissection points for risk reporting, and help you route process flows. • It is important to use an existing hierarchy
It is important to use an existing hierarchy
• The first step is figuring out how many you have, and deciding which to use. Some common areas include:
–
–
–
–
Information Technology
Information
Technology
Human Resources
Internal Audit
Finance
Organization
Chart
Organization Chart
Risk Entity 1
MyBank
Corporate Services
Risk Entity 2
Risk Entity 3
Finance
Risk Entity 4
Operational Risk
Risk Entity 5
Risk Entity 5
Process
InfoSec.
Information Technology
Risk
Model
Model Validation
Architecture
Credit Risk
Analytics
Counterparty
Platform
Windows
Active
Active Directory
Desktop
Patching
Server
Support
Patching
UNIX
Management
Solaris
Linux
A Hierarchy Gone Wrong
A Hierarchy Gone Wrong
Once you decide which hierarchy to follow, you need to decide how you’re going to build it in your G C
GRC. In designing how to incorporate your hierarchy, p y
pay close attention to your goals. If you don’t y
g
y
design it correctly, you might not get the results you expected. Remember, changing it later is NOT an easy task. Common design mistakes include:
• Cutting corners to save a few bucks
• Trying to manage it manually
• Deviating from established corporate standards
• Failing to consider long term goals and possibilities
A Functional Hierarchy
A Functional Hierarchy
Building Hierarchy in GRC Solution
Building Hierarchy in GRC Solution
Wireframe mockups of what the Hierarchy, Risks, and Controls will look like in Archer eGRC
Archer eGRC.
Risks and Controls
Risks and Controls
• Micro
Micro Vs. Macro
Vs Macro(10K) Risks
• Controls & Control Process
• Putting it all together
i i ll
h
Processes
• Patching
• Support
Risks
• Patch not applied in a timely fashion
• Patch causes service disruption
Controls
• Monitor compliance with SLAs
• Pre‐
deployment testing
Actual Risk/Control Hierarchy
Actual Risk/Control Hierarchy
These are not the controls you’re looking for
looking for…
MyBank
Sales
Business Goals: Earn Profits
Risk: Can’t Service client needs manually
System Vulnerable to Attack
ttac
Control:
Utilize Technology
Platform Team
Technology Goals: Service Business Needs with Computer Systems
Computer Systems
Risk:
Control:
Patch Regularly
Platform Team Goals: Patch Systems
Risk: Patch Causes Outage
Technology
Control:
Test patch prior to production deployment
Patching
Bringing it all together
Bringing it all together
Organization
Chart
Organization Chart
MyBank
Risk Entity 1
Risk Entity 2
Corporate Services
Risk Entity 3
Finance
Risk Entity 4
Operational Risk
Risk Entity 5
ik
i
Process
Risk
Control
InfoSec.
f
Information Technology
Risk
Model
Model Validation
Architecture
Credit Risk
Analytics
l
Counterparty
Platform
Windows
Active
Active Directory
Desktop
k
Patching
Patch could cause a system failure
Test patch prior to deployment
d
l
t
Server
Support
Patching
UNIX
Management
Solaris
Linux
A continual approach to control management
MANAGING RISK WITH EFFECTIVE CONTROLS
Calculating Risk
Calculating Risk
Probability/
Severity/
Impact
Inherent Risk
Likelihood
Inherent Risk
Control Effectiveness
Residual Risk
Calculating
Risk
Calculating Risk
Severity or Impact is a factor of all downstream impacts of a risk being realized. As an example: If a p
patch were to shut down a server for 24 hours, the downstream impact might be quantifiable losses f
,
p
g
q
f
such as number of Widgets not manufactured, or average number of trades not realized, or legal and regulatory damages/fines. It can also be non‐quantifiable impacts such as loss of reputation, or loss of fixed wage employee productivity. To understand the full impact of such a failure, it is essential to have full visibility into a given system’s entire data flow.
Severity/
Impact
Probability/
Likelihood
Inherent Risk
The probability or Likelihood of a given event is slightly more difficult to determine. When available, internal
internal statistics are most relevant, but since most companies that continue to operate see very few statistics are most relevant but since most companies that continue to operate see very few
major incidents, table top exercises, and industry/peer statistics are generally going to provide the bulk of your analytic data.
Understand Downstream Impacts
Understand Downstream Impacts
Fact Pattern
DB2 Warehouse pulls all data from DB1
ll d t f
DB1
DB2 Used for nightly
ACH transactions
Nightly ACH averages $40MM
DB1 used for Wires
Federal Reserve
notified: Outage
notified: Outage prevents nightly submission
Client trades cannot be performed without
be performed without wires
Market conditions may contribute to material loss if trades are not submitted
Understand Downstream Impacts
Understand Downstream Impacts
Fact Pattern
Webserver services all online banking transactions
Bank revenue from Internet Operations is 15% IBT
15% IBT
Outage of 8 hours results in 10% transaction loss
Outage of 24 hours results in 40% transaction loss
Federal Reserve
notified if outage is greater than 8 hours
Client Service calls increase by 300% on average during outage
d i
t
Measuring Inherent Risk
Measuring Inherent Risk
• Option 1: Quantitative Method
Option 1: Quantitative Method
– Calculate Value at Risk (VaR) – Sorry, wrong talk /
• Option 2: Qualitative Method
Option 2 Qualitative Method
– Measure based on qualitative assertions resulting from external research and personal expertise
from external research and personal expertise
Inherent Risk: Probability
Inherent Risk: Probability
Probability
Rating Description 1
Rare
2
Unlikely 3
Possible 4
5
Likelihood of Occurrence Highly unlikely, but it may occur in exceptional circumstances. It could happen, but probably never will. Chance of
Chance of Occurrence Frequency of Occurrence < 2% > 50 years Not expected, but there’s a slight possibility it may occur at some time. 3% ‐ 15% 10‐50 years The event might occur at some time as there is a history of The
event might occur at some time as there is a history of
casual occurrence at similar organizations. 15 ‐ 40%
3 years – 10 years Likely There is a strong possibility the event will occur as there is a history of frequent occurrence at this or similar organizations. 40% ‐ 65% 6 months – 3 years Almost Certain Very likely. The event is expected to occur in most circumstances as there is a history of regular occurrence at this and similar organizations. > 65% < 6 months Inherent Risk: Impact
Inherent Risk: Impact
Impact
Rating Description Financial Impact Reputation Impact Regulatory Impact Business Objective Impact Service Impact No additional clients at risk; No
additional clients at risk;
Negligible; Critical services
Negligible; Critical services minimal customer satisfaction unavailable for less than one impact
hour Insignificant Minimal financial Negligible Little or no impact loss; Less than $150k
impact Minor
Minor Adverse local $150k to $1 mil; not media coverage media
coverage
covered by insurance only Disclosure to Monthly targets regulator; MRA
regulator; MRA threatened probable
At least 1 client of > $1 mil in annual revenue classified low at‐risk; minor decrease in customer satisfaction (1‐2%)
Inconvenient; Critical services unavailable for several hours, partner productivity impacted Moderate
Moderate Adverse capital city media $1 mil to $ 5 mil; not coverage
coverage, covered by insurance potential national media coverage
Breach of obligations; Quarterly plan or MRA likely;
MRA likely; strategic objectives
strategic objectives regulatory fine threatened likely
Several clients classified low at‐risk; at least 1 clients of > $1 mil annual revenue classified high at‐risk; measureable decrease in customer satisfaction (2‐4%)
Client dissatisfaction; Critical services unavailable for less services
unavailable for less
than 1 day 4
Major
Major MRIA and or Regulator examination / Annual plan or Adverse and $5 mil to $30 mil; not extended national extended
national investigation investigation
strategic objectives
strategic objectives covered by insurance media coverage likely; legal or threatened regulatory sanction likely
5
Demand for Above $30 mil; not Catastrophic government covered by insurance
covered by insurance inquiry 1
2
3
Regulator takeover threatened Resolved in day‐to‐
day management Client Impact
Long term strategic objectives threatened Large percentage of clients classified low at‐risk; at least 5 Critical services unavailable clients of $1 mil annual for 1 day or a series of
for 1 day or a series of revenue classified high at‐risk; prolonged outages significant decrease in customer satisfaction (5‐10%)
Large percentage of clients classified high at‐risk; major decrease in customer
decrease in customer satisfaction (>10%)
Critical services unavailable for more than a day (at a crucial time) Inherent Risk: Probability * Impact
Inherent Risk: Probability Impact
Impact
5
5
10
15
20
25
4
4
8
12
16
20
3
3
6
9
12
15
2
2
4
6
8
10
1
1
2
3
4
5
1
2
3
4
5
Probability
Red/Amber/Green
Simple Value
> or = 10
4 ‐ 9
< or = 3
Description
High; Risk is outside appetite, management action is required
Medium; Risk is managed though needs to be monitored closely
Low; Risk is well controlled and within appetite
Controls: Effectiveness Ratings
Controls: Effectiveness Ratings
Control Effectiveness Measurement
Effectiveness
Rating
Key
Control %
Secondary Secondary
Control %
Strong
80%
40%
These controls prevent risk under normal and extreme operating conditions and provide a high degree of assurance that errors would be prevented or detected on a timely basis.
Satisfactoryy
70%
30%
These controls prevent and/or lessen the impact of a risk under most normal operating conditions. They provide reasonable assurance that errors would be prevented or detected on a timely basis. yp
p
y
During periods of extreme stress, this control is expected to perform effectively in mitigating the risk.
Fair
60%
20%
These controls lessen the impact of a risk under most normal operating conditions. During periods of elevated stress, this control would not be expected to perform effectively in mitigating the risk.
M i l
Marginal
50%
10%
These controls lessen the impact of a risk under most normal operating conditions. They may have d fi i i
deficiencies or weaknesses in their design or execution. During periods of moderate stress, this k
i th i d i
ti
D i
i d f
d t t
thi
control would not be expected to perform effectively in mitigating the risk.
Unsatisfactory
40%
1%
These controls lessen the impact of a risk under some normal operating conditions. They are likely to have deficiencies or weaknesses in their design or execution. During periods of even some stress, this control would not be expected to perform effectively in mitigating the risk.
Description
Control Owners vs. Control Agents
Control Owners vs. Control Agents
While you might generally only have one control owner asserting to the effectiveness of a given control, numerous individuals from different ,
f
ff
teams may be responsible for implementing that control for their own particular area. Each Control Agent should attest to the effectiveness of his or her own control.
f
Control: Windows Patching
Control Agent:
Windows Platform Manager
Windows Platform Manager
Control: Patching
Control:
UNIX Patchingg
Control Owner: Platform Manager
Control Agent:
UNIX Platform Manager
Can also be considered Controls and Sub‐
Controls, or Generic Controls
Control:
Mainframe Patching
Control Agent:
/
g
OS/390 Platform Manager
Control Owners vs. Control Agents
Control Owners vs. Control Agents
Phase I
Manual Review of Control Agent Assertions by Control Owner
•Control Agent Submits control assertion
•Control
Agent Submits control assertion
•Control Owner uses assertions as working papers to determine overall control effectiveness
Phase II
Phase II
Calculated Roll‐up of Control Agent Assertions
•Control Agents make assertion
•Control Agent assertions calculated into product of all assertions
•Control Owner validates value and approves assertion of overall control effectiveness
Phase III
Control Effectiveness Automatically Calculated
•Automated metrics and control measures contribute to automated assertion of control effectiveness
•Control Agents validate value and approves assertion of individual control effectiveness
•Control
Control Agent assertions calculated into product of all assertions
Agent assertions calculated into product of all assertions
•Control Owner validates value and approves assertion of overall control effectiveness
Calculating
Residual Risk
Calculating Residual Risk
Control Effectiveness Percentage
Inherent Risk
Inherent Risk
Residual Risk
Residual Risk
(CEP)
Impact
Probability
Control Weight
Risk
Controls
Type
Security Vulnerability May Lead to Compromise of Client Confidential Data. Probability=Likely‐4
Impact=Likely‐4
Inherent Risk=High‐16
Patch Systems
Key
Satisfactory
70%
Review Logs
Sec.
Fair
20%
Perform
Vuln. Scans
Sec.
unsatisfactory
1%
Note: Optimum Control Effectiveness is the effective control environment at 100% presumed effectiveness. This would rarely ever
Note:
Optimum Control Effectiveness is the effective control environment at 100% presumed effectiveness This would rarely ever
equal 100% of the total risk since enterprises generally operate at Low‐Moderate risk level to maintain positive profit margins.
Continual
Control Improvement
Continual Control Improvement
Deficiencies Identified
Self Assertion
Self Assertion
Monitoring
& Testing
Audits & Exams
Controls Assessed
Controls Assessed
Effective Control Lifecycle
Deficiencies Remedied or Mitigating Controls Created
Remediation Plan Developed
Confidence in Control Effectiveness
Confidence in Control Effectiveness
High Degree of Confidence
Moderate Degree of Confidence
Low Degree of Confidence
Control Contributor B Response
B Response
Control Contributor A Response
Control Contributor C Response
Self Assertion
Control Contributor B Response
B Response
Positive Confidence Factors are those influences that add to our confidence in a given control’s effectiveness. Certain factors hold greater weight than do other factors.
Examples include: Positive Audit/Exam findings, Positive Self Attestations, Positive Monitoring and Testing Results.
Control Contributor A Response
Self Assertion (RCSA)
Positive Audits/Exams
Control Contributor C Response
Monitor & Test Assertion
Negative Confidence Factors immediately f
undermine the confidence in the effectiveness of a given control. Examples include Adverse Audit/Exam Findings, Incidents, or Adverse Self Assessments.
Positive Monitor/Test
Audited Assertion
Demonstrating
Linkage
Demonstrating Linkage
Process
Risk
Macro Risk
Risk Contributors
COBIT COBIT
5
Policies
Control
Corporate Standards
Authoritative Authoritative Sources
Source
GLBA
ISO 27001
Guidelines
Procedures
A look at an eGRC Live
ARCHER DEMO
Collaborate – Contribute – Connect
• www.isaca.org/knowledge
www.isaca.org/knowledge‐center
center
• The Knowledge Center is a collection of resources and online communities that
resources and online communities that connect ISACA members – globally, across industries and by professional focus ‐ under one umbrella. Add or reply to a discussion, post a document or link, connect with other ISACA
ISACA members, or create a wiki by b
iki b
participating in a community today!