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!