ISACA® CRISC™ study guide mind map

1. CRISC Exam Passing Principles

2. The job profile of the CRISC™ (Certified in Risk and Information Systems Control) published at the beginning of 2010 is the combination of considerable enterprise and IT risk management, in two modules, for implementing and monitoring internal information technology controls has met with significant global interest.

2.1. Covers

2.2. Designation

2.2.1. The CRISC™ certification / designation reflects reflects a solid achievement record in the areas of enterprise / IT risk management as well ad the design, implementation, monitoring and maintenance of controls.

2.3. The first CRISC™ examinations took place in June 2011.

3. Domain 1 - Risk Identification, Assessment and Evaluation

3.1. Domain 1 - CRISC® Exam Relevance

3.1.1. The content area for Domain 1 will represent ...

3.1.1.1. 31% of the CRISC examination

3.1.1.2. 62 questions

3.2. Risk Management Process

3.2.1. What is it?

3.2.1.1. The (constant) process of balancing the risk associated with business activities with an adequate level of control that will enable the business to meet its objectives.

3.4.4. Promote fair and open communication.

3.4.5. Establish tone at the top and assign personal accountability.

3.4.5.1.1. Risk Management must have defined clear roles and responsibilites in order to be effective.

3.4.6. Daily process with continuous improvement.

3.4.6.1. Why

3.4.6.1.1. Risk changes and environment changes (Internal and External), so Risk Management practices must be adapt.

3.4.6.1.2. Risk management should use historical data and facilitates learning and continual improvement.

3.5. Risk Evaluation Process

3.5.1. Process of comparing the estimated risk against given risk criteria to determine the significance of the risk.

3.6. Risk Assessment Process

3.6.1. Process used to identify and evaluate risk and its potential effects.

3.6.2. Elements of Risk Assessment

3.6.2.1. Scope

3.6.2.2. Description of Assessment Area

3.6.2.2.1. Assets

3.6.2.2.2. System

3.6.2.2.3. Region

3.6.2.2.4. Processes

3.6.2.2.5. ...

3.6.2.3. Threats

3.6.2.4. Vulnerabilities

3.6.2.5. Likelihood

3.6.2.6. Impact

3.6.2.7. Risk Assessment Report

3.7. Risk Identification Process

3.7.1. Process of determining the risk that an enterprise / organization faces (globally or in specific organization activity: programme, project).

3.8. The Business Impact of IT Risk

3.8.1. Loss of revenue.

3.8.2. Loss of sensitive information and data.

3.8.3. Loss of reputation / brand visibility / brand image.

3.8.4. Loss of public confidence.

3.8.5. Loss of SLAs / OLAs levels.

3.8.6. LOE to correct problems caused by Threat Actions.

3.8.7. Loss of credibility.

3.8.8. Damage to enterprise’s interest.

3.8.9. System repair costs.

3.9. Applicable Guidelines for Risk Appetite and Risk Tolerance

3.9.1. Connectivity of risk appetite and risk tolerance.

3.9.2. Review and approval of exceptions to risk tolerance standards.

3.9.3. Risk appetite and tolerance change over time.

3.9.4. Cost of risk mitigation options can affect risk tolerance.

3.9.5. Risk Capacity

3.9.5.1. The maximum amount of risk that an organisation or subset of it, can bear, linked to factors such as its reputation, capital, assets and ability to raise additional funds.

3.9.6. Risk Tolerance

3.9.6.1. The threshold levels of risk exposure that, with appropriate approvals, can be exceeded, but which when exceeded will trigger some form of response (e.g. reporting the situation to senior management for action)

3.9.7. Risk Appetite

3.9.7.1. The amount of risk the organisation, or subset of it, is willing to accept

3.10. Risk Hierarchy - 4 Levels of Risk

3.10.1. Portfolio risk

3.10.1.1. goal

3.10.1.1.1. Management of stakeholder perceptions that would affect the reputation of an organization.

3.10.1.1.2. Ensuring business success of the organization.

3.10.1.2. context

3.10.1.2.1. business success

3.10.1.2.2. business vitality

3.10.1.2.3. finance

3.10.1.2.4. core services

3.10.1.2.5. organization / enterprise capabilities

3.10.1.2.6. resources

3.10.1.2.7. portfolio management

3.10.2. Program risk

3.10.2.1. goal

3.10.2.1.1. Delivering business change with measurable benefits.

3.10.2.1.2. Delivering business transformation.

3.10.2.1.3. Delivering outcomes.

3.10.2.2. context

3.10.2.2.1. benefits

3.10.2.2.2. capabilities

3.10.2.2.3. programme management

3.10.3. Project risk

3.10.3.1. goal

3.10.3.1.1. Producing defined business change products within time, cost and scope constraints.

3.20.3. Extended Balanced Scorecard (EBSC)

3.20.3.1.1. A variant of BSC approach, linking BSC dimensions to a limited set of more tangible criteria.

3.20.3.2. Financial

3.20.3.2.1. Share value

3.20.3.2.2. Profit

3.20.3.2.3. Revenue

3.20.3.2.4. Cost of capital

3.20.3.2.5. debt

3.20.3.2.6. ROA

3.20.3.2.7. Cash flow

3.20.3.3. Customer

3.20.3.3.1. Market share

3.20.3.3.2. customer satisfaction

3.20.3.3.3. customer service

3.20.3.3.4. number of contracts

3.20.3.3.5. KYC

3.20.3.3.6. Customer due diligence

3.20.3.3.7. number of claims

3.20.3.4. Internal

3.20.3.4.1. Regulatory compliance

3.20.3.4.2. number of incidents

3.20.3.4.3. centralized data

3.20.3.4.4. process optimization

3.20.3.5. Growth

3.20.3.5.1. Competitive advantage

3.20.3.5.2. Reputation

3.20.4. dr. Westerman 4 A’s

3.20.4.1. What is it?

3.20.4.1.1. Key area of focus presented by Dr Westerman

3.20.4.1.2. aka. The Four As Framework

3.20.4.2. Why

3.20.4.2.1. IT managers can improve alignment and understanding, both in IT and the business, by discussing IT risk considerations in terms of four key enterprise risks: Availability, Access, Accuracy and Agility. The four As can be the basis for effective IT / business alignment conversations, for evaluating risk implications of new investments, and for categorizing operational risks identified through more specialized risk management techniques.

3.20.4.3. Agility

3.20.4.3.1. To be able to change with business with appropriate cost and speed.

3.20.4.4. Accuracy

3.20.4.4.1. To provide correct information on time and complete.

3.20.4.5. Access

3.20.4.5.1. To ensure right people access data and systems when they need.

3.20.4.6. Availability

3.20.4.6.1. To keep systems (and business processes) running and recoverable.

3.20.5. Factor Analysis of Information Risk (FAIR)

3.20.5.1. What is it?

3.20.5.1.1. Taxonomy of the factors that contribute to risk and how they affect each other. It is primarily concerned with establishing accurate probabilities for the frequency and magnitude of loss events.

3.20.5.2. The Open Group has adopted FAIR as a key component in its approach to risk management.

3.20.5.4. By FAIR the risk is the probability of a loss tied to an asset.

3.20.5.5. FAIR defines 6 kind of loss:

3.20.5.5.1. 1. Productivity

3.20.5.5.2. 2. Response

3.20.5.5.3. 3. Replacement

3.20.5.5.4. 4. Fines and judgements (F/J)

3.20.5.5.5. 5. Competitive advantage (CA)

3.20.5.5.6. 6. Reputation

3.20.5.6. FAIR defines Value / Liability as:

3.20.5.6.1. Criticality

3.20.5.6.2. Cost

3.20.5.6.3. Sensitivity

3.20.5.7. FAIR defines Threat as:

3.20.6. COSO® Enterprise Risk Management - Integrated Framework (ERM)

3.20.6.1. What is it?

3.20.6.1.1. Serve as the broadly accepted standard for satisfying those reporting requirements; however, in 2004 COSO® published Enterprise Risk Management - Integrated Framework. COSO® believes this framework expands on internal control, providing a more robust and extensive focus on the broader subject of enterprise risk management.

3.20.6.2. 4 Objectives categories (vertical columns)

3.20.6.2.1. Strategic

3.20.6.2.2. Operations

3.20.6.2.3. Reporting

3.20.6.2.4. Reporting

3.20.6.2.5. It should be recognized that the four columns represent categories of an entity’s objectives, not parts or units of the entity.

3.20.6.3. 8 Components (horizontal rows)

3.20.6.3.1. Internal Environment

3.20.6.3.2. Objective Setting

3.20.6.3.3. Event Identification

3.20.6.3.4. Risk Assessment

3.20.6.3.5. Risk Response

3.20.6.3.6. Control Activities

3.20.6.3.7. Information and Communication

3.20.6.3.8. Monitoring

3.20.6.4. The entity and its organizational units are depicted by the third dimension of the matrix.

3.20.6.5. Each component row “cuts across'' and applies to all four objectives categories.

3.20.6.6. see COSO ERM-IF mind map

4. Domain 2 - Risk Response

4.1. Domain 2 - CRISC™ Exam Relevance

4.1.1. The content area for Domain 2 will represent ...

4.1.1.1. 17% of the CRISC examination

4.1.1.2. 34 questions

4.2. Risk Response Process

4.2.1. What is it?

4.2.1.1. Process of addressing the risks identified during risk assessment.

4.2.1.1.1. Cost benefit analysis.

4.2.1.1.2. Reduce risk to acceptable levels.

4.2.1.1.3. Combination of types of controls.

4.2.1.2. Triggered when a risk exceeds an organizations acceptance level.

4.2.1.3. Driven by input from the risk assessment process.

4.2.2. Why

4.2.2.1. Ensures that the residual risk is within limits of the risk appetite and risk acceptance levels (aka. risk tolerance) of the enterprise.

4.2.2.2. Is based on selecting the correct, prioritized response to risk, based on level of risk, organizations risk tolerance and cost/benefit of risk response options.

4.2.2.2.1. In other words: does asset value still overweight risk response costs including monetary and non-monetary costs.

5. Domain 3 - Risk Monitoring

5.1. Domain 3 - CRISC™ Exam Relevance

5.1.1. The content area for Domain 3 will represent ...

5.2. Risk Monitoring Process

5.2.1. What is it?

5.2.1.1. Process accomplished by selecting KRIs from all the controls and data points available.

5.2.1.2. Periodically re-evaluate risk levels.

5.2.2. Select which controls will be used as Key Risk Indicators (KRIs):

5.2.2.1. Controls that indicate important risk issues or risk trends.

5.2.2.2. Monitored on a regular basis to allow results to be compared over time.

5.2.2.3. Reflect business priorities.

5.3. Risk Indicators

5.3.1. What is it?

5.3.1.1. Metrics used to indicate risk thresholds and when a risk level may be approaching a high or unacceptable level of risk.

5.3.1.2. A metric capable of showing that the enterprise is subject to, or has a high probability of being subject to, a risk that exceeds the defined risk appetite.

5.3.2. Why

5.3.2.1. Set in place tracking and reporting mechanisms that alert staff to a developing or potential risk.

5.3.3. Risk indicators are placed at control points positioned to gather data used to:

5.3.3.1. Gauge risk levels at a point in time.

5.3.3.2. Track events and incidents.

5.3.3.3. That may indicate a potential hazardous situation.

5.4. Key Performance Indicators (KPIs)

5.4.1. Requirements that a KPI must satisfy:

5.4.1.1. Contribution to CSFs

5.4.1.1.1. The connection between the KPI and the CSF above must be demonstrable and described.

5.4.1.2. Stakeholders

5.4.1.2.1. The stakeholders of the KPI must be identified and have accepted their role. Stakeholders are all parties involved in the creation of the KPI and/or with an interest in the presence of the KPI.

5.4.1.3. Relevance

5.4.1.3.1. The KPI, together with other KPIs, must cover as much of the information needs as possible, which is explicitly coordinated with the stakeholders.

5.4.1.4. Ownership

5.4.1.4.1. Ownership of the KPI must be established. The owner is to have a mandate, in the event that the standard value is not obtained, to take measures to adjust the process, so that the value of the KPI is improved.

5.4.1.5. Recognizable

5.4.1.5.1. KPIs are recognizable for employees.

5.4.1.6. Repeatable

5.4.1.6.1. The KPI must be able to be established regularly and in the same way.

5.4.1.7. Traceable

5.4.1.7.1. The way in which the result of the KPI was achieved must be described.

5.4.1.8. Uniformity of processes

5.4.1.8.1. The KPIs must result from processes that are interpreted and implemented in a uniform way by all stakeholders.

5.4.1.9. Standard

5.4.1.9.1. In particular, if KPIs are used for a benchmark, they must correspond to existing standards and be described using standard definitions.

5.4.1.10. Costs vs benefits

5.4.1.10.1. A healthy ratio between costs and benefits of the development of KPIs and especially of the measurements. The costs involved in defining the KPI must be justified by the benefits of the insight obtained.

5.4.1.11. SMART

5.4.1.11.1. The KPI must be Specific, Measurable, Acceptable (for all stakeholders), Realistic, and Time-dependent.

5.4.1.12. The I in KPI stands for indicator

5.4.1.12.1. The goal of KPI is to provide insight into what can be improved and is not intended as a way of settling scores

5.5. Key Risk Indicators (KRIs)

5.5.1. KRIs are like signals / triggers:

5.5.1.1. Indicate warning thresholds.

5.5.1.2. Allow tracking and reporting.

5.5.1.3. Highlight trends in developing or potential risk.

5.5.2. KRIs are like Early Warning Indicator (EWIs). The difference is that KRIs are dedicated to risks.

6.5. Control Types and Effects

6.5.1. Compensating control

6.5.1.1. An internal control that reduces the risk of an existing or potential control weakness resulting in errors and omissions.

6.5.2. Impact (Business impact)

6.5.2.1. The net effect, positive or negative, on the achievement of business objectives.

6.5.3. Preventive control

6.5.3.1. An internal control that is used to avoid undesirable events, errors and other occurrences that an enterprise has determined could have a negative material effect on a process or end product.

6.5.4. Threat

6.5.4.1. Anything nything (e..g.., , object,, substance substance,, human) that is ca that is capable of actin of acting against an asset in a manner that can result in harm an asset in a manner that can result in harm

6.5.5. Vulnerability

6.5.5.1. A weakness in the design, implementation, operation or internal control of a process that could expose the system to adverse threats from threat events.

6.6. Control Strength

6.6.1. Cannot be determined by simple control category identification.

6.6.2. Can be assessed by its quantitative and qualitative compliance testing results.

6.6.3. Must be assessed within context.

6.6.4. Can be effectively assessed only by measuring against control objective.

6.6.5. Meaningful control design considerations include:

6.6.5.1. Design effectiveness.

6.6.5.2. Operating effectiveness.

6.6.5.3. Alignment with operating environment.

6.7. Control Costs and Benefits

6.7.1. Cost-benefit Analysis

6.7.1.1. Provide a monetary impact view of risk.

6.7.1.2. Determine the cost of protecting what is important.

6.7.1.3. Make good choices.

6.8. Total Cost of Ownership (TCO) for controls

6.8.1. Acquisition costs.

6.8.2. Deployment and implementation costs.

6.8.3. Recurring maintenance costs.

6.8.4. Testing and assessment costs.

6.8.5. Compliance monitoring and enforcement.

6.8.6. Inconvenience to users.

6.8.7. Reduced throughput of controlled processes.

6.8.8. Training in new procedures or technologies as applicable.

6.8.9. End of life decommissioning.

6.9. Software Development Life Cycle (SDLC) Process

6.9.1. The SDLC process governs:

6.9.1.1. The phases deployed in the development or acquisition of a software system.

6.9.1.2. Depending on the methodology, may even include the controlled retirement of the system.

6.9.2. Various types / formats of SDLC

6.9.2.1. waterfall

6.9.2.1.1. e.g.

6.9.2.2. iterative

6.9.2.2.1. e.g.

6.9.2.3. iterative & incremental & adaptive (a.k.a. true ’agile’)

6.9.2.3.1. Agile is a umbrella term enclosing different methodologies, tools, techniques, practices and frameworks

6.9.2.3.2. e.g.

6.9.2.4. Plan-Driven Projects vs. Change-driven Project Projects

6.9.3. SDLC phases (generic, not methodology specific)

6.9.3.1. 1. Feasibility study

6.9.3.1.1. Do we need this project / product? Is it aligned with our mission?

6.9.3.2. 2. Requirements study

6.9.3.2.1. What exactly do we need? Can we do it? Budget? Scope? Time?

6.9.3.3. 3. Requirements definition

6.9.3.3.1. Business analysis. Use stories. Use cases. Business process modelling.

8.1.7. Pre-requisite for certification:

9. Basic risk related definitions (from ISACA® CRISC™ perspective)

9.1. Accountability

9.1.1. Applies to those who either own the required resources or those who have the authority to approve the execution and / or accept the outcome of an activity within specific risk management processes.

9.1.2. Ideally only one person should be accountable - from accountability reasons.

9.1.2.1. e.g.

9.1.2.1.1. Project Management is accountable for risk affecting his project.

9.1.2.1.2. Team Leader is accountable for risks affecting his team and work.

9.2. Asset (ISACA®)

9.2.1. Something of either tangible or intangible value that is worth protecting, including people, information, infrastructure, finances and reputation.

9.3. Business Impact Analysis / Assessment (BIA)

9.3.1. Business Impact Analysis (BIS) is a specialized process / exercise (not tool or technique) to determine the impact of losing the support of any resource.

9.4. Business risk

9.4.1. The risk that the system may not meet the users’ expected benefits, services or requirements

9.4.2. e.g.

9.4.2.1. Risk of ”shelfware” - a piece of software that has never been used at all since its creation.

9.4.2.2. Risk of ”bloatware” - type of software that using more system resources than necessary.

9.5. Business case (ISACA®)

9.5.1. Documentation of the rationale for making a business investment, used both to support a business decision on whether to proceed with the investment and as an operational tool to support management of the investment through its full economic life cycle.

9.6. Compensating control

9.6.1. An internal control that reduces the risk of an existing or potential control weakness resulting in errors and omissions.

9.14. Preventive control (ISACA®)

9.14.1. An internal control that is used to avoid undesirable events, errors and other occurrences that an enterprise has determined could have a negative material effect on a process or end product.

9.15. Probability

9.15.1. The probability of it occurring can range anywhere from just above 0 percent to just below 100 percent. Can't be exactly 100 percent, because then it would be a certainty, not a risk. And it can't be exactly 0 percent, or it wouldn't be a risk

9.15.2. Chance, parameters and computation, quantitative.

9.16. Project risk

9.16.1. The risk that the project is under.

9.16.2. e.g. in PRINCE2® each project risk impact is measured against all 6 project parameters

9.16.2.1. Budget

9.16.2.1.1. Project budget

9.16.2.1.2. Project risk budget

9.16.2.1.3. Project change budget

9.16.2.2. Time

9.16.2.2.1. Project time

9.16.2.2.2. Project phase time

9.16.2.2.3. Project work package time

9.16.2.3. Quality

9.16.2.3.1. quality of delivered deliverables / products

9.16.2.3.2. quality and maturity of project management practices

9.16.2.4. Scope

9.16.2.4.1. Risk of ‘fatware’ e.g. 80% of software functionalities never used

9.16.2.5. Risk

9.16.2.5.1. Overall project risk profile in risk tolerance

9.16.2.6. Benefits

9.16.2.6.1. Risk associated with project benefits (during and after the project)

9.17. Reputation risk (ISACA®)

9.17.1. The current and prospective effect on earnings and capital arising from negative public opinion.

9.18. Residual risk

9.18.1. The remaining risk after management has implemented a risk response.

9.19. Responsibility

9.19.1. Belongs to those who must ensure that the activities are completed successfully.

9.19.2. Ideally more than one person should be responsible (additional workforce, human resource backup in case of unavailability of first person).

9.19.2.1. e.g.

9.19.2.1.1. Software Developer

9.19.2.1.2. Server Administrator

9.19.2.1.3. Data Custodian

9.20. Risk

9.20.1. The potential for events and their consequences, contains both (aka. two sides of the risk coin):

9.20.1.1. Opportunities

9.20.1.1.1. for benefit (upside / benefits)

9.20.1.2. Threats

9.20.1.2.1. to success (downside / disbenefits)

9.20.2. Risk is the combination of the likelihood of events occurring and the impact those events have on the enterprise / organization.

9.20.2.1. Risk = likelihood * impact

9.21. Risk appetite

9.21.1. Risk appetite is intangible and cannot be measured directly.

9.21.1.1. Analogy of physical appetite or hunger, which cannot be directly quantified.

9.21.1.1.1. ‘I could eat a horse’

9.21.1.1.2. ‘I fancy a doughnut’

9.21.1.1.3. ‘hungry kike the wolf‘

9.21.2. Appetite is always different across organizations.

9.21.3. The broad-based amount of risk that a company or other entity (CEO, organization / department / sub department) is willing to accept in pursuit of its mission (or vision).

9.21.5. Risk appetite is directly related to an entity’s strategy.

9.21.6. Entities often consider risk appetite qualitatively, with such categories as high, moderate or low, or they may take a quantitative approach, reflecting and balancing goals for growth, return and risk.

9.22. Risk attitude

9.22.1. Is the chosen response of an individual or group to uncertainty that matters, driven by perception. Understanding risk attitude is a critical success factor that promotes effective decision-making in risky situations.

9.23. Risk awareness

9.23.1. Acknowledging that risk is an integral part of the business.

9.24. Risk communication

9.24.1. Risk is to be managed, it must first be discussed and effectively communicated throughout the enterprise.

9.25. Risk culture

9.25.1. ”Culture is a socially constructed attribute of organizations that serves as the social glue binding an organization together.”

9.25.1.1. Cameron & Quinn, 2011

9.25.2. Set of shared attitudes, values and practices that characterize how an entity considers risk in its day-to-day activities.

9.25.3. For many companies, the risk culture flows from the entity’s risk philosophy and risk appetite.

9.25.4. Often one of the most if not the most important enabler!

9.25.4.1. See great talk on RSA 2014 conference about Risk / Security culture.

9.25.4.1.1. https://www.youtube.com/watch?v=bFtGogUiCXI

9.25.5. For those entities that do not explicitly define their risk philosophy, the risk culture may form haphazardly, resulting in significantly different risk cultures within an enterprise or even within a particular business unit, function or department.

9.25.6. Begins at the top (board and executive)

9.25.6.1. Set direction.

9.25.6.2. Communicate risk-aware decision making.

9.25.6.3. Reward effective risk management behaviors.

9.25.7. Risk-Aware Culture is a series of behaviors

9.25.7.1. Behaviors toward taking risk.

9.25.7.2. Behavior toward negative outcomes.

9.25.7.3. Behavior toward policy compliance.

9.25.8. Symptoms of inadequate or problematic risk culture include

9.25.8.1. Misalignment between ‘real’ culture and policies.

9.25.8.2. Misalignment between real risk appetite and translation into policies.

9.25.8.3. Existence of a “blame culture” vs ”learning culture ”.

9.26. Risk impact

9.26.1. Magnitude of harm that could be caused by a threat’s exploitation of a vulnerability.

9.27. Risk indicators (ISACA®)

9.27.1. Metrics used to indicate risk thresholds and when a risk level may be approaching a high or unacceptable level of risk.

9.27.2. A metric capable of showing that the enterprise is subject to, or has a high probability of being subject to, a risk that exceeds the defined risk appetite.

9.28. Risk Management Process

9.28.1. Is the (constant) process of balancing the risk associated with business activities with an adequate level of control that will enable the business to meet its objectives.

9.33.2.10. JIS Q2001:2001 Guidelines for development and implementation of risk management system

9.33.2.10.1. Japan standard

9.33.2.11. ONR 49000 series

9.33.2.11.1. Australian standard

9.33.2.12. PCI DDS

9.33.2.12.1. International norm

9.34. Threat (ISACA®)

9.34.1. Actions or actors that may act in a manner that can result in loss or harm.

9.34.2. Anything nything (e..g.., , object,, substance substance,, human) that is ca that is capable of actin of acting against an asset in a manner that can result in harm an asset in a manner that can result in harm

9.35. Vulnerability (ISACA®)

9.35.1. A (known) weakness in asset, design, implementation, operation or internal control of a process that could expose the system to adverse threats.

11.8. ISACA® CRISC™ Practice Question Database

12. Domains relationships

13. Interactive Glossary

13.1. Interactive CRISC™ Glossary

14. This freeware mind map (aligned with the newest version of CRISC™ exam) was carefully hand crafted with passion and love for learning and constant improvement as well for promotion the CRISC™ qualification and as a learning tool for candidates wanting to gain CRISC™ qualification. (please share, like and give feedback - your feedback and comments are my main motivation for further elaboration. THX!)