Online Mind Mapping and Brainstorming

Create your own awesome maps

Online Mind Mapping and Brainstorming

Even on the go

with our free apps for iPhone, iPad and Android

Get Started

Already have an account? Log In

ISACA® CRISC™ study guide mind map by Mind Map: ISACA® CRISC™ study guide
mind map
5.0 stars - 62 reviews range from 0 to 5

ISACA® CRISC™ study guide mind map

ISACA® is a registered trademark of Information Systems Audit and Control Association. CISA®, Certified Information Systems Auditor®, CISM®, CGEIT®, Certified in the Governance of Enterprise IT/CGEIT® (and design)®, COBIT® are registered trademarks of ISACA®. CRISC™, Certified in Risk and Information Systems Control™, Certified Information Security Manager™, Risk IT™, Val IT™ are trademarks of ISACA®. Trademarks are properties of the holders, who are not affiliated with mind map author.

CRISC Exam Passing Principles

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.


It covers 5 domains, 39 tasks and 72 knowledge statements (statements covering the required technical knowledge).


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.

The first CRISC™ examinations took place in June 2011.

Domain 1 - Risk Identification, Assessment and Evaluation

Domain 1 - CRISC® Exam Relevance

The content area for Domain 1 will represent ..., 31% of the CRISC examination, 62 questions

Risk Management Process

What is it?, 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., Holistically covers all concepts and processes affiliated with managing risk, including:, Systematic application of management policies, procedures and practices, Establishing the context, External, Internal, Communicating, consulting, Identifying, Analysing, Evaluating, Treating, Controlling, Monitoring, Reviewing

High Level Process Phases (Risk IT), 1. Collect Data, 2. Analyze Risk, 3. Maintain Risk Profile

Risk Governance

Strategic business function that helps ensure that:, Risk Management activities align with the enterprise’s loss capacity and leadership’s subjective., Risk Management strategy is aligned with the overall business strategy.

Risk Governance is ultimately the responsibility of the board of directors and senior management. They establish risk culture and acceptable level of risk.

Guiding Principles for Effective Risk Management

Maintain business objective focus., Why, Risk Management must provide value.

Integrate IT risk management into Enterprise Risk Management (ERM)., Why, Risk Management must be part of overall enterprise Governance.

Balance the costs and benefits of managing risk., Why, Risk Management costs must be lower than value (monetary and monetary) of assets under protection.

Promote fair and open communication., Why, Risk Management must promote and communicate Risk-aware culture.

Establish tone at the top and assign personal accountability., Why, Risk Management must have defined clear roles and responsibilites in order to be effective.

Daily process with continuous improvement., Why, Risk changes and environment changes (Internal and External), so Risk Management practices must be adapt., Risk management should use historical data and facilitates learning and continual improvement.

Risk Evaluation Process

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

Risk Assessment Process

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

Elements of Risk Assessment, Scope, Description of Assessment Area, Assets, System, Region, Processes, ..., Threats, Vulnerabilities, Likelihood, Impact, Risk Assessment Report

Risk Identification Process

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

The Business Impact of IT Risk

Loss of revenue.

Loss of sensitive information and data.

Loss of reputation / brand visibility / brand image.

Loss of public confidence.

Loss of SLAs / OLAs levels.

LOE to correct problems caused by Threat Actions.

Loss of credibility.

Damage to enterprise’s interest.

System repair costs.

Applicable Guidelines for Risk Appetite and Risk Tolerance

Connectivity of risk appetite and risk tolerance.

Review and approval of exceptions to risk tolerance standards.

Risk appetite and tolerance change over time.

Cost of risk mitigation options can affect risk tolerance.

Risk Capacity, 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.

Risk Tolerance, 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)

Risk Appetite, The amount of risk the organisation, or subset of it, is willing to accept

Risk Hierarchy - 4 Levels of Risk

Portfolio risk, goal, Management of stakeholder perceptions that would affect the reputation of an organization., Ensuring business success of the organization., context, business success, business vitality, finance, core services, organization / enterprise capabilities, resources, portfolio management, by AXELOS®, MoP® - Management of Portfolios standard, see MoP® mind map, by PMI®, The Standard for Portfolio Management 3rd Edition (a.k.a. PfMBOK), see PfMBOK mind map

Program risk, goal, Delivering business change with measurable benefits., Delivering business transformation., Delivering outcomes., context, benefits, capabilities, programme management, by AXELOS®, MSP®- Managing Successful Programmes standard, see MSP® mind map, by PMI®, The Standard for Program Management 3rd Edition (a.k.a. PgMBOK), see PgMBOK mind map

Project risk, goal, Producing defined business change products within time, cost and scope constraints., Delivering outputs., context (6 project parameters), time, budget, benefits, quality, scope, risk, context, project management, by AXELOS®, PRINCE2® - PRojects IN Controlled Environments, see PRINCE2® mind map, by PMI®, A Guide to the Project Management Body of Knowledge: PMBOK® Guide, see PMBOK® 5 Guide mind map

Operational risk, goal, Maintaining business services to appropriate levels., Day-to-day management., Business as Usual (BaU)., context, reputation, volume, quality, internal control, revenue, staff, customer

IT Risk in the Risk Hierarchy (from ISACA® Risk IT™ perspective)

Strategic Risk

Environment Risk

Market Risk

Credit Risk

Operational Risk

Compliance Risk

IT-related Risk

Three IT Risk Categories (from ISACA® Risk IT™ perspective)

IT Benefit / Value Enablement, e.g., Technology enabler for new business initiatives., Technology enabler for efficient operations., Technology enabler for higher SLAs / OLAs levels.

IT Programme and Project Delivery, e.g., Project relevance / priority., Project time / budget overrun., Project quality.

IT Operations and Service Delivery, e.g., IT service interruptions (SLAs / OLAs crisis)., Security issues., Compliance / regulatory issues.

Risk Scenario

What, Risk Scenario is a description of an event that can lead to a business impact, when and if it should occur., Risk Scenario is a technique used to make risk more concrete and tangible and allow for proper risk assessment and analysis.

Why (Purpose of Risk Scenario), Bring realism., Provide insight., Facilitate organizational engagement., Provide improved analysis and structure to the complex nature of enterprise risk.

Risk Scenario components, Actor / Threat Actor / Source, What, Generates the threat is a source of threat. Not every threat requires a Threat Actor., Entity that can adversely act on assets., Internal (to the organization), Intentional, Accidential, e.g., employee, contractor, External (to the organization), Skilled, Unskilles, e.g., competitor, outsider, business partner, regulator, market, act of god, Threat Actors can be also human or nonhuman., In 2008, CSO Magazine reported, In 2009, Verizon Data Breach Investigation Report, Threat Type, What, A nature of the event., A threat consists of an adverse action performed by a threat agent on an asset., e.g., Malicious., Accidental., Failure., Natural., External Requirement., Event, Loss Events, Events generating the negative impact., Vulnerability Events (or vulnerabilities / weaknesses), Events contributing to the magnitude or frequency of loss events occurring., Threat Events, Circumstances or events that can trigger loss events., e.g., Disclosure, Interruption, Modification, Theft, Destruction, Ineffective design, Ineffective execution, Rules and regulations, Inappropriate use, Asset / Resource, What, Any object (tangible, intangible) that has value to enterprise / organization., Tangible, e.g., Application / Software, Process, Facilities, IT infrastructure, Data / Information, People and organization, Intangible, e.g., Information, Reputation, Trust, Time / Timing Dimension, What, Specification of time related information to scenario., e.g., Timing of occurrence (in critical business moment or not), Timing to detect, Timing to react, Timing to recover, Timing lag between event and impact / consequences, Immediate impact / consequences, Delayed impact / consequences, Duration

Risk Scenario development strategies, Top-down approach., Bottom-up approach., Approaches are complementary and should be used simultaneously.

Risk Scenario development process, 1. Use list of example generic scenarios to define a manageable set of concrete scenarios for the enterprise., 2. Perform a validation against business objectives of the entity., 3. Refine the selected scenarios and detail them in line with criticality to entity., 4. Reduce number of scenarios to manageable set., 5. Keep all risks in a Risk Register for easy re-evaluation., 6. Include in scenarios how to handle unspecified events.

Risk Scenario development enablers, Organizational Buy-in., Risk Culture., What, ”Culture is a socially constructed attribute of organizations that serves as the social glue binding an organization together.”, Cameron & Quinn, 2011, ”Groups of people create a culture through shared values and behaviors. How we reward behaviors, how we treat those values as malleable or immutable affects how strong the organization’s culture is and how well it is supported by the participants.”, Building a DevOps Culture, Mandi Walls, 2013, Risk-aware culture is a series of behaviors, Behaviors toward taking risk., Behavior toward negative outcomes., Behavior toward policy compliance., Often one of the most if not the most important enabler!, See great talk on RSA 2014 conference about Risk / Security culture.,, Begins at the top (board / executive / CEO):, Set direction., Communicate risk-aware decision making., Reward effective risk management behaviors., Symptoms of inadequate or problematic risk culture include, Misalignment between real risk appetite and translation into policies., Existence of a “blame culture”., Skilled scenario facilitation / identification., Thorough understanding of environment (internal and external)., Involvement of all stakeholders (especially decision-makers).

Risk Factors

What is it?, A features that influences the likelihood and or business impact of risk scenarios., A condition that can influence the frequency and/or magnitude and, ultimately, the business impact of IT-related events/scenarios.

5 Risk Factors categories, External Environmental, What is it?, External to enterprise / organization circumstances that can increase the likelihood or impact or an event., e.g., Market / economy., Rate of change in the market., Industry / competition., Geopolitical situation., Regulatory environment., Technology status & evolution., Suppliers and partners status., Acts of god / natural disasters., Brand/ trademark., Publicity., Energy., Emissions, effluents and waste., Privacy., Not always controllable by the enterprise / organisation., e.g., Government., International law., Local law., Internal Environmental, What is it?, Internal, within the enterprise / organization circumstances that can increase the likelihood or impact or an event., e.g., Strategic Importance of IT., Complexity of IT., Complexity of enterprise / organization., Degree of change / degree of agility., Change management capability., Risk management philosophy & values., Risk appetite., Risk tolerances., Operating model., Integrity and ethics., Management’s integrity and commitment to ethical values influence preferences and judgments which are translated into standards of behaviour., Organization culture., Tone at the top., Eliminate inappropriate incentives and temptations., Competency levels., Enterprise polices., Enterprise strategy and objectives., Implementation and achievement., Role of board of directors., Enterprise organizational structure., Assignment of authority and responsibility., Delegation of authority., HR Practices., Capabilities, Risk Management Capability, What is it?, How well enterprise is executing the core risk management processes., e.g., IT Capability, What is it?, Context of risk management., Mature and well-controlled IT processes., e.g., Mature IT process reducing likelihood of risk., Mature DRP and BCM., IT Related Business Capability, What is it?, Degree to which business management is capable of managing the direction and performance of IT., e.g., Correct IT partners selection, Well selected / managed programs and projects., Right investments decisions.

Risk Analysis Process

What is it?, Process of integrating risk assessments at a corporate level to obtain a complete view of the overall risk for the enterprise.

Risk Analysis determines, Extent of potential threat., Risks associated with IT systems throughout SDLC.

Risk Analysis methods

Risk Analysis methods / techniques categories:, Qualitative Analysis, What, Subjective using logical reasoning / intuition. Do not operate on numerical data, presenting results in the form of descriptions, recommendations., Expressed e.g. in simple words: low, medium, high., Reputation, Opinion-based, Qualitative Risk Analysis methods (non-exhaustive list), Scenarios, Extrapolative Approach., Normative Approach., Risk Control Self Assessment (RCSA)., Scorecards., Key Risk Indicators (KRI’s)., Likelihood-Impact Matrix., Attribute Analysis., Delphi Forecasting / Method / Methodology., Failure Models and Effects Analysis (FMEA)., Failure Mode and Effects Criticality Analysis (FMECA)., NIST SP 800-30 method., CRAMM methodology., Advantages, It allows for determination of areas of greater risk in short time and without bigger expenditures., Analysis is relatively easy and cheap., Enables visibility and understanding of risk ranking., Easier to reach consensus. Not necessary to quantify threat frequency., Not necessary to determine financial values of assets., Easier to involve people who are not experts on security or computers., Disadvantages, It does not allow for determination of probabilities and results using numerical measures., Costs benefits analysis is more difficult during selection of protections, Achieved results have general character, approximates, etc., Insufficient differentiation between important risks., Difficult to justify investing in control implementation because there is no basis for a cost-benefit analysis., Results are dependent upon the quality of the risk management team that is created., Quantitative Analysis, What, Objective mathematically or statistically based., Used when we have the ability to map a monetary (e.g. dollar) amount to a specific risk., Expressed in monetary values: 10$, 100$, 1000$ etc., Money, financial imapact, Assigning numeric and monetary values, Can be used in caluculating ALE, ALE = SLE x ARO, Quantitative Risk Analysis methods (non-exhaustive list), Internal Loss Data, Internal Loss Data Quality., Economic Losses., Operational Risk Losses., External Data., ALE (Annual Loss Expected) method., Information Security Risk Analysis Method (ISRAM)., Courtney method., Business Process Modelling (BPM) and Simulation., Statistical Process Control (SPC)., Variance-Covariance method., Historical Simulation method., Monte Carlo simulation., Advantages, It allow for definition of consequences of incidents occurrence in quantitative way., The realizations of costs and benefits analysis during selection of protections., It obtain more accurate image of risk., Risks are prioritized by financial impact; assets are prioritized by financial values., Results facilitate management of risk by return on security investment., Results can be expressed in management-specific terminology (e.g., monetary values and probability expressed as a specific percentage)., Accuracy tends to increase over time as the organization builds historic record of data while gaining experience., Disadvantages, Quantitative measures must depending on the scope and accuracy of defines measurement scale., Analysis‘s results may be not precise and event confusing., It must be enriched in qualitative description, Analysis conducted with application of those methods is generality more expensive, demanding greater experience and advanced tools, Impact values assigned to risks are based on subjective opinions of participants., Process to reach credible results and consensus is very time consuming., Calculations can be complex and time consuming., Results are presented in monetary terms only, and they may be difficult for non-technical people to interpret., Process requires expertise, so participants cannot be easily coached through it.

Identifying and assessing IT Risk

Threats and Opportunities inherent in enterprise use of IT.

Clarity in defining business impact (+/-) of IT related risks is critical to understanding threats, vulnerabilities, and opportunities.

Adverse Impact of Risk Event

Loss of degradation of any or a combination of the 3 basic risk goals of CIA:, Integrity, Accuracy & completeness of processing of transaction., Reliability of information processing activities., Accuracy and completeness and security of the output., Data cannot be modified undetectably., Data entered into a database are accurate, valid and consistent., Alteration, Availability, Mission critical system is unavailable for end users., Loss of system functionality., Destruction, Confidentiality, Disclosure

Business Impact Analysis / Assessment (BIA)

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

Why, Establishes the escalation of that loss overtime., Is a discovery process to uncover the inter workings of a given process., Answers the questions about procedures, shortcuts, workarounds, and possible failures., Uses the same qualitative and quantitative techniques.

BIA discovery techniques (non-exhaustive list), Questionnaires., Interviews., Documentation review., Process observation., Personnel observation during work., ID vital material and records (Information asset inventory)., Detect existing workarounds and alternate procedures., Verify critical business functions., OBASHI® methodology., see OBASHI® mind map

Ways of describing IT Risk in business terms (methods, frameworks, standards) (from ISACA® Risk IT™ perspective)

Extended Information Criteria (COBIT®), What is it?, To satisfy business objectives, information needs to conform to certain control criteria, which COBIT refers to as business requirements for information., Based on broader quality, fiduciary, and security requirements, 7 distinct information criteria are defined., The COBIT® Framework identifies which of the 7 information criteria:, Effectiveness, Deals with information being relevant and pertinent to the business process as well as being delivered in a timely, correct, consistent and usable manner., Efficiency, Concerns the provision of information through the optimal (most productive and economical) use of resources., Confidentiality, Concerns the protection of sensitive information from unauthorized disclosure., Integrity, Relates to the accuracy and completeness of information as well as to its validity in accordance with business values and expectations., Availability, Relates to information being available when required by the business process now and in the future. It also concerns the safeguarding of necessary resources and associated capabilities., Compliance, Deals with complying with the laws, regulations and contractual arrangements to which the business process is subject, i.e., externally imposed business criteria as well as internal policies., Reliability, Relates to the provision of appropriate information for management to operate the entity and exercise its fiduciary and governance responsibilities., see COBIT® 5 mind map

Balanced Scorecard (BSC), What is it?, Strategic management system that helps organization translates its strategies into objectives that drive both behaviour and performance. Both financial and non-financial., Measures are designed to track the progress of objectives against targets., Financial, Share value, profit, revenue, cost of capital, debt, ROA, cash flow., Customer, Market share, customer satisfaction, customer service, number of contracts, KYC, customer due diligence, number of claims., Internal, Regulatory compliance, number of incidents, centralized data, process optimization., Growth, Competitive advantage, reputation., Further reading,

Extended Balanced Scorecard (EBSC), What, A variant of BSC approach, linking BSC dimensions to a limited set of more tangible criteria., Financial, Share value, Profit, Revenue, Cost of capital, debt, ROA, Cash flow, Customer, Market share, customer satisfaction, customer service, number of contracts, KYC, Customer due diligence, number of claims, Internal, Regulatory compliance, number of incidents, centralized data, process optimization, Growth, Competitive advantage, Reputation

dr. Westerman 4 A’s, What is it?, Key area of focus presented by Dr Westerman, aka. The Four As Framework, Why, 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., Agility, To be able to change with business with appropriate cost and speed., Is IT helping the business manage change with predictable cost and speed? As the speed of change in the business world accelerates, the capability of IT to build and manage modular, scalable systems and agile processes will be a critical success factor., Accuracy, To provide correct information on time and complete., Is IT helping the business provide timely and accurate information to decision-makers? Is the IT function working transparently, and enabling others to do the same? This theme evokes the importance of analytics to the enterprise, an important investment area for CIOs., Access, To ensure right people access data and systems when they need., Is IT helping people get to the systems they need to do their jobs? This may mean employees, but increasingly it means partners, customers, vendors, regulators, contractors and other external collaborators. As the membranes around the enterprise get increasingly permeable and fuzzy, initiatives like interoperability, identity management, single sign-on, and remote device management become much more important., Availability, To keep systems (and business processes) running and recoverable., This is the classic "How many 9's?" level of risk, where metrics like uptime are most relevant. As Westerman underscores in his book about showing the value of IT to the business: these are table stakes. You will not be invited to the leadership, transformation, and innovation parts of the CIO job if you cannot reliably and effectively supply the utility/commodity parts of it.

Factor Analysis of Information Risk (FAIR), What is it?, 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., The Open Group has adopted FAIR as a key component in its approach to risk management., The "Build Security In" initiative of Homeland Security Department of USA, cites FAIR., By FAIR the risk is the probability of a loss tied to an asset., FAIR defines 6 kind of loss:, 1. Productivity, A reduction of the organization to effectively produce goods or services in order to generate value., 2. Response, The resources spent while acting following an adverse event., 3. Replacement, The expense to substitute/repair an affected asset., 4. Fines and judgements (F/J), The cost of the overall legal procedure deriving from the adverse event., 5. Competitive advantage (CA), Missed opportunities due to the security incident., 6. Reputation, Missed opportunities or sales due to the diminishing corporate image following the event., FAIR defines Value / Liability as:, Criticality, That characteristic of an asset that has to do with the impact to an organization’s productivity., e.g., For example, the impact a corrupted database would have on the organization’s ability to generate revenue., Cost, The costs associated with replacing an asset that has been stolen or destroyed., e.g., Examples include the cost of replacing a stolen laptop or rebuilding a bombed-out building., Sensitivity, The impact resulting from confidential information being disclosed or improperly used., Embarrassment, Competitive advantage, Legal / regulatory, General, FAIR defines Threat as:

COSO® Enterprise Risk Management - Integrated Framework (ERM), What is it?, 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., 4 Objectives categories (vertical columns), Strategic, High-level goals, aligned with and supporting its mission., Operations, Effective and efficient use of its resources., Reporting, Reliability of reporting., Reporting, Compliance with applicable laws and regulations., It should be recognized that the four columns represent categories of an entity’s objectives, not parts or units of the entity., 8 Components (horizontal rows), Internal Environment, Objective Setting, Event Identification, Risk Assessment, Risk Response, Control Activities, Information and Communication, Monitoring, The entity and its organizational units are depicted by the third dimension of the matrix., Each component row “cuts across'' and applies to all four objectives categories., see COSO ERM-IF mind map

Domain 2 - Risk Response

Domain 2 - CRISC™ Exam Relevance

The content area for Domain 2 will represent ..., 17% of the CRISC examination, 34 questions

Risk Response Process

What is it?, Process of addressing the risks identified during risk assessment., Cost benefit analysis., Reduce risk to acceptable levels., Combination of types of controls., Triggered when a risk exceeds an organizations acceptance level., Driven by input from the risk assessment process.

Why, Ensures that the residual risk is within limits of the risk appetite and risk acceptance levels (aka. risk tolerance) of the enterprise., 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., In other words: does asset value still overweight risk response costs including monetary and non-monetary costs.

High level Risk Response Process

1. Review risk analysis results.

2. Select response options.

3. Prioritize options.

4. Implement risk action plan.

Risk Response Process phases & tasks.

Phase 1 - Articulate Risk, Task 1 - Communicate Risk Analysis results., Report results., Coordinate additional RA activities., Communicate risk return., Identify negative and positive impacts., Provide decisions makers summary of exposures, scenarios, and key considerations., Task 2 - Report Risk Management activities., Meet risk reporting needs., Ensure Reporting on Issues and Status is appropriate., Include all pertinent activities in reporting., Provide inputs to integrated enterprise reporting., Task 3 - Interpret Risk Assessment findings., Review results and findings from various sources., Map results to risk profile and control baseline., Consider established risk tolerance., Communicate gaps and exposure to business., Help business understand how corrective action plans affect risk profile., Identify integration opportunities., Task 4 - Identify business opportunities., Recurring risk analysis., Identify IT related capacity parity., Look for opportunities to use IT (technology).

Phase 2 - Manage Risk, Task 1 - Inventory controls., Inventory controls in place., Classify and map controls., Develop control tests., Identify procedures and technology., Partition operational controls., Task 2 - Monitor operational alignment., Ensure business line accountability., Test key risk issues., Obtain Buy-in by management on KRI., Ensure KRI’s are implemented with thresholds, checkpoint and automated communications., Integrate KRI data into performance indicator reporting., Ensure risk analysis is performed when residual risk is outside tolerance., Task 3 - Respond to discovered risk exposures and opportunities., Emphasize projects that are expected to reduce adverse events and balance against strategic opportunities., Hold cost benefit discussion., Select candidate controls., Monitoring changes in business operational risk profiles., Adjust the rankings of risk response projects., Task 4 - Implement Controls., Ensure effective deployment / adjustment of controls., Communicate with key stakeholders., Test controls., Map controls to monitoring mechanisms., Identify and train staff on new procedures., Task 5 - Report IT risk response plan progress., Monitor risk response plans (all levels)., Ensure effectiveness of responses., Determine whether acceptance of residual risk has been obtained., Ensure committed risk responses are owned and deviations are reported to senior management.

Phase 3 - React To Risk Events, Task 1 - Maintain incident response plans., Prepare for materialization of threats., Maintain open communication about risks., Build RTO into action plans., Define pathways of escalation., Verify incident response plans are adequate., Task 2 - Monitor risk., Monitor the environment., When control limit breached; escalate or confirm., Categorize incidents., Communicate business impact., Continue to take action and drive desired outcome., Ensure policy is followed with clear accountability for follow-up actions., Task 3 - Initiate incident response., Take action to minimize in-progress incident impact., Identify impact category., Inform stakeholders of incident., Identify time requirements to carry out plan., Ensure correct action is taken., Task 4 - Communicate lessons learned from risk events., Examine past events and missed opportunities., Determine where failure stemmed from., Research root cause., Determine underlying problem., Identify tactical corrections., Identify and correct underlying root causes., Identify root cause of incidents., Request additional risk analysis as needed., Communicate root cause, response requirements, process improvements.

Risk Response Options

for Threats, Avoid, risk avoidance is achieved by deciding not to undertake a risk by either not taking part in a certain risky activity or by abandoning an asset / source that generates the risk, avoiding all risks is not a viable strategy, if we do not take risks, we cannot gain the benefits that can aris, outcome = risk probability of occurrence is 0%, it simply means to conduct activity where the risk is not met, Reduce, reduce probability (a.k.a. Prevent), reduce impact (a.k.a. Mitigate), reduce probability & impact simultaneously

for Opportunities, Exploit, exploiting the opportunity aims to make the most of an opportunity that arises to make the probability of its outcome to be 100%., it uses extensive measures to ensure that the opportunity becomes a certainty., outcome = risk probability of occurrence is 100%, risk becomes an issue (opportunity becomes a certainty), Enhance (a.k.a. Improve), control methods put in place to increase the likelihood or increase the impact of the opportunity., enhancement methods are not as extensive as exploit controls because they do not aim at making the opportunity a certainty., increse probability (but still <100%), increse impact, increse probability & impact simultaneously

for Threats & Opportunities, Transfer, by transferring risk firms remove their own responsibility for dealing with risk events to someone outside of the organisation / programme / project etc., the most typical examples are taking out insurance and outsourcing., (for opportunity) it aims to transfer the opportunity to a more specialised organisation that will help maximise its effects., you cannot transfer accountability, only risk impact, as name suggest 2nd party is needed for transfer, transfer means transfering all (100%) impact to 2nd party, Share, as name suggest 2nd party is needed for sharing, sharing means sharing at least small percentage of impact with 2nd party, Accept, accepting an opportunity basically leaves everything to chance, Passive Acceptance, without monitoring, Active Acceptance, with monitoring, Prepare Contingent Plans, only reduces impact, does not changes probability

Risk Response Process parameters

Cost of Response to Reduce Risk Within Tolerance Levels.

Importance of Risk.

Capability to Implement Risk Response.

Effectiveness of Response.

Efficiency of Response.

Risk Response Prioritization

Quick win.

Business case to be made.


Risk Response Prioritization Options

Risk Response Prioritization Factors

Stakeholder interests / perception

Acceptance of change.

Solution balance.

Cost., Including monetary and non-monetary costs (e.g. time, scope)

Productivity impact (impact on BaU).

Control ownership.

Ability to monitor, audit and control.


Market condition changes.

Ability to execute.

Ability to rollback (if needed).

Risk Mitigation Control Types




Preparedness activities.

Risk Response programs

Prioritize Risk Response programs according to risk levels:, Look for quick wins., Search by experience and known situations.

Update Risk Register.

Ensure that controls are designed and implemented correctly:, A control poses a new risk to the organization.

Domain 3 - Risk Monitoring

Domain 3 - CRISC™ Exam Relevance

The content area for Domain 3 will represent ..., 17% of the CRISC examination, 34 questions

Risk Monitoring Process

What is it?, Process accomplished by selecting KRIs from all the controls and data points available., Periodically re-evaluate risk levels.

Select which controls will be used as Key Risk Indicators (KRIs):, Controls that indicate important risk issues or risk trends., Monitored on a regular basis to allow results to be compared over time., Reflect business priorities.

Risk Indicators

What is it?, Metrics used to indicate risk thresholds and when a risk level may be approaching a high or unacceptable level of risk., 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.

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

Risk indicators are placed at control points positioned to gather data used to:, Gauge risk levels at a point in time., Track events and incidents., That may indicate a potential hazardous situation.

Key Performance Indicators (KPIs)

Requirements that a KPI must satisfy:, Contribution to CSFs, The connection between the KPI and the CSF above must be demonstrable and described., Stakeholders, 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., Relevance, The KPI, together with other KPIs, must cover as much of the information needs as possible, which is explicitly coordinated with the stakeholders., Ownership, 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., Recognizable, KPIs are recognizable for employees., Repeatable, The KPI must be able to be established regularly and in the same way., Traceable, The way in which the result of the KPI was achieved must be described., Uniformity of processes, The KPIs must result from processes that are interpreted and implemented in a uniform way by all stakeholders., Standard, In particular, if KPIs are used for a benchmark, they must correspond to existing standards and be described using standard definitions., Costs vs benefits, 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., SMART, The KPI must be Specific, Measurable, Acceptable (for all stakeholders), Realistic, and Time-dependent., The I in KPI stands for indicator, The goal of KPI is to provide insight into what can be improved and is not intended as a way of settling scores

Key Risk Indicators (KRIs)

KRIs are like signals / triggers:, Indicate warning thresholds., Allow tracking and reporting., Highlight trends in developing or potential risk.

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

KRIs are subset of Risk Indicators (RI).

Types, Logs., Alarms., Reports., Calls., Events., Incidents., ...

Parameters, Size and complexity of enterprise., Business vision / mission stability., Type of market in which the enterprise operates., Strategy focus of the enterprise.

Factors, Create ownership of Risk Indicators, Involve stakeholders to obtain buy-in., Include all stakeholders, operational and strategic., Balanced selection of risk indicators, Lag (detective)., Lead (preventative)., Trend (indicator correlation / risk)., Ensure Indicators reflect Root Cause. Map unique root cause to single or specific of indicators to avoid false conclusions.

Criteria for KRI selection, Impact:, Controls covering high impact risks., Effort:, Controls that are easy to monitor., Reliability:, Close relationship between the risk and the control., Sensitivity:, Accurately reflect changes in risk., Repeatability:, Is repeatable so it can be measured in regular basis.

Benefits of selecting right KRIs, Forecast developing risks (forecasts / forward-looking):, Trends/preventative., Post-incident review (backward-looking):, Analysis and lessons learned., Better future risk response., Document trends:, Watch developing risks over time., Measure risk appetite and tolerance:, Compliance., Increase likelihood of meeting strategic objectives., Assist in optimizing risk governance and risk management environment.

Disadvantages of wrong KRIs, No linkage from KRI to specific risk., Useless., Unclear or incomplete KRIs:, Not industry or market specific., Too generic, to organization / department / project specific., Too many KRIs:, Meaningless., Difficult to measure:, Hard to compare, interpret, or aggregate.

Changing KRIs / KRIs Maintenance, Risk changes - so should KRIs:, Different trigger levels., Each KRI is related to the risk appetite and tolerance so that trigger levels can be defined that enable stakeholders to take appropriate action in a timely manner.

Optimizing KRIs, Sensitivity:, Collecting too much data., Solution: Only collect critical level data., Timing:, Data collected too late to take corrective action., Solution: Collect abnormalities in a timely manner., Frequency:, Data collected daily but reported monthly., Solution: set sample rate., Corrective action gaps:, Reports do not indicate priority corrective action underway., Solution: project management tools, assign owners of risk.

Gathering KRI information / data

KRIs rely on information / data from diverse sources.

Steps to Data Gathering, Gathering requirements, Requires input from, Data / Information / Process owners., Programme / Project owners / SROs., System custodians., Compliance committee., Audit committee., Other process stakeholders., Information / Data access, Direct data access, Preferred method (integrity reasons)., Direct retrieval of required data (raw format / no filtering)., Receipt of data extracts, From system custodians (be aware of risk of loosing integrity, risk of filtering)., Specify format of data (be aware of data format constraints)., Information / Data validation, Information / Data prepared for analysis:, Accurate., Free of errors., Valid., Integral., Complete., Consistent structure., On time., Compare data from different sources for accuracy., Statistical analysis helps assess data validity., Information / Data validating considerations:, Control Totals., Duplicates., Missing items., Orphan records., Ranges., Reasonableness., Relationships., Reliability., Statistical anomalies., Validity., Information / Data analysis, Ensure that information / data analysis supports the review objective:, Check analysis logic rules carefully., Refine as needed., Analysis should be repeatable:, Frequency depends on., Sensitivity., Range., Time., Reporting & corrective action, Reports generated and sent:, To the right people., With correct level of detail., In an understandable format., With the right frequency., Depending on types of controls being monitored., With correct information.

Maturity Level Assessment

Use of Maturity Level Assessment, Determine maturity level of several key factors., Provides gap analysis between current and desired state., Supports projects to address processes at unacceptable maturity level., Maturity Models are well known concept not only in IT or Risk Management domain.

Assessing Risk Maturity Levels, Boards need accurate reporting on maturity of risk management efforts:, Ensure risk is managed enterprise-wide., Correct priorities., Activities necessary to develop greater maturity., Maturity levels are assessed from unpredictable, uncontrolled processes, to levels of consistency and continuous improvement.

Levels, Level 0 - Non-existent:, Management processes are not applied at all., Level 1 - Initial / Ad hoc:, Processes are ad hoc and disorganized., Level 2 - Repeatable But Intuitive:, Processes follow regular pattern., Level 3 - Defined Process:, Processes are documented and communicated., Level 4 - Managed and Measureable:, Processes are monitored and measured., Level 5 - Optimised:, Good practices are followed and automated.

see Maturity Models mind map

Changing Threat Levels

Market conditions.

New technology.

Aging technology.

Staff experience levels (aka. capabilities).

Regulations and legislation (aka. constraints).

Attackers skill level.

New connections to global systems.

Measuring Changes in Threat Levels, Open new vulnerabilities., Bypass or remove existing controls., Adversely affect potential business levels.

Responding to Changes in Threat Levels, Changes in threat levels may mandate changes in:, Network infrastructure., Policies., Procedures., Threat-specific countermeasures., Compensating controls.

Threat Level Review, The threat level (aka. Risk Profile) for the organization must be checked at least:, Annually., Whenever there is a major change to the system., Following any major incident., The risk may be checked as a specific periodic review or in an incremental manner:, Regulation., PCI-DSS requirements., ISO 27001 requirements.

Changes in Asset Value

Changes in asset value will have a direct impact on risk levels:, End of life for a product or service., Rapidly growing new product or service., Size of stored customer data.

Risk Reporting

Types of risk communication reporting content include, Expectations from risk management:, Policies, strategy, procedures, awareness training etc., Status with regard to IT risk:, Risk profile of enterprise, KRIs, thresholds, loss data, etc., Current risk management capability:, Risk management process maturity, how well risk is manager etc., Actionable Items.

Effective Report Writing Skills, Report writing can be described as a career skill., Not only is it a task that forms part of an increasing number of business jobs, but it can make a huge difference to how you are perceived and how well you get on in your career., Today, good communication skills and the ability to write effective reports are essential competencies in the workplace., Style is the most nebulous area of report writing., It is very easy to criticise a writer’s style as ‘poor’ or ‘inappropriate’., What is not so easy is to specify the stylistic improvements that should be encouraged.

Good vs. Poor Communication, Benefits of good communication include:, Contributing to managements understanding of exposures., Awareness., Transparency to external stakeholders., Consequences of poor communication include:, Perception that the enterprise lacks transparency with external stakeholders., Incorrect perception by external stakeholders., False sense of confidence relating to exposure.

Effective reports, Clear:, e.g. use plain language (Language clarity), are logically ordered and easy to navigate (Structural clarity / logic flow), highlight important information, explain complex information in plain language., Concise:, e.g. concise document is a piece of writing that conveys only the needed material., Coherent:, e.g. at the paragraph level, coherence is achieved by organizing material into a topic sentence and supporting sentences., Useful., e.g. enable decision making., Timely., Appropriate:, e.g. aimed at the correct audience based on levels of knowledge, format of report., Available only to personnel on a ‘need-to-know’ basis.

Possible Risk Report recipients, Steering committee., Senior Management Team:, CEO., CFO., CIO., CRO / CIRO., Business unit directors., Consultants., Security experts., Subject domain experts., IT Directors., PMOs., Compliance and Audit.

Reporting on Periodic Risk Assessment, On a periodic basis to steering committees and responsible managers (e.g. Project / Programme Manager) to enable timely response to emerging trends., Indicate progress on risk mitigation activities.

Risk Reporting topics, Current levels of policy, culture and compliance., Current risk status:, KRI thresholds., Changes over past period., Forecast of future risk., Capability of staff to meet risk scenarios., State of awareness programs., Past incidents.

Risk Reporting methods (non-exhaustive list), Face to face (F2F) meetings., Heatmaps., Dashboards., Workshops., Bubble charts., Risk prioritisation chart., Facilitated workshops., Distribution lists., Centralized web portals, PPM software.

Domain 4 - Information Systems Control Design and Implementation

Domain 4 - CRISC™ Exam Relevance

The content area for Domain 4 will represent ..., 17% of the CRISC® examination, 38 questions


Policies, procedures, practices and guidelines designed to provide reasonable assurance that:, Business objectives are achieved., Undesired events are prevented or detected and corrected.

Control Categories

Compensatory, Reduces likelihood of Attack

Corrective, Controls that remedy incident, Decrease Impact

Detective, Controls that identify incident, Reduces likelihood of Attack

Deterrent, Discovers Attack, Triggers Preventive Controls

Directive, Regulations, Policies, Standards, Guidelines, Processes & Procedures

Preventative, Controls that avoid incident, Protects Vulnerability, Reduces Impact

Control Types

Technical / Logical:, Safeguards or countermeasures built into computer equipment and software to avoid, counteract or minimize security risks relating to personal property, or any company property., e.g., ACLs, Antivirus software, firewalls, IPS, IDS

Nontechnical:, Management (Administrative), e.g., Policies, Standards, Processes, Procedures, Guidelines, Supervision, Operational (and Physical), e.g. locks, compartmentalized areas, fences, doors, gates, extinguishers., Physical Security (Facility or Infrastructure Protection), Designed to deny unauthorized access to facilities, equipment and resources, and to protect personnel and property from damage or harm., e.g., Doors, Safes, Locks, Fences, Environmental controls (air conditioning), Extinguishers, Operational Security (Execution of Policies, Standards & Process, Education & Awareness), e.g., Program Security, Personnel Security, Document Controls (or CM), HR, Finance

according to, NIST SP800-53, Rev 3, Recommended Security Controls for Federal Information Systems, ISO/IEC 27001:2013 Information technology - Security techniques - Information security management systems - Requirements

Control Types and Effects

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

Impact (Business impact), The net effect, positive or negative, on the achievement of business objectives.

Preventive control, 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.

Threat, 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

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

Control Strength

Cannot be determined by simple control category identification.

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

Must be assessed within context.

Can be effectively assessed only by measuring against control objective.

Meaningful control design considerations include:, Design effectiveness., Operating effectiveness., Alignment with operating environment.

Control Costs and Benefits

Cost-benefit Analysis, Provide a monetary impact view of risk., Determine the cost of protecting what is important., Make good choices.

Total Cost of Ownership (TCO) for controls

Acquisition costs.

Deployment and implementation costs.

Recurring maintenance costs.

Testing and assessment costs.

Compliance monitoring and enforcement.

Inconvenience to users.

Reduced throughput of controlled processes.

Training in new procedures or technologies as applicable.

End of life decommissioning.

Software Development Life Cycle (SDLC) Process

The SDLC process governs:, The phases deployed in the development or acquisition of a software system., Depending on the methodology, may even include the controlled retirement of the system.

Various types / formats of SDLC, waterfall, e.g., Classic Waterfall: DoD-STD-2167A, Modified Waterfall: MIL-STD-498, PRINCE2®, ASAP (Accelerated SAP), iterative, e.g., Boehm’s Spiral Model, Rapid Application Development (RAD) Model, iterative & incremental & adaptive (a.k.a. true ’agile’), Agile is a umbrella term enclosing different methodologies, tools, techniques, practices and frameworks, e.g., Rational Unified Process (RUP), Dynamic Systems Development Method (DSDM®), see DSDM® v6 (2014) mind map, Agile Project Management (AgilePM®), methodology derived from DSDM v5 in 2010, see AgilePM® mind map, eXtreme Programming (XP),,, Lean Software Development (LSD), Feature-driven design (FDD), Scalable Agile Framework (SAFe),, Disciplined Agile Delivery (DAD),, Scrum,,, ..., Plan-Driven Projects vs. Change-driven Project Projects

SDLC phases (generic, not methodology specific), 1. Feasibility study, Do we need this project / product? Is it aligned with our mission?, 2. Requirements study, What exactly do we need? Can we do it? Budget? Scope? Time?, 3. Requirements definition, Business analysis. Use stories. Use cases. Business process modelling., 4. Detailed design, Mock-ups, Prototypes, Designs, Models, Technical Specifications., 5. Programming, Coding, 6. Testing, 7. Installation, Up and running on production., 8. Post-implementation review, 9. Benefits realization

High Level SDLC phases (from CRISC™ perspective), 1. Project Initiation, Tasks, 1. Conduct a feasibility study, 2. Define requirements, Business Information Requirements, Effectiveness., Efficiency., Confidentiality., Integrity., Availability., Compliance., Reliability., Training., 3. Acquire software “Options”, 2. Project Design and Development, Proposed system has:, Adequate controls., Test plans., Monitoring capability., Leading Principles for Design and Development, Align with the business., Use technology to enable change (and agility)., Leverage existing technology (build on solid foundations)., Embrace simplicity., Remain Flexible., Build within the enterprise’s capabilities., Learn from failure (and improve)., Project Status Reports, Ongoing reports regarding:, Any changes to time frames, budget, deliverables, scope of controls., Status of controls in development / implementation., Changes to risk levels., 3. Project Testing, Meets the business requirements., Has appropriate controls implemented., Is ready to be migrated to production., 4. Project Implementation, Project Implementation planning., Develop and establish technical infrastructure., Roles., Skills training., New processes., Supporting infrastructure., Ensure controls operate correctly., Challenges in implementation, Manage project phases:, From building to integrating to migrating the system., Phasing-out of old system. (aka. Roll-out), Phasing-in of new system. (aka. Roll-in), Communicate changes to users and support staff., Conducting change management of new process „status quo” a new way of working into practice (human factor):, Awareness programs., Trainings:, Deliver and evaluate effectiveness of training., Maintain training program., Coaching., Data Migration / Conversion Considerations, Data field formats and sizes:, Alphanumeric., Length., File or database structure:, Relational databases., BigData., Flat files., Cloud computing., Coding schemes., Risks During Data Migration, Interruption to business operations., Corruption of data., Breach of data confidentiality., Inconsistencies between legacy and new systems., Data Conversion Project Key Considerations, Completeness of data conversion., Data integrity., Storage and security of data under conversion., Data consistency., Business continuity., Changeover (Go-live) Techniques (moving into production), Parallel changeover:, Cut over when new systems are proven effective., Run both systems., Phased changeover:, Difficulty of maintaining integrity of data on both systems., Incrementally cut over modules or subsystems., Abrupt changeover:, Hard cutover from old to new system., 5. Project Post Implementation review, Conducted by independent personnel., Compare to initial project design and baselines., Focus on control effectiveness., Compare to previous audits., Document findings and recommendations., Does the system meet:, User expectations / needs., Expected ROI / ROSI (return on investment / return on security investment)., Performance standards., Acceptable risk levels., Are recommended modifications scheduled., System being supported adequately., Security controls working correctly., Closing a Project, Assign outstanding risks, issues, contracts., Conduct formal reviews of project., Determine lessons learned., Determine lessons learned recipients (probable PMO or canter of excellence), Ensure project documentation is complete and up to date., Archive project documentation., Ensure responsibility for security controls and risk management is assigned., Ensure controls continue to operate effectively., (if required) months / years after project, analyse projects benefits assessments in comparison to benefits baselines.

Business Risk, The risk that the system may not meet the users’ expected benefits, services or requirements, e.g., Risk of ”shelfware” - a piece of software that has never been used at all since its creation., Risk of ”bloatware” - type of software that using more system resources than necessary.

Project Risk, The risk that the project is under., e.g. in PRINCE2® each project risk impact is measured against all 6 project parameters, Budget, Project budget, Project risk budget, Project change budget, Time, Project time, Project phase time, Project work package time, Quality, quality of delivered deliverables / products, quality and maturity of project management practices, Scope, Risk of ‘fatware’ e.g. 80% of software functionalities never used, Risk, Overall project risk profile in risk tolerance, Benefits, Risk associated with project benefits (during and after the project)

Understanding Business and Risk Requirements, The business usually does not really know their risk requirements, Lead the business through a process to discover their risk requirements, What risks will this new system pose to the business?, How critical is the system to enterprise?, Does this system contain / process sensitive data?, Who will use the system (end users / employees / technical support / customers)?, Does this system is under local law requirements?, Does system scope is under specific norm, e.g. ISO / EIC 27001, HIPPA, BESEL III?

Project Management and Controlling, Scope Management, e.g., Change approval process, Time Management, e.g., Critical Path Method (CPM), Slack Time, Budget Management, e.g., Measuring and reporting resource usage, Risk Management, e.g., Project Risk Profiles, Quality Management, e.g., Project quality strategies, Benefits Management, e.g., Project benefits strategies

PM tools and techniques (non-exhaustive list), Critical Path Method (CPM), example #1, Gantt chart, example #1, PERT chart and CPM, example #1, Product Breakdown Structure (PBS)., Resourse Breakdown Structure (RBS)., Work Breakdown Structure (WBS).

HR Practices

Job descriptions

Cross trainings, Professional education, Job training, Awareness training

Job rotation

Mandatory vacations

Domain 5 - Information Systems Control Monitoring and Maintenance

Domain 5 - CRISC™ Exam Relevance

The content area for Domain 5 will represent ..., 17% of the CRISC® examination, 38 questions

IS Control Monitoring Process

IS Control Monitoring and Maintenance Process phases

1. Prioritize risk

2. Identify controls

3. Identify information

4. Implement monitoring

5. Report results

Gathering Monitoring Data

Direct Information, e.g., Information obtained directly by the analyst, Sampling, Tools

Indirect Information, e.g., Information provided by a third party

Key Control Indicators (KCIs)

An indicator which is used by organisations to help define its controls environment and monitor levels of control relative to desired tolerances.

Select & Implement Automated Monitoring Tools





Impact on Performance.

Usability of Existing Tools.

Tool Complexity.


License & Ownerships Cost / Benefit.

Monitoring Tools

Monitoring tools can focus on various dimensions of internal control.

Monitoring tools are organized into groups based on their control monitoring focus:, Transaction data., Conditions., Changes., Processing Integrity., Error management.

Transaction Data Monitoring

This group of tools perform the following functions:, Compare transaction data against a defined rule set., Ad hoc reporting., Data correlation across multiple sources.

Compliance Monitoring

This group of tools perform the following functions:, Examine specific settings or parameters., Compare configuration information against a baseline., Operating periodically - scanning basis., Can be agent based (embedded in hardware or software).

Process Monitoring

The CRISC™ will monitor risk associated with:, Error reporting and handling., Change control., Project management., Business continuity plans., Incident reports.

Continuous Monitoring

Increasing importance with the advent of e-business.

Provides a method to collect data evidence and system reliability, integrity and compliance as part of normal progressing function.

Allows for monitoring on a continuous basis in a automated fashion.

This type of tools are designed to automate the evaluation process The most common types include:, Continuous and Intermittent Simulation (CIS)., Snapshots., Monitor Hooks., Integrated Test Facility (ITF)., Systems Control Audit Review File and Embedded Audit Modules (SCARF/EAM).

Cause and Effect Diagram

Cause and Effect Diagram Steps, Agree on effect or problem statement., Identify major categories of failure., Link the potential or observed control failures to the categories., Discuss the control failure points with the project team., Revise the monitoring process and repeat testing as necessary.

example #1

Overview of the CRISC™ certification

About the CRISC™ exam

CRISC™ exam questions are developed with the intent of measuring and testing practical knowledge and the application of general concepts and standards.

PBE & CBE (only pencil & eraser are allowed)., PBE - Paper based exam., CBE - Closed book exam.

4 hour exam.

200 multiple choice questions designed with one best answer.

No negative points.

Pre-requisite for exam:, none

Pre-requisite for certification:, Read CRISC™ Application Form,

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


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.

Ideally only one person should be accountable - from accountability reasons., e.g., Project Management is accountable for risk affecting his project., Team Leader is accountable for risks affecting his team and work.

Asset (ISACA®)

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

Business Impact Analysis / Assessment (BIA)

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

Business risk

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

e.g., Risk of ”shelfware” - a piece of software that has never been used at all since its creation., Risk of ”bloatware” - type of software that using more system resources than necessary.

Business case (ISACA®)

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.

Compensating control

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


Policies, procedures, practices and guidelines designed to provide reasonable assurance.

Data custodian (ISACA®)

The individual(s) and department(s) responsible for the storage and safeguarding of computerized data.

Data owner (ISACA®)

The individual(s), normally a manager or director, who has responsibility for the integrity, accurate reporting and use of computerized data.


Generally accepted, business process-oriented structures that establish a common language and enable repeatable business processes.

e.g., AXELOS® M_o_R® - Management of Risk, UK best practices, see M_o_R® mind map, COSO Enterprise Risk Management (ERM) - Integrated Framework, see COSO ERM-IF mind map, COSO Internal Control (IC) - Integrated Framework, see COSO III IC-IF mind map, DHS Risk Management Framework, USA framework, Framework for Improving Critical Infrastructure Cybersecurity, USA framework, Pages: 39, see RSA Confereence interview - The Evolving Cybersecurity Framework,, ISACA® - The Risk IT Framework, USA framework, NIST Risk Management Framework (RMF), USA framework, Process

Impact (Business impact)

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


To determine the likelihood of future events, enterprises / organizations must analyse threats to an it system, potential vulnerabilities, and the controls in place.

Possibility observed factors, qualitative.


aka. Good Practice / Leading Practice / Generic Practice.

Frequent or unusual actions performed as an application of knowledge.

e.g., APM Body of Knowledge, UK standard, Association for Project Management (APM), AS/NZS HB 436:2004 Risk Management Guidelines Companion to AS NZS 4360:2004, Australian guidlines, Standards Australia/Standards New Zealand (AS/NZS), Pages: 130, BS 6079-3:2000: Project Management – Part 3: Guide to the Management of Business-related Projects Risk, UK guidlines, British Standards Institution (BSI), BS 7799-1:2005 Information technology - Security Techniques - Code of practice for information security management (ISM), UK standard, British Standards Institution (BSI), Pages: 130, BS 7799-2, UK guidance, British Standards Institution (BSI), BS 7799-3, UK guidance, British Standards Institution (BSI), BS 31100:2008 Risk management. Code of practice, UK standard, British Standards Institution (BSI), CAN/CSA-Q634-91 - Risk Analysis Requirements and Guidelines, Canadian guidlines, ISACA® - The Risk IT Practitioner Guide, USA guidlines, ISACA, ISO Guide 73:2009 Risk management - Vocabulary, International guidlines, Pages: 24, ISO/EIC 27003:2010 Information technology - Security techniques - Information security management system implementation guidance, International guidlines, Pages: 74, ISO/EIC 27005:2013 IT Risk: Turning Business Threats Into Competitive Advantage (ISRM), International guidlines, Process, Risk treatment activity, PMBOK®5 Guide (includes Risk Management guidelines in projects), USA best practices, Pages: 46 (chapter 11), Process, see PMBOK®5 mind map, Project Risk Analysis and Management (PRAM) Guide, UK guidlines, Pages: 186

Preventive control (ISACA®)

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.


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

Chance, parameters and computation, quantitative.

Project risk

The risk that the project is under.

e.g. in PRINCE2® each project risk impact is measured against all 6 project parameters, Budget, Project budget, Project risk budget, Project change budget, Time, Project time, Project phase time, Project work package time, Quality, quality of delivered deliverables / products, quality and maturity of project management practices, Scope, Risk of ‘fatware’ e.g. 80% of software functionalities never used, Risk, Overall project risk profile in risk tolerance, Benefits, Risk associated with project benefits (during and after the project)

Reputation risk (ISACA®)

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

Residual risk

The remaining risk after management has implemented a risk response.


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

Ideally more than one person should be responsible (additional workforce, human resource backup in case of unavailability of first person)., e.g., Software Developer, Server Administrator, Data Custodian


The potential for events and their consequences, contains both (aka. two sides of the risk coin):, Opportunities, for benefit (upside / benefits), Threats, to success (downside / disbenefits)

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

Risk appetite

Risk appetite is intangible and cannot be measured directly., Analogy of physical appetite or hunger, which cannot be directly quantified., ‘I could eat a horse’, ‘I fancy a doughnut’, ‘hungry kike the wolf‘

Appetite is always different across organizations.

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).

Risk Appetite is connected with Risk Attitude and Risk Tolerance., see RARA Model,

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

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.

Risk attitude

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.

Risk Attitude is connected with Risk Appetite and Risk Tolerance., see RARA Model,

Risk awareness

Acknowledging that risk is an integral part of the business.

Risk communication

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

Risk culture

”Culture is a socially constructed attribute of organizations that serves as the social glue binding an organization together.”, Cameron & Quinn, 2011

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

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

Often one of the most if not the most important enabler!, See great talk on RSA 2014 conference about Risk / Security culture.,

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.

Begins at the top (board and executive), Set direction., Communicate risk-aware decision making., Reward effective risk management behaviors.

Risk-Aware Culture is a series of behaviors, Behaviors toward taking risk., Behavior toward negative outcomes., Behavior toward policy compliance.

Symptoms of inadequate or problematic risk culture include, Misalignment between ‘real’ culture and policies., Misalignment between real risk appetite and translation into policies., Existence of a “blame culture” vs ”learning culture ”.

Risk impact

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

Risk indicators (ISACA®)

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

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.

Risk Management Process

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.

Holistically covers all concepts and processes affiliated with managing risk, including:, Systematic application of management policies, procedures and practices., Establishing the context., Communicating, consulting., Identifying., Analysing., Evaluating., Treating., Controlling., Monitoring., Reviewing.

Risk subcultures

Individual business units, functions and departments will have slightly different risk cultures.

Risk tolerance

The acceptable variation relative to the achievement of an objective (often best measured in the same units as those used to measure the related objectives: costs, time, value, quality etc.)

Risk tolerance always need to be measureable in order to be controlled.

"You cannot control it, if you cannot measure it."

Risk Tolerance is connected with Risk Attitude and Risk Appetite., see RARA Model,

Risk tolerance vs Risk appetite

Risk factors (ISACA®)

A features that influences the likelihood and or business impact of risk scenarios.

A condition that can influence the frequency and/or magnitude and, ultimately, the business impact of IT-related events/scenarios.


Established mandatory rules, specifications and metrics used to measure compliance against quality, value, etc.

e.g., A Risk Management Standard (Ferma), UK standard, Federation of European Risk Management Associations (FERMA), Pages: 18, Process, AS/NZS 4360:1995 & AS/NZS 4360:2004 Risk management, Australian standard, Standards Australia/Standards New Zealand (AS/NZS), Pages: 28, Process, BS IEC 62198:2001, UK standard, British Standards Institution (BSI), CAN/CSA-Q850-97 - Risk Management: Guideline for Decision-Makers, Canadian standard, Canadian Standards Association (CSA), Pages: 62, Process, CEI/IEC 62198:2001: International Standard, Project Risk Management: Application Guidelines, Switzerland standard, International Electrotechnical Commission, Switzerland, IEEE Standard 1540-2001 Standard for Software Life Cycle Processes - Risk Management, USA standard, Institute of Electrical and Electronic Engineer (IEEE), Pages: 30, Process, ISACA IT Audit and Assurance Standards, USA standards,, ISO 31000:2009 Risk management - Principles and guidelines, International norm, Pages: 34, Process, ISO/EIC 27001:2013 Information Technology - Security techniques - Information security management systems (ISMS) - Requirements, International norm, Pages: 30, JIS Q2001:2001 Guidelines for development and implementation of risk management system, Japan standard, Japanese Standards Association (JSA), ONR 49000 series, Australian standard, PCI DDS, International norm

Threat (ISACA®)

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

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

Vulnerability (ISACA®)

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

CRISC™ Official website

Official Recommended exam study materials


Development Guides

ISACA® CRISC™ QAE Item Development Guide,

ISACA® CRISC™ Item Development Guide:,

ISACA® CRISC™ Review Manual 2015

ISACA® Risk IT™ Framework

ISACA® Risk IT™ Practitioner Guide

ISACA® CRISC™ Review Questions, Answers & Explanations Manual 2015 Supplement

ISACA® CRISC™ Review Questions, Answers & Explanations Manual 2015

ISACA® CRISC™ Practice Question Database

Domains relationships

Interactive Glossary

Interactive CRISC™ Glossary

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!)

Questions / issues / errors? What do you think about my work? Your comments are highly appreciated. Please don't hesitate to contact me for :-) Mirosław Dąbrowski, Poland/Warsaw.