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.1.1. It covers 5 domains, 39 tasks and 72 knowledge statements (statements covering the required technical knowledge).
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. Overview of the CRISC™ certification
3.1. About the CRISC™ exam
3.1.1. CRISC™ exam questions are developed with the intent of measuring and testing practical knowledge and the application of general concepts and standards.
3.1.2. PBE & CBE (only pencil & eraser are allowed).
3.1.2.1. PBE - Paper based exam.
3.1.2.2. CBE - Closed book exam.
3.1.3. 4 hour exam.
3.1.4. 200 multiple choice questions designed with one best answer.
3.1.5. No negative points.
3.1.6. Pre-requisite for exam:
3.1.6.1. none
3.1.7. Pre-requisite for certification:
3.1.7.1. Read CRISC™ Application Form
3.1.7.1.1. http://www.isaca.org/Certification/CRISC-Certified-in-Risk-and-Information-Systems-Control/Documents/CRISC-Application.pdf
4. CRISC™ Official website
4.1. http://www.isaca.org/Certification/CRISC-Certified-in-Risk-and-Information-Systems-Control/Pages/default.aspx
5. Official Recommended exam study materials
5.1. Glossary
5.1.1. http://www.isaca.org/Knowledge-Center/Documents/Glossary/CRISC-glossary.pdf
5.2. Development Guides
5.2.1. ISACA® CRISC™ QAE Item Development Guide
5.2.1.1. https://www.isaca.org/Certification/Write-an-Exam-Question/Documents/CRISC-QAE-Item-Development-Guide.pdf
5.2.2. ISACA® CRISC™ Item Development Guide:
5.2.2.1. http://www.isaca.org/Certification/Write-an-Exam-Question/Documents/CRISC-Item-Development-Guide-2013.pdf
5.3. ISACA® CRISC™ Review Manual 2015
5.3.1. https://www.isaca.org/bookstore/Pages/Product-Detail.aspx?Product_code=CRR15
5.4. ISACA® Risk IT™ Framework
5.4.1. https://svpr-isg-a1.isaca.org/ISGweb/Purchase/ProductDetail.aspx?Product_code=RITF
5.5. ISACA® Risk IT™ Practitioner Guide
5.5.1. https://svpr-isg-a1.isaca.org/ISGweb/Purchase/ProductDetail.aspx?Product_code=RITPG
5.6. ISACA® CRISC™ Review Questions, Answers & Explanations Manual 2015 Supplement
5.6.1. https://www.isaca.org/bookstore/Pages/Product-Detail.aspx?Product_code=CRQ15ES
5.7. ISACA® CRISC™ Review Questions, Answers & Explanations Manual 2015
5.7.1. https://www.isaca.org/bookstore/Pages/Product-Detail.aspx?Product_code=CRQ15
5.8. ISACA® CRISC™ Practice Question Database
5.8.1. https://www.isaca.org/bookstore/Pages/Product-Detail.aspx?Product_code=XMXCR14-12M
6. 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!)
6.1. Questions / issues / errors? What do you think about my work? Your comments are highly appreciated. Feel free to visit my website: www.miroslawdabrowski.com
6.1.1. http://www.miroslawdabrowski.com
6.1.2. http://www.linkedin.com/in/miroslawdabrowski
6.1.3. https://www.google.com/+MiroslawDabrowski
6.1.4. https://play.spotify.com/user/miroslawdabrowski/
6.1.5. https://twitter.com/mirodabrowski
6.1.6. miroslaw_dabrowski
7. Domain 1 - Risk Identification, Assessment and Evaluation
7.1. Domain 1 - CRISC® Exam Relevance
7.1.1. The content area for Domain 1 will represent ...
7.1.1.1. 31% of the CRISC examination
7.1.1.2. 62 questions
7.2. Risk Management Process
7.2.1. What is it?
7.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.
7.2.1.2. Holistically covers all concepts and processes affiliated with managing risk, including:
7.2.1.2.1. Systematic application of management policies, procedures and practices
7.2.1.2.2. Establishing the context
7.2.1.2.3. Communicating, consulting
7.2.1.2.4. Identifying
7.2.1.2.5. Analysing
7.2.1.2.6. Evaluating
7.2.1.2.7. Treating
7.2.1.2.8. Controlling
7.2.1.2.9. Monitoring
7.2.1.2.10. Reviewing
7.2.2. High Level Process Phases (Risk IT)
7.2.2.1. 1. Collect Data
7.2.2.2. 2. Analyze Risk
7.2.2.3. 3. Maintain Risk Profile
7.3. Risk Governance
7.3.1. Strategic business function that helps ensure that:
7.3.1.1. Risk Management activities align with the enterprise’s loss capacity and leadership’s subjective.
7.3.1.2. Risk Management strategy is aligned with the overall business strategy.
7.3.2. Risk Governance is ultimately the responsibility of the board of directors and senior management. They establish risk culture and acceptable level of risk.
7.4. Guiding Principles for Effective Risk Management
7.4.1. Maintain business objective focus.
7.4.1.1. Why
7.4.1.1.1. Risk Management must provide value.
7.4.2. Integrate IT risk management into Enterprise Risk Management (ERM).
7.4.2.1. Why
7.4.2.1.1. Risk Management must be part of overall enterprise Governance.
7.4.3. Balance the costs and benefits of managing risk.
7.4.3.1. Why
7.4.3.1.1. Risk Management costs must be lower than value (monetary and monetary) of assets under protection.
7.4.4. Promote fair and open communication.
7.4.4.1. Why
7.4.4.1.1. Risk Management must promote and communicate Risk-aware culture.
7.4.5. Establish tone at the top and assign personal accountability.
7.4.5.1. Why
7.4.5.1.1. Risk Management must have defined clear roles and responsibilites in order to be effective.
7.4.6. Daily process with continuous improvement.
7.4.6.1. Why
7.4.6.1.1. Risk changes and environment changes (Internal and External), so Risk Management practices must be adapt.
7.4.6.1.2. Risk management should use historical data and facilitates learning and continual improvement.
7.5. Risk Evaluation Process
7.5.1. Process of comparing the estimated risk against given risk criteria to determine the significance of the risk.
7.6. Risk Assessment Process
7.6.1. Process used to identify and evaluate risk and its potential effects.
7.6.2. Elements of Risk Assessment
7.6.2.1. Scope
7.6.2.2. Description of Assessment Area
7.6.2.2.1. Assets
7.6.2.2.2. System
7.6.2.2.3. Region
7.6.2.2.4. Processes
7.6.2.2.5. ...
7.6.2.3. Threats
7.6.2.4. Vulnerabilities
7.6.2.5. Likelihood
7.6.2.6. Impact
7.6.2.7. Risk Assessment Report
7.7. Risk Identification Process
7.7.1. Process of determining the risk that an enterprise / organization faces (globally or in specific organization activity: programme, project).
7.8. The Business Impact of IT Risk
7.8.1. Loss of revenue.
7.8.2. Loss of sensitive information and data.
7.8.3. Loss of reputation / brand visibility / brand image.
7.8.4. Loss of public confidence.
7.8.5. Loss of SLAs / OLAs levels.
7.8.6. LOE to correct problems caused by Threat Actions.
7.8.7. Loss of credibility.
7.8.8. Damage to enterprise’s interest.
7.8.9. System repair costs.
7.9. Applicable Guidelines for Risk Appetite and Risk Tolerance
7.9.1. Connectivity of risk appetite and risk tolerance.
7.9.2. Review and approval of exceptions to risk tolerance standards.
7.9.3. Risk appetite and tolerance change over time.
7.9.4. Cost of risk mitigation options can affect risk tolerance.
7.9.5. Risk Capacity
7.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.
7.9.6. Risk Tolerance
7.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)
7.9.7. Risk Appetite
7.9.7.1. The amount of risk the organisation, or subset of it, is willing to accept
7.10. Risk Hierarchy - 4 Levels of Risk
7.10.1. Portfolio risk
7.10.1.1. goal
7.10.1.1.1. Management of stakeholder perceptions that would affect the reputation of an organization.
7.10.1.1.2. Ensuring business success of the organization.
7.10.1.2. context
7.10.1.2.1. business success
7.10.1.2.2. business vitality
7.10.1.2.3. finance
7.10.1.2.4. core services
7.10.1.2.5. organization / enterprise capabilities
7.10.1.2.6. resources
7.10.1.2.7. portfolio management
7.10.2. Program risk
7.10.2.1. goal
7.10.2.1.1. Delivering business change with measurable benefits.
7.10.2.1.2. Delivering business transformation.
7.10.2.1.3. Delivering outcomes.
7.10.2.2. context
7.10.2.2.1. benefits
7.10.2.2.2. capabilities
7.10.2.2.3. programme management
7.10.3. Project risk
7.10.3.1. goal
7.10.3.1.1. Producing defined business change products within time, cost and scope constraints.
7.10.3.1.2. Delivering outputs.
7.10.3.2. context (6 project parameters)
7.10.3.2.1. time
7.10.3.2.2. budget
7.10.3.2.3. benefits
7.10.3.2.4. quality
7.10.3.2.5. scope
7.10.3.2.6. risk
7.10.3.3. context
7.10.3.3.1. project management
7.10.4. Operational risk
7.10.4.1. goal
7.10.4.1.1. Maintaining business services to appropriate levels.
7.10.4.1.2. Day-to-day management.
7.10.4.1.3. Business as Usual (BaU).
7.10.4.2. context
7.10.4.2.1. reputation
7.10.4.2.2. volume
7.10.4.2.3. quality
7.10.4.2.4. internal control
7.10.4.2.5. revenue
7.10.4.2.6. staff
7.10.4.2.7. customer
7.11. IT Risk in the Risk Hierarchy (from ISACA® Risk IT™ perspective)
7.11.1. Strategic Risk
7.11.2. Environment Risk
7.11.3. Market Risk
7.11.4. Credit Risk
7.11.5. Operational Risk
7.11.6. Compliance Risk
7.11.7. IT-related Risk
7.12. Three IT Risk Categories (from ISACA® Risk IT™ perspective)
7.12.1. IT Benefit / Value Enablement
7.12.1.1. e.g.
7.12.1.1.1. Technology enabler for new business initiatives.
7.12.1.1.2. Technology enabler for efficient operations.
7.12.1.1.3. Technology enabler for higher SLAs / OLAs levels.
7.12.2. IT Programme and Project Delivery
7.12.2.1. e.g.
7.12.2.1.1. Project relevance / priority.
7.12.2.1.2. Project time / budget overrun.
7.12.2.1.3. Project quality.
7.12.3. IT Operations and Service Delivery
7.12.3.1. e.g.
7.12.3.1.1. IT service interruptions (SLAs / OLAs crisis).
7.12.3.1.2. Security issues.
7.12.3.1.3. Compliance / regulatory issues.
7.13. Risk Scenario
7.13.1. What
7.13.1.1. Risk Scenario is a description of an event that can lead to a business impact, when and if it should occur.
7.13.1.2. Risk Scenario is a technique used to make risk more concrete and tangible and allow for proper risk assessment and analysis.
7.13.2. Why (Purpose of Risk Scenario)
7.13.2.1. Bring realism.
7.13.2.2. Provide insight.
7.13.2.3. Facilitate organizational engagement.
7.13.2.4. Provide improved analysis and structure to the complex nature of enterprise risk.
7.13.3. Risk Scenario components
7.13.3.1. Actor / Threat Actor / Source
7.13.3.1.1. What
7.13.3.1.2. Internal (to the organization)
7.13.3.1.3. External (to the organization)
7.13.3.1.4. Threat Actors can be also human or nonhuman.
7.13.3.1.5. In 2008, CSO Magazine reported
7.13.3.1.6. In 2009, Verizon Data Breach Investigation Report
7.13.3.2. Threat Type
7.13.3.2.1. What
7.13.3.2.2. e.g.
7.13.3.3. Event
7.13.3.3.1. Loss Events
7.13.3.3.2. Vulnerability Events (or vulnerabilities / weaknesses)
7.13.3.3.3. Threat Events
7.13.3.3.4. e.g.
7.13.3.4. Asset / Resource
7.13.3.4.1. What
7.13.3.4.2. Tangible
7.13.3.4.3. Intangible
7.13.3.5. Time / Timing Dimension
7.13.3.5.1. What
7.13.3.5.2. e.g.
7.13.4. Risk Scenario development strategies
7.13.4.1. Top-down approach.
7.13.4.2. Bottom-up approach.
7.13.4.3. Approaches are complementary and should be used simultaneously.
7.13.5. Risk Scenario development process
7.13.5.1. 1. Use list of example generic scenarios to define a manageable set of concrete scenarios for the enterprise.
7.13.5.2. 2. Perform a validation against business objectives of the entity.
7.13.5.3. 3. Refine the selected scenarios and detail them in line with criticality to entity.
7.13.5.4. 4. Reduce number of scenarios to manageable set.
7.13.5.5. 5. Keep all risks in a Risk Register for easy re-evaluation.
7.13.5.6. 6. Include in scenarios how to handle unspecified events.
7.13.6. Risk Scenario development enablers
7.13.6.1. Organizational Buy-in.
7.13.6.2. Risk Culture.
7.13.6.2.1. What
7.13.6.2.2. Often one of the most if not the most important enabler!
7.13.6.2.3. Begins at the top (board / executive / CEO):
7.13.6.2.4. Symptoms of inadequate or problematic risk culture include
7.13.6.3. Skilled scenario facilitation / identification.
7.13.6.4. Thorough understanding of environment (internal and external).
7.13.6.5. Involvement of all stakeholders (especially decision-makers).
7.14. Risk Factors
7.14.1. What is it?
7.14.1.1. A features that influences the likelihood and or business impact of risk scenarios.
7.14.1.2. A condition that can influence the frequency and/or magnitude and, ultimately, the business impact of IT-related events/scenarios.
7.14.2. 5 Risk Factors categories
7.14.2.1. External Environmental
7.14.2.1.1. What is it?
7.14.2.1.2. e.g.
7.14.2.1.3. Not always controllable by the enterprise / organisation.
7.14.2.2. Internal Environmental
7.14.2.2.1. What is it?
7.14.2.2.2. e.g.
7.14.2.3. Capabilities
7.14.2.3.1. Risk Management Capability
7.14.2.3.2. IT Capability
7.14.2.3.3. IT Related Business Capability
7.15. Risk Analysis Process
7.15.1. What is it?
7.15.1.1. Process of integrating risk assessments at a corporate level to obtain a complete view of the overall risk for the enterprise.
7.15.2. Risk Analysis determines
7.15.2.1. Extent of potential threat.
7.15.2.2. Risks associated with IT systems throughout SDLC.
7.16. Risk Analysis methods
7.16.1. Risk Analysis methods / techniques categories:
7.16.1.1. Qualitative Analysis
7.16.1.1.1. What
7.16.1.1.2. Qualitative Risk Analysis methods (non-exhaustive list)
7.16.1.1.3. Advantages
7.16.1.1.4. Disadvantages
7.16.1.2. Quantitative Analysis
7.16.1.2.1. What
7.16.1.2.2. Quantitative Risk Analysis methods (non-exhaustive list)
7.16.1.2.3. Advantages
7.16.1.2.4. Disadvantages
7.17. Identifying and assessing IT Risk
7.17.1. Threats and Opportunities inherent in enterprise use of IT.
7.17.2. Clarity in defining business impact (+/-) of IT related risks is critical to understanding threats, vulnerabilities, and opportunities.
7.18. Adverse Impact of Risk Event
7.18.1. Loss of degradation of any or a combination of the 3 basic risk goals of CIA:
7.18.1.1. Integrity
7.18.1.1.1. Accuracy & completeness of processing of transaction.
7.18.1.1.2. Reliability of information processing activities.
7.18.1.1.3. Accuracy and completeness and security of the output.
7.18.1.1.4. Data cannot be modified undetectably.
7.18.1.1.5. Data entered into a database are accurate, valid and consistent.
7.18.1.1.6. Alteration
7.18.1.2. Availability
7.18.1.2.1. Mission critical system is unavailable for end users.
7.18.1.2.2. Loss of system functionality.
7.18.1.2.3. Destruction
7.18.1.3. Confidentiality
7.18.1.3.1. Disclosure
7.19. Business Impact Analysis / Assessment (BIA)
7.19.1. What is it?
7.19.1.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.
7.19.2. Why
7.19.2.1. Establishes the escalation of that loss overtime.
7.19.2.2. Is a discovery process to uncover the inter workings of a given process.
7.19.2.3. Answers the questions about procedures, shortcuts, workarounds, and possible failures.
7.19.2.4. Uses the same qualitative and quantitative techniques.
7.19.3. BIA discovery techniques (non-exhaustive list)
7.19.3.1. Questionnaires.
7.19.3.2. Interviews.
7.19.3.3. Documentation review.
7.19.3.4. Process observation.
7.19.3.5. Personnel observation during work.
7.19.3.6. ID vital material and records (Information asset inventory).
7.19.3.7. Detect existing workarounds and alternate procedures.
7.19.3.8. Verify critical business functions.
7.19.3.9. OBASHI® methodology.
7.19.3.9.1. see OBASHI® mind map
7.20. Ways of describing IT Risk in business terms (methods, frameworks, standards) (from ISACA® Risk IT™ perspective)
7.20.1. Extended Information Criteria (COBIT®)
7.20.1.1. What is it?
7.20.1.1.1. To satisfy business objectives, information needs to conform to certain control criteria, which COBIT refers to as business requirements for information.
7.20.1.1.2. Based on broader quality, fiduciary, and security requirements, 7 distinct information criteria are defined.
7.20.1.2. The COBIT® Framework identifies which of the 7 information criteria:
7.20.1.2.1. Effectiveness
7.20.1.2.2. Efficiency
7.20.1.2.3. Confidentiality
7.20.1.2.4. Integrity
7.20.1.2.5. Availability
7.20.1.2.6. Compliance
7.20.1.2.7. Reliability
7.20.1.3. see COBIT® 5 mind map
7.20.2. Balanced Scorecard (BSC)
7.20.2.1. What is it?
7.20.2.1.1. Strategic management system that helps organization translates its strategies into objectives that drive both behaviour and performance. Both financial and non-financial.
7.20.2.1.2. Measures are designed to track the progress of objectives against targets.
7.20.2.2. Financial
7.20.2.2.1. Share value, profit, revenue, cost of capital, debt, ROA, cash flow.
7.20.2.3. Customer
7.20.2.3.1. Market share, customer satisfaction, customer service, number of contracts, KYC, customer due diligence, number of claims.
7.20.2.4. Internal
7.20.2.4.1. Regulatory compliance, number of incidents, centralized data, process optimization.
7.20.2.5. Growth
7.20.2.5.1. Competitive advantage, reputation.
7.20.2.6. Further reading
7.20.2.6.1. http://www.mindtools.com/pages/article/newLDR_85.htm
7.20.3. Extended Balanced Scorecard (EBSC)
7.20.3.1. What
7.20.3.1.1. A variant of BSC approach, linking BSC dimensions to a limited set of more tangible criteria.
7.20.3.2. Financial
7.20.3.2.1. Share value
7.20.3.2.2. Profit
7.20.3.2.3. Revenue
7.20.3.2.4. Cost of capital
7.20.3.2.5. debt
7.20.3.2.6. ROA
7.20.3.2.7. Cash flow
7.20.3.3. Customer
7.20.3.3.1. Market share
7.20.3.3.2. customer satisfaction
7.20.3.3.3. customer service
7.20.3.3.4. number of contracts
7.20.3.3.5. KYC
7.20.3.3.6. Customer due diligence
7.20.3.3.7. number of claims
7.20.3.4. Internal
7.20.3.4.1. Regulatory compliance
7.20.3.4.2. number of incidents
7.20.3.4.3. centralized data
7.20.3.4.4. process optimization
7.20.3.5. Growth
7.20.3.5.1. Competitive advantage
7.20.3.5.2. Reputation
7.20.4. dr. Westerman 4 A’s
7.20.4.1. What is it?
7.20.4.1.1. Key area of focus presented by Dr Westerman
7.20.4.1.2. aka. The Four As Framework
7.20.4.2. Why
7.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.
7.20.4.3. Agility
7.20.4.3.1. To be able to change with business with appropriate cost and speed.
7.20.4.4. Accuracy
7.20.4.4.1. To provide correct information on time and complete.
7.20.4.5. Access
7.20.4.5.1. To ensure right people access data and systems when they need.
7.20.4.6. Availability
7.20.4.6.1. To keep systems (and business processes) running and recoverable.
7.20.5. Factor Analysis of Information Risk (FAIR)
7.20.5.1. What is it?
7.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.
7.20.5.2. The Open Group has adopted FAIR as a key component in its approach to risk management.
7.20.5.3. The "Build Security In" initiative of Homeland Security Department of USA, cites FAIR.
7.20.5.4. By FAIR the risk is the probability of a loss tied to an asset.
7.20.5.5. FAIR defines 6 kind of loss:
7.20.5.5.1. 1. Productivity
7.20.5.5.2. 2. Response
7.20.5.5.3. 3. Replacement
7.20.5.5.4. 4. Fines and judgements (F/J)
7.20.5.5.5. 5. Competitive advantage (CA)
7.20.5.5.6. 6. Reputation
7.20.5.6. FAIR defines Value / Liability as:
7.20.5.6.1. Criticality
7.20.5.6.2. Cost
7.20.5.6.3. Sensitivity
7.20.5.7. FAIR defines Threat as:
7.20.6. COSO® Enterprise Risk Management - Integrated Framework (ERM)
7.20.6.1. What is it?
7.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.
7.20.6.2. 4 Objectives categories (vertical columns)
7.20.6.2.1. Strategic
7.20.6.2.2. Operations
7.20.6.2.3. Reporting
7.20.6.2.4. Reporting
7.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.
7.20.6.3. 8 Components (horizontal rows)
7.20.6.3.1. Internal Environment
7.20.6.3.2. Objective Setting
7.20.6.3.3. Event Identification
7.20.6.3.4. Risk Assessment
7.20.6.3.5. Risk Response
7.20.6.3.6. Control Activities
7.20.6.3.7. Information and Communication
7.20.6.3.8. Monitoring
7.20.6.4. The entity and its organizational units are depicted by the third dimension of the matrix.
7.20.6.5. Each component row “cuts across'' and applies to all four objectives categories.
7.20.6.6. see COSO ERM-IF mind map
8. Domain 2 - Risk Response
8.1. Domain 2 - CRISC™ Exam Relevance
8.1.1. The content area for Domain 2 will represent ...
8.1.1.1. 17% of the CRISC examination
8.1.1.2. 34 questions
8.2. Risk Response Process
8.2.1. What is it?
8.2.1.1. Process of addressing the risks identified during risk assessment.
8.2.1.1.1. Cost benefit analysis.
8.2.1.1.2. Reduce risk to acceptable levels.
8.2.1.1.3. Combination of types of controls.
8.2.1.2. Triggered when a risk exceeds an organizations acceptance level.
8.2.1.3. Driven by input from the risk assessment process.
8.2.2. Why
8.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.
8.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.
8.2.2.2.1. In other words: does asset value still overweight risk response costs including monetary and non-monetary costs.
8.3. High level Risk Response Process
8.3.1. 1. Review risk analysis results.
8.3.2. 2. Select response options.
8.3.3. 3. Prioritize options.
8.3.4. 4. Implement risk action plan.
8.3.5. http://www.isaca.org/Journal/Past-Issues/2011/Volume-2/PublishingImages/11v2-it-scenario1.jpg
8.4. Risk Response Process phases & tasks.
8.4.1. Phase 1 - Articulate Risk
8.4.1.1. Task 1 - Communicate Risk Analysis results.
8.4.1.1.1. Report results.
8.4.1.1.2. Coordinate additional RA activities.
8.4.1.1.3. Communicate risk return.
8.4.1.1.4. Identify negative and positive impacts.
8.4.1.1.5. Provide decisions makers summary of exposures, scenarios, and key considerations.
8.4.1.2. Task 2 - Report Risk Management activities.
8.4.1.2.1. Meet risk reporting needs.
8.4.1.2.2. Ensure Reporting on Issues and Status is appropriate.
8.4.1.2.3. Include all pertinent activities in reporting.
8.4.1.2.4. Provide inputs to integrated enterprise reporting.
8.4.1.3. Task 3 - Interpret Risk Assessment findings.
8.4.1.3.1. Review results and findings from various sources.
8.4.1.3.2. Map results to risk profile and control baseline.
8.4.1.3.3. Consider established risk tolerance.
8.4.1.3.4. Communicate gaps and exposure to business.
8.4.1.3.5. Help business understand how corrective action plans affect risk profile.
8.4.1.3.6. Identify integration opportunities.
8.4.1.4. Task 4 - Identify business opportunities.
8.4.1.4.1. Recurring risk analysis.
8.4.1.4.2. Identify IT related capacity parity.
8.4.1.4.3. Look for opportunities to use IT (technology).
8.4.2. Phase 2 - Manage Risk
8.4.2.1. Task 1 - Inventory controls.
8.4.2.1.1. Inventory controls in place.
8.4.2.1.2. Classify and map controls.
8.4.2.1.3. Develop control tests.
8.4.2.1.4. Identify procedures and technology.
8.4.2.1.5. Partition operational controls.
8.4.2.2. Task 2 - Monitor operational alignment.
8.4.2.2.1. Ensure business line accountability.
8.4.2.2.2. Test key risk issues.
8.4.2.2.3. Obtain Buy-in by management on KRI.
8.4.2.2.4. Ensure KRI’s are implemented with thresholds, checkpoint and automated communications.
8.4.2.2.5. Integrate KRI data into performance indicator reporting.
8.4.2.2.6. Ensure risk analysis is performed when residual risk is outside tolerance.
8.4.2.3. Task 3 - Respond to discovered risk exposures and opportunities.
8.4.2.3.1. Emphasize projects that are expected to reduce adverse events and balance against strategic opportunities.
8.4.2.3.2. Hold cost benefit discussion.
8.4.2.3.3. Select candidate controls.
8.4.2.3.4. Monitoring changes in business operational risk profiles.
8.4.2.3.5. Adjust the rankings of risk response projects.
8.4.2.4. Task 4 - Implement Controls.
8.4.2.4.1. Ensure effective deployment / adjustment of controls.
8.4.2.4.2. Communicate with key stakeholders.
8.4.2.4.3. Test controls.
8.4.2.4.4. Map controls to monitoring mechanisms.
8.4.2.4.5. Identify and train staff on new procedures.
8.4.2.5. Task 5 - Report IT risk response plan progress.
8.4.2.5.1. Monitor risk response plans (all levels).
8.4.2.5.2. Ensure effectiveness of responses.
8.4.2.5.3. Determine whether acceptance of residual risk has been obtained.
8.4.2.5.4. Ensure committed risk responses are owned and deviations are reported to senior management.
8.4.3. Phase 3 - React To Risk Events
8.4.3.1. Task 1 - Maintain incident response plans.
8.4.3.1.1. Prepare for materialization of threats.
8.4.3.1.2. Maintain open communication about risks.
8.4.3.1.3. Build RTO into action plans.
8.4.3.1.4. Define pathways of escalation.
8.4.3.1.5. Verify incident response plans are adequate.
8.4.3.2. Task 2 - Monitor risk.
8.4.3.2.1. Monitor the environment.
8.4.3.2.2. When control limit breached; escalate or confirm.
8.4.3.2.3. Categorize incidents.
8.4.3.2.4. Communicate business impact.
8.4.3.2.5. Continue to take action and drive desired outcome.
8.4.3.2.6. Ensure policy is followed with clear accountability for follow-up actions.
8.4.3.3. Task 3 - Initiate incident response.
8.4.3.3.1. Take action to minimize in-progress incident impact.
8.4.3.3.2. Identify impact category.
8.4.3.3.3. Inform stakeholders of incident.
8.4.3.3.4. Identify time requirements to carry out plan.
8.4.3.3.5. Ensure correct action is taken.
8.4.3.4. Task 4 - Communicate lessons learned from risk events.
8.4.3.4.1. Examine past events and missed opportunities.
8.4.3.4.2. Determine where failure stemmed from.
8.4.3.4.3. Research root cause.
8.4.3.4.4. Determine underlying problem.
8.4.3.4.5. Identify tactical corrections.
8.4.3.4.6. Identify and correct underlying root causes.
8.4.3.4.7. Identify root cause of incidents.
8.4.3.4.8. Request additional risk analysis as needed.
8.4.3.4.9. Communicate root cause, response requirements, process improvements.
8.5. Risk Response Options
8.5.1. for Threats
8.5.1.1. Avoid
8.5.1.1.1. 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
8.5.1.1.2. avoiding all risks is not a viable strategy
8.5.1.1.3. outcome = risk probability of occurrence is 0%
8.5.1.1.4. it simply means to conduct activity where the risk is not met
8.5.1.2. Reduce
8.5.1.2.1. reduce probability (a.k.a. Prevent)
8.5.1.2.2. reduce impact (a.k.a. Mitigate)
8.5.1.2.3. reduce probability & impact simultaneously
8.5.2. for Opportunities
8.5.2.1. Exploit
8.5.2.1.1. exploiting the opportunity aims to make the most of an opportunity that arises to make the probability of its outcome to be 100%.
8.5.2.1.2. it uses extensive measures to ensure that the opportunity becomes a certainty.
8.5.2.1.3. outcome = risk probability of occurrence is 100%
8.5.2.2. Enhance (a.k.a. Improve)
8.5.2.2.1. control methods put in place to increase the likelihood or increase the impact of the opportunity.
8.5.2.2.2. enhancement methods are not as extensive as exploit controls because they do not aim at making the opportunity a certainty.
8.5.2.2.3. increse probability (but still <100%)
8.5.2.2.4. increse impact
8.5.2.2.5. increse probability & impact simultaneously
8.5.3. for Threats & Opportunities
8.5.3.1. Transfer
8.5.3.1.1. by transferring risk firms remove their own responsibility for dealing with risk events to someone outside of the organisation / programme / project etc.
8.5.3.1.2. (for opportunity) it aims to transfer the opportunity to a more specialised organisation that will help maximise its effects.
8.5.3.1.3. you cannot transfer accountability, only risk impact
8.5.3.1.4. as name suggest 2nd party is needed for transfer
8.5.3.1.5. transfer means transfering all (100%) impact to 2nd party
8.5.3.2. Share
8.5.3.2.1. as name suggest 2nd party is needed for sharing
8.5.3.2.2. sharing means sharing at least small percentage of impact with 2nd party
8.5.3.3. Accept
8.5.3.3.1. accepting an opportunity basically leaves everything to chance
8.5.3.3.2. Passive Acceptance
8.5.3.3.3. Active Acceptance
8.5.3.4. Prepare Contingent Plans
8.5.3.4.1. only reduces impact
8.5.3.4.2. does not changes probability
8.6. Risk Response Process parameters
8.6.1. Cost of Response to Reduce Risk Within Tolerance Levels.
8.6.2. Importance of Risk.
8.6.3. Capability to Implement Risk Response.
8.6.4. Effectiveness of Response.
8.6.5. Efficiency of Response.
8.7. Risk Response Prioritization
8.7.1. Quick win.
8.7.2. Business case to be made.
8.7.3. Deferral.
8.8. Risk Response Prioritization Options
8.9. Risk Response Prioritization Factors
8.9.1. Stakeholder interests / perception
8.9.2. Acceptance of change.
8.9.3. Solution balance.
8.9.4. Cost.
8.9.4.1. Including monetary and non-monetary costs (e.g. time, scope)
8.9.5. Productivity impact (impact on BaU).
8.9.6. Control ownership.
8.9.7. Ability to monitor, audit and control.
8.9.8. Regulations.
8.9.9. Market condition changes.
8.9.10. Ability to execute.
8.9.11. Ability to rollback (if needed).
8.10. Risk Mitigation Control Types
8.10.1. Managerial.
8.10.2. Technical.
8.10.3. Operational.
8.10.4. Preparedness activities.
8.11. Risk Response programs
8.11.1. Prioritize Risk Response programs according to risk levels:
8.11.1.1. Look for quick wins.
8.11.1.2. Search by experience and known situations.
8.11.2. Update Risk Register.
8.11.3. Ensure that controls are designed and implemented correctly:
8.11.3.1. A control poses a new risk to the organization.
9. Domain 3 - Risk Monitoring
9.1. Domain 3 - CRISC™ Exam Relevance
9.1.1. The content area for Domain 3 will represent ...
9.1.1.1. 17% of the CRISC examination
9.1.1.2. 34 questions
9.2. Risk Monitoring Process
9.2.1. What is it?
9.2.1.1. Process accomplished by selecting KRIs from all the controls and data points available.
9.2.1.2. Periodically re-evaluate risk levels.
9.2.2. Select which controls will be used as Key Risk Indicators (KRIs):
9.2.2.1. Controls that indicate important risk issues or risk trends.
9.2.2.2. Monitored on a regular basis to allow results to be compared over time.
9.2.2.3. Reflect business priorities.
9.3. Risk Indicators
9.3.1. What is it?
9.3.1.1. Metrics used to indicate risk thresholds and when a risk level may be approaching a high or unacceptable level of risk.
9.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.
9.3.2. Why
9.3.2.1. Set in place tracking and reporting mechanisms that alert staff to a developing or potential risk.
9.3.3. Risk indicators are placed at control points positioned to gather data used to:
9.3.3.1. Gauge risk levels at a point in time.
9.3.3.2. Track events and incidents.
9.3.3.3. That may indicate a potential hazardous situation.
9.4. Key Performance Indicators (KPIs)
9.4.1. Requirements that a KPI must satisfy:
9.4.1.1. Contribution to CSFs
9.4.1.1.1. The connection between the KPI and the CSF above must be demonstrable and described.
9.4.1.2. Stakeholders
9.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.
9.4.1.3. Relevance
9.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.
9.4.1.4. Ownership
9.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.
9.4.1.5. Recognizable
9.4.1.5.1. KPIs are recognizable for employees.
9.4.1.6. Repeatable
9.4.1.6.1. The KPI must be able to be established regularly and in the same way.
9.4.1.7. Traceable
9.4.1.7.1. The way in which the result of the KPI was achieved must be described.
9.4.1.8. Uniformity of processes
9.4.1.8.1. The KPIs must result from processes that are interpreted and implemented in a uniform way by all stakeholders.
9.4.1.9. Standard
9.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.
9.4.1.10. Costs vs benefits
9.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.
9.4.1.11. SMART
9.4.1.11.1. The KPI must be Specific, Measurable, Acceptable (for all stakeholders), Realistic, and Time-dependent.
9.4.1.12. The I in KPI stands for indicator
9.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
9.5. Key Risk Indicators (KRIs)
9.5.1. KRIs are like signals / triggers:
9.5.1.1. Indicate warning thresholds.
9.5.1.2. Allow tracking and reporting.
9.5.1.3. Highlight trends in developing or potential risk.
9.5.2. KRIs are like Early Warning Indicator (EWIs). The difference is that KRIs are dedicated to risks.
9.5.3. KRIs are subset of Risk Indicators (RI).
9.5.4. Types
9.5.4.1. Logs.
9.5.4.2. Alarms.
9.5.4.3. Reports.
9.5.4.4. Calls.
9.5.4.5. Events.
9.5.4.6. Incidents.
9.5.4.7. ...
9.5.5. Parameters
9.5.5.1. Size and complexity of enterprise.
9.5.5.2. Business vision / mission stability.
9.5.5.3. Type of market in which the enterprise operates.
9.5.5.4. Strategy focus of the enterprise.
9.5.6. Factors
9.5.6.1. Create ownership of Risk Indicators
9.5.6.1.1. Involve stakeholders to obtain buy-in.
9.5.6.1.2. Include all stakeholders, operational and strategic.
9.5.6.2. Balanced selection of risk indicators
9.5.6.2.1. Lag (detective).
9.5.6.2.2. Lead (preventative).
9.5.6.2.3. Trend (indicator correlation / risk).
9.5.6.3. Ensure Indicators reflect Root Cause. Map unique root cause to single or specific of indicators to avoid false conclusions.
9.5.7. Criteria for KRI selection
9.5.7.1. Impact:
9.5.7.1.1. Controls covering high impact risks.
9.5.7.2. Effort:
9.5.7.2.1. Controls that are easy to monitor.
9.5.7.3. Reliability:
9.5.7.3.1. Close relationship between the risk and the control.
9.5.7.4. Sensitivity:
9.5.7.4.1. Accurately reflect changes in risk.
9.5.7.5. Repeatability:
9.5.7.5.1. Is repeatable so it can be measured in regular basis.
9.5.8. Benefits of selecting right KRIs
9.5.8.1. Forecast developing risks (forecasts / forward-looking):
9.5.8.1.1. Trends/preventative.
9.5.8.2. Post-incident review (backward-looking):
9.5.8.2.1. Analysis and lessons learned.
9.5.8.2.2. Better future risk response.
9.5.8.3. Document trends:
9.5.8.3.1. Watch developing risks over time.
9.5.8.4. Measure risk appetite and tolerance:
9.5.8.4.1. Compliance.
9.5.8.5. Increase likelihood of meeting strategic objectives.
9.5.8.6. Assist in optimizing risk governance and risk management environment.
9.5.9. Disadvantages of wrong KRIs
9.5.9.1. No linkage from KRI to specific risk.
9.5.9.1.1. Useless.
9.5.9.2. Unclear or incomplete KRIs:
9.5.9.2.1. Not industry or market specific.
9.5.9.2.2. Too generic, to organization / department / project specific.
9.5.9.3. Too many KRIs:
9.5.9.3.1. Meaningless.
9.5.9.4. Difficult to measure:
9.5.9.4.1. Hard to compare, interpret, or aggregate.
9.5.10. Changing KRIs / KRIs Maintenance
9.5.10.1. Risk changes - so should KRIs:
9.5.10.1.1. Different trigger levels.
9.5.10.2. 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.
9.5.11. Optimizing KRIs
9.5.11.1. Sensitivity:
9.5.11.1.1. Collecting too much data.
9.5.11.1.2. Solution: Only collect critical level data.
9.5.11.2. Timing:
9.5.11.2.1. Data collected too late to take corrective action.
9.5.11.2.2. Solution: Collect abnormalities in a timely manner.
9.5.11.3. Frequency:
9.5.11.3.1. Data collected daily but reported monthly.
9.5.11.3.2. Solution: set sample rate.
9.5.11.4. Corrective action gaps:
9.5.11.4.1. Reports do not indicate priority corrective action underway.
9.5.11.4.2. Solution: project management tools, assign owners of risk.
9.6. Gathering KRI information / data
9.6.1. KRIs rely on information / data from diverse sources.
9.6.2. Steps to Data Gathering
9.6.2.1. Gathering requirements
9.6.2.1.1. Requires input from
9.6.2.2. Information / Data access
9.6.2.2.1. Direct data access
9.6.2.2.2. Receipt of data extracts
9.6.2.3. Information / Data validation
9.6.2.3.1. Information / Data prepared for analysis:
9.6.2.3.2. Information / Data validating considerations:
9.6.2.4. Information / Data analysis
9.6.2.4.1. Ensure that information / data analysis supports the review objective:
9.6.2.4.2. Analysis should be repeatable:
9.6.2.5. Reporting & corrective action
9.6.2.5.1. Reports generated and sent:
9.7. Maturity Level Assessment
9.7.1. Use of Maturity Level Assessment
9.7.1.1. Determine maturity level of several key factors.
9.7.1.2. Provides gap analysis between current and desired state.
9.7.1.3. Supports projects to address processes at unacceptable maturity level.
9.7.1.4. Maturity Models are well known concept not only in IT or Risk Management domain.
9.7.2. Assessing Risk Maturity Levels
9.7.2.1. Boards need accurate reporting on maturity of risk management efforts:
9.7.2.1.1. Ensure risk is managed enterprise-wide.
9.7.2.1.2. Correct priorities.
9.7.2.1.3. Activities necessary to develop greater maturity.
9.7.2.2. Maturity levels are assessed from unpredictable, uncontrolled processes, to levels of consistency and continuous improvement.
9.7.3. Levels
9.7.3.1. Level 0 - Non-existent:
9.7.3.1.1. Management processes are not applied at all.
9.7.3.2. Level 1 - Initial / Ad hoc:
9.7.3.2.1. Processes are ad hoc and disorganized.
9.7.3.3. Level 2 - Repeatable But Intuitive:
9.7.3.3.1. Processes follow regular pattern.
9.7.3.4. Level 3 - Defined Process:
9.7.3.4.1. Processes are documented and communicated.
9.7.3.5. Level 4 - Managed and Measureable:
9.7.3.5.1. Processes are monitored and measured.
9.7.3.6. Level 5 - Optimised:
9.7.3.6.1. Good practices are followed and automated.
9.7.4. see Maturity Models mind map
9.8. Changing Threat Levels
9.8.1. Market conditions.
9.8.2. New technology.
9.8.3. Aging technology.
9.8.4. Staff experience levels (aka. capabilities).
9.8.5. Regulations and legislation (aka. constraints).
9.8.6. Attackers skill level.
9.8.7. New connections to global systems.
9.8.8. Measuring Changes in Threat Levels
9.8.8.1. Open new vulnerabilities.
9.8.8.2. Bypass or remove existing controls.
9.8.8.3. Adversely affect potential business levels.
9.8.9. Responding to Changes in Threat Levels
9.8.9.1. Changes in threat levels may mandate changes in:
9.8.9.1.1. Network infrastructure.
9.8.9.1.2. Policies.
9.8.9.1.3. Procedures.
9.8.9.1.4. Threat-specific countermeasures.
9.8.9.1.5. Compensating controls.
9.8.10. Threat Level Review
9.8.10.1. The threat level (aka. Risk Profile) for the organization must be checked at least:
9.8.10.1.1. Annually.
9.8.10.1.2. Whenever there is a major change to the system.
9.8.10.1.3. Following any major incident.
9.8.10.2. The risk may be checked as a specific periodic review or in an incremental manner:
9.8.10.2.1. Regulation.
9.8.10.2.2. PCI-DSS requirements.
9.8.10.2.3. ISO 27001 requirements.
9.9. Changes in Asset Value
9.9.1. Changes in asset value will have a direct impact on risk levels:
9.9.1.1. End of life for a product or service.
9.9.1.2. Rapidly growing new product or service.
9.9.1.3. Size of stored customer data.
9.10. Risk Reporting
9.10.1. Types of risk communication reporting content include
9.10.1.1. Expectations from risk management:
9.10.1.1.1. Policies, strategy, procedures, awareness training etc.
9.10.1.2. Status with regard to IT risk:
9.10.1.2.1. Risk profile of enterprise, KRIs, thresholds, loss data, etc.
9.10.1.3. Current risk management capability:
9.10.1.3.1. Risk management process maturity, how well risk is manager etc.
9.10.1.4. Actionable Items.
9.10.2. Effective Report Writing Skills
9.10.2.1. Report writing can be described as a career skill.
9.10.2.2. 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.
9.10.2.3. Today, good communication skills and the ability to write effective reports are essential competencies in the workplace.
9.10.2.4. Style is the most nebulous area of report writing.
9.10.2.5. It is very easy to criticise a writer’s style as ‘poor’ or ‘inappropriate’.
9.10.2.6. What is not so easy is to specify the stylistic improvements that should be encouraged.
9.10.3. Good vs. Poor Communication
9.10.3.1. Benefits of good communication include:
9.10.3.1.1. Contributing to managements understanding of exposures.
9.10.3.1.2. Awareness.
9.10.3.1.3. Transparency to external stakeholders.
9.10.3.2. Consequences of poor communication include:
9.10.3.2.1. Perception that the enterprise lacks transparency with external stakeholders.
9.10.3.2.2. Incorrect perception by external stakeholders.
9.10.3.2.3. False sense of confidence relating to exposure.
9.10.4. Effective reports
9.10.4.1. Clear:
9.10.4.1.1. 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.
9.10.4.2. Concise:
9.10.4.2.1. e.g. concise document is a piece of writing that conveys only the needed material.
9.10.4.3. Coherent:
9.10.4.3.1. e.g. at the paragraph level, coherence is achieved by organizing material into a topic sentence and supporting sentences.
9.10.4.4. Useful.
9.10.4.4.1. e.g. enable decision making.
9.10.4.5. Timely.
9.10.4.6. Appropriate:
9.10.4.6.1. e.g. aimed at the correct audience based on levels of knowledge, format of report.
9.10.4.7. Available only to personnel on a ‘need-to-know’ basis.
9.10.5. Possible Risk Report recipients
9.10.5.1. Steering committee.
9.10.5.2. Senior Management Team:
9.10.5.3. CEO.
9.10.5.4. CFO.
9.10.5.5. CIO.
9.10.5.6. CRO / CIRO.
9.10.5.7. Business unit directors.
9.10.5.8. Consultants.
9.10.5.9. Security experts.
9.10.5.10. Subject domain experts.
9.10.5.11. IT Directors.
9.10.5.12. PMOs.
9.10.5.13. Compliance and Audit.
9.10.6. Reporting on Periodic Risk Assessment
9.10.6.1. On a periodic basis to steering committees and responsible managers (e.g. Project / Programme Manager) to enable timely response to emerging trends.
9.10.6.2. Indicate progress on risk mitigation activities.
9.10.7. Risk Reporting topics
9.10.7.1. Current levels of policy, culture and compliance.
9.10.7.2. Current risk status:
9.10.7.2.1. KRI thresholds.
9.10.7.2.2. Changes over past period.
9.10.7.2.3. Forecast of future risk.
9.10.7.2.4. Capability of staff to meet risk scenarios.
9.10.7.2.5. State of awareness programs.
9.10.7.3. Past incidents.
9.10.8. Risk Reporting methods (non-exhaustive list)
9.10.8.1. Face to face (F2F) meetings.
9.10.8.2. Heatmaps.
9.10.8.3. Dashboards.
9.10.8.4. Workshops.
9.10.8.5. Bubble charts.
9.10.8.6. Risk prioritisation chart.
9.10.8.7. Facilitated workshops.
9.10.8.8. Distribution lists.
9.10.8.9. Centralized web portals
9.10.8.10. PPM software.
10. Domain 4 - Information Systems Control Design and Implementation
10.1. Domain 4 - CRISC™ Exam Relevance
10.1.1. The content area for Domain 4 will represent ...
10.1.1.1. 17% of the CRISC® examination
10.1.1.2. 38 questions
10.2. Control
10.2.1. Policies, procedures, practices and guidelines designed to provide reasonable assurance that:
10.2.1.1. Business objectives are achieved.
10.2.1.2. Undesired events are prevented or detected and corrected.
10.3. Control Categories
10.3.1. Compensatory
10.3.1.1. Reduces likelihood of Attack
10.3.2. Corrective
10.3.2.1. Controls that remedy incident
10.3.2.2. Decrease Impact
10.3.3. Detective
10.3.3.1. Controls that identify incident
10.3.3.2. Reduces likelihood of Attack
10.3.4. Deterrent
10.3.4.1. Discovers Attack
10.3.4.2. Triggers Preventive Controls
10.3.5. Directive
10.3.5.1. Regulations, Policies, Standards, Guidelines, Processes & Procedures
10.3.6. Preventative
10.3.6.1. Controls that avoid incident
10.3.6.2. Protects Vulnerability
10.3.6.3. Reduces Impact
10.4. Control Types
10.4.1. Technical / Logical:
10.4.1.1. Safeguards or countermeasures built into computer equipment and software to avoid, counteract or minimize security risks relating to personal property, or any company property.
10.4.1.2. e.g.
10.4.1.2.1. ACLs
10.4.1.2.2. Antivirus software
10.4.1.2.3. firewalls
10.4.1.2.4. IPS
10.4.1.2.5. IDS
10.4.2. Nontechnical:
10.4.2.1. Management (Administrative)
10.4.2.1.1. e.g.
10.4.2.2. Operational (and Physical)
10.4.2.2.1. e.g. locks, compartmentalized areas, fences, doors, gates, extinguishers.
10.4.2.2.2. Physical Security (Facility or Infrastructure Protection)
10.4.2.2.3. Operational Security (Execution of Policies, Standards & Process, Education & Awareness)
10.4.3. according to
10.4.3.1. NIST SP800-53, Rev 3, Recommended Security Controls for Federal Information Systems
10.4.3.2. ISO/IEC 27001:2013 Information technology - Security techniques - Information security management systems - Requirements
10.5. Control Types and Effects
10.5.1. Compensating control
10.5.1.1. An internal control that reduces the risk of an existing or potential control weakness resulting in errors and omissions.
10.5.2. Impact (Business impact)
10.5.2.1. The net effect, positive or negative, on the achievement of business objectives.
10.5.3. Preventive control
10.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.
10.5.4. Threat
10.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
10.5.5. Vulnerability
10.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.
10.6. Control Strength
10.6.1. Cannot be determined by simple control category identification.
10.6.2. Can be assessed by its quantitative and qualitative compliance testing results.
10.6.3. Must be assessed within context.
10.6.4. Can be effectively assessed only by measuring against control objective.
10.6.5. Meaningful control design considerations include:
10.6.5.1. Design effectiveness.
10.6.5.2. Operating effectiveness.
10.6.5.3. Alignment with operating environment.
10.7. Control Costs and Benefits
10.7.1. Cost-benefit Analysis
10.7.1.1. Provide a monetary impact view of risk.
10.7.1.2. Determine the cost of protecting what is important.
10.7.1.3. Make good choices.
10.8. Total Cost of Ownership (TCO) for controls
10.8.1. Acquisition costs.
10.8.2. Deployment and implementation costs.
10.8.3. Recurring maintenance costs.
10.8.4. Testing and assessment costs.
10.8.5. Compliance monitoring and enforcement.
10.8.6. Inconvenience to users.
10.8.7. Reduced throughput of controlled processes.
10.8.8. Training in new procedures or technologies as applicable.
10.8.9. End of life decommissioning.
10.9. Software Development Life Cycle (SDLC) Process
10.9.1. The SDLC process governs:
10.9.1.1. The phases deployed in the development or acquisition of a software system.
10.9.1.2. Depending on the methodology, may even include the controlled retirement of the system.
10.9.2. Various types / formats of SDLC
10.9.2.1. waterfall
10.9.2.1.1. e.g.
10.9.2.2. iterative
10.9.2.2.1. e.g.
10.9.2.3. iterative & incremental & adaptive (a.k.a. true ’agile’)
10.9.2.3.1. Agile is a umbrella term enclosing different methodologies, tools, techniques, practices and frameworks
10.9.2.3.2. e.g.
10.9.2.4. Plan-Driven Projects vs. Change-driven Project Projects
10.9.3. SDLC phases (generic, not methodology specific)
10.9.3.1. 1. Feasibility study
10.9.3.1.1. Do we need this project / product? Is it aligned with our mission?
10.9.3.2. 2. Requirements study
10.9.3.2.1. What exactly do we need? Can we do it? Budget? Scope? Time?
10.9.3.3. 3. Requirements definition
10.9.3.3.1. Business analysis. Use stories. Use cases. Business process modelling.
10.9.3.4. 4. Detailed design
10.9.3.4.1. Mock-ups, Prototypes, Designs, Models, Technical Specifications.
10.9.3.5. 5. Programming
10.9.3.5.1. Coding
10.9.3.6. 6. Testing
10.9.3.7. 7. Installation
10.9.3.7.1. Up and running on production.
10.9.3.8. 8. Post-implementation review
10.9.3.9. 9. Benefits realization
10.9.4. High Level SDLC phases (from CRISC™ perspective)
10.9.4.1. 1. Project Initiation
10.9.4.1.1. Tasks
10.9.4.2. 2. Project Design and Development
10.9.4.2.1. Proposed system has:
10.9.4.2.2. Leading Principles for Design and Development
10.9.4.2.3. Project Status Reports
10.9.4.3. 3. Project Testing
10.9.4.3.1. Meets the business requirements.
10.9.4.3.2. Has appropriate controls implemented.
10.9.4.3.3. Is ready to be migrated to production.
10.9.4.4. 4. Project Implementation
10.9.4.4.1. Project Implementation planning.
10.9.4.4.2. Develop and establish technical infrastructure.
10.9.4.4.3. Roles.
10.9.4.4.4. Skills training.
10.9.4.4.5. New processes.
10.9.4.4.6. Supporting infrastructure.
10.9.4.4.7. Ensure controls operate correctly.
10.9.4.4.8. Challenges in implementation
10.9.4.4.9. Data Migration / Conversion Considerations
10.9.4.4.10. Risks During Data Migration
10.9.4.4.11. Data Conversion Project Key Considerations
10.9.4.4.12. Changeover (Go-live) Techniques (moving into production)
10.9.4.5. 5. Project Post Implementation review
10.9.4.5.1. Conducted by independent personnel.
10.9.4.5.2. Compare to initial project design and baselines.
10.9.4.5.3. Focus on control effectiveness.
10.9.4.5.4. Compare to previous audits.
10.9.4.5.5. Document findings and recommendations.
10.9.4.5.6. Does the system meet:
10.9.4.5.7. Are recommended modifications scheduled.
10.9.4.5.8. System being supported adequately.
10.9.4.5.9. Security controls working correctly.
10.9.4.5.10. Closing a Project
10.9.5. Business Risk
10.9.5.1. The risk that the system may not meet the users’ expected benefits, services or requirements
10.9.5.2. e.g.
10.9.5.2.1. Risk of ”shelfware” - a piece of software that has never been used at all since its creation.
10.9.5.2.2. Risk of ”bloatware” - type of software that using more system resources than necessary.
10.9.6. Project Risk
10.9.6.1. The risk that the project is under.
10.9.6.2. e.g. in PRINCE2® each project risk impact is measured against all 6 project parameters
10.9.6.2.1. Budget
10.9.6.2.2. Time
10.9.6.2.3. Quality
10.9.6.2.4. Scope
10.9.6.2.5. Risk
10.9.6.2.6. Benefits
10.9.7. Understanding Business and Risk Requirements
10.9.7.1. The business usually does not really know their risk requirements
10.9.7.2. Lead the business through a process to discover their risk requirements
10.9.7.2.1. What risks will this new system pose to the business?
10.9.7.2.2. How critical is the system to enterprise?
10.9.7.2.3. Does this system contain / process sensitive data?
10.9.7.2.4. Who will use the system (end users / employees / technical support / customers)?
10.9.7.2.5. Does this system is under local law requirements?
10.9.7.2.6. Does system scope is under specific norm, e.g. ISO / EIC 27001, HIPPA, BESEL III?
10.9.8. Project Management and Controlling
10.9.8.1. Scope Management
10.9.8.1.1. e.g.
10.9.8.2. Time Management
10.9.8.2.1. e.g.
10.9.8.3. Budget Management
10.9.8.3.1. e.g.
10.9.8.4. Risk Management
10.9.8.4.1. e.g.
10.9.8.5. Quality Management
10.9.8.5.1. e.g.
10.9.8.6. Benefits Management
10.9.8.6.1. e.g.
10.9.9. PM tools and techniques (non-exhaustive list)
10.9.9.1. Critical Path Method (CPM)
10.9.9.1.1. example #1
10.9.9.2. Gantt chart
10.9.9.2.1. example #1
10.9.9.3. PERT chart and CPM
10.9.9.3.1. example #1
10.9.9.4. Product Breakdown Structure (PBS).
10.9.9.5. Resourse Breakdown Structure (RBS).
10.9.9.6. Work Breakdown Structure (WBS).
10.10. HR Practices
10.10.1. Job descriptions
10.10.2. Cross trainings
10.10.2.1. Professional education
10.10.2.2. Job training
10.10.2.3. Awareness training
10.10.3. Job rotation
10.10.4. Mandatory vacations
11. Domain 5 - Information Systems Control Monitoring and Maintenance
11.1. Domain 5 - CRISC™ Exam Relevance
11.1.1. The content area for Domain 5 will represent ...
11.1.1.1. 17% of the CRISC® examination
11.1.1.2. 38 questions
11.2. IS Control Monitoring Process
11.3. IS Control Monitoring and Maintenance Process phases
11.3.1. 1. Prioritize risk
11.3.2. 2. Identify controls
11.3.3. 3. Identify information
11.3.4. 4. Implement monitoring
11.3.5. 5. Report results
11.4. Gathering Monitoring Data
11.4.1. Direct Information
11.4.1.1. e.g.
11.4.1.1.1. Information obtained directly by the analyst
11.4.1.1.2. Sampling
11.4.1.1.3. Tools
11.4.2. Indirect Information
11.4.2.1. e.g.
11.4.2.1.1. Information provided by a third party
11.5. Key Control Indicators (KCIs)
11.5.1. An indicator which is used by organisations to help define its controls environment and monitor levels of control relative to desired tolerances.
11.6. Select & Implement Automated Monitoring Tools
11.6.1. Sustainability.
11.6.2. Scalability.
11.6.3. Customizability.
11.6.4. Ownership.
11.6.5. Impact on Performance.
11.6.6. Usability of Existing Tools.
11.6.7. Tool Complexity.
11.6.8. Transferability.
11.6.9. License & Ownerships Cost / Benefit.
11.7. Monitoring Tools
11.7.1. Monitoring tools can focus on various dimensions of internal control.
11.7.2. Monitoring tools are organized into groups based on their control monitoring focus:
11.7.2.1. Transaction data.
11.7.2.2. Conditions.
11.7.2.3. Changes.
11.7.2.4. Processing Integrity.
11.7.2.5. Error management.
11.8. Transaction Data Monitoring
11.8.1. This group of tools perform the following functions:
11.8.1.1. Compare transaction data against a defined rule set.
11.8.1.2. Ad hoc reporting.
11.8.1.3. Data correlation across multiple sources.
11.9. Compliance Monitoring
11.9.1. This group of tools perform the following functions:
11.9.1.1. Examine specific settings or parameters.
11.9.1.2. Compare configuration information against a baseline.
11.9.1.3. Operating periodically - scanning basis.
11.9.1.4. Can be agent based (embedded in hardware or software).
11.10. Process Monitoring
11.10.1. The CRISC™ will monitor risk associated with:
11.10.1.1. Error reporting and handling.
11.10.1.2. Change control.
11.10.1.3. Project management.
11.10.1.4. Business continuity plans.
11.10.1.5. Incident reports.
11.11. Continuous Monitoring
11.11.1. Increasing importance with the advent of e-business.
11.11.2. Provides a method to collect data evidence and system reliability, integrity and compliance as part of normal progressing function.
11.11.3. Allows for monitoring on a continuous basis in a automated fashion.
11.11.4. This type of tools are designed to automate the evaluation process The most common types include:
11.11.4.1. Continuous and Intermittent Simulation (CIS).
11.11.4.2. Snapshots.
11.11.4.3. Monitor Hooks.
11.11.4.4. Integrated Test Facility (ITF).
11.11.4.5. Systems Control Audit Review File and Embedded Audit Modules (SCARF/EAM).
11.12. Cause and Effect Diagram
11.12.1. Cause and Effect Diagram Steps
11.12.1.1. Agree on effect or problem statement.
11.12.1.2. Identify major categories of failure.
11.12.1.3. Link the potential or observed control failures to the categories.
11.12.1.4. Discuss the control failure points with the project team.
11.12.1.5. Revise the monitoring process and repeat testing as necessary.
11.12.2. example #1
12. Basic risk related definitions (from ISACA® CRISC™ perspective)
12.1. Accountability
12.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.
12.1.2. Ideally only one person should be accountable - from accountability reasons.
12.1.2.1. e.g.
12.1.2.1.1. Project Management is accountable for risk affecting his project.
12.1.2.1.2. Team Leader is accountable for risks affecting his team and work.
12.2. Asset (ISACA®)
12.2.1. Something of either tangible or intangible value that is worth protecting, including people, information, infrastructure, finances and reputation.
12.3. Business Impact Analysis / Assessment (BIA)
12.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.
12.4. Business risk
12.4.1. The risk that the system may not meet the users’ expected benefits, services or requirements
12.4.2. e.g.
12.4.2.1. Risk of ”shelfware” - a piece of software that has never been used at all since its creation.
12.4.2.2. Risk of ”bloatware” - type of software that using more system resources than necessary.
12.5. Business case (ISACA®)
12.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.
12.6. Compensating control
12.6.1. An internal control that reduces the risk of an existing or potential control weakness resulting in errors and omissions.
12.7. Control
12.7.1. Policies, procedures, practices and guidelines designed to provide reasonable assurance.
12.8. Data custodian (ISACA®)
12.8.1. The individual(s) and department(s) responsible for the storage and safeguarding of computerized data.
12.9. Data owner (ISACA®)
12.9.1. The individual(s), normally a manager or director, who has responsibility for the integrity, accurate reporting and use of computerized data.
12.10. Framework
12.10.1. Generally accepted, business process-oriented structures that establish a common language and enable repeatable business processes.
12.10.2. e.g.
12.10.2.1. AXELOS® M_o_R® - Management of Risk
12.10.2.1.1. UK best practices
12.10.2.1.2. see M_o_R® mind map
12.10.2.2. COSO Enterprise Risk Management (ERM) - Integrated Framework
12.10.2.2.1. see COSO ERM-IF mind map
12.10.2.3. COSO Internal Control (IC) - Integrated Framework
12.10.2.3.1. see COSO III IC-IF mind map
12.10.2.4. DHS Risk Management Framework
12.10.2.4.1. USA framework
12.10.2.5. Framework for Improving Critical Infrastructure Cybersecurity
12.10.2.5.1. USA framework
12.10.2.5.2. Pages: 39
12.10.2.5.3. see RSA Confereence interview - The Evolving Cybersecurity Framework
12.10.2.6. ISACA® - The Risk IT Framework
12.10.2.6.1. USA framework
12.10.2.7. NIST Risk Management Framework (RMF)
12.10.2.7.1. USA framework
12.10.2.7.2. Process
12.11. Impact (Business impact)
12.11.1. The net effect, positive or negative, on the achievement of business objectives.
12.12. Likelihood
12.12.1. To determine the likelihood of future events, enterprises / organizations must analyse threats to an it system, potential vulnerabilities, and the controls in place.
12.12.2. Possibility observed factors, qualitative.
12.13. Practice
12.13.1. aka. Good Practice / Leading Practice / Generic Practice.
12.13.2. Frequent or unusual actions performed as an application of knowledge.
12.13.3. e.g.
12.13.3.1. APM Body of Knowledge
12.13.3.1.1. UK standard
12.13.3.2. AS/NZS HB 436:2004 Risk Management Guidelines Companion to AS NZS 4360:2004
12.13.3.2.1. Australian guidlines
12.13.3.2.2. Pages: 130
12.13.3.3. BS 6079-3:2000: Project Management – Part 3: Guide to the Management of Business-related Projects Risk
12.13.3.3.1. UK guidlines
12.13.3.4. BS 7799-1:2005 Information technology - Security Techniques - Code of practice for information security management (ISM)
12.13.3.4.1. UK standard
12.13.3.4.2. Pages: 130
12.13.3.5. BS 7799-2
12.13.3.5.1. UK guidance
12.13.3.6. BS 7799-3
12.13.3.6.1. UK guidance
12.13.3.7. BS 31100:2008 Risk management. Code of practice
12.13.3.7.1. UK standard
12.13.3.8. CAN/CSA-Q634-91 - Risk Analysis Requirements and Guidelines
12.13.3.8.1. Canadian guidlines
12.13.3.9. ISACA® - The Risk IT Practitioner Guide
12.13.3.9.1. USA guidlines
12.13.3.10. ISO Guide 73:2009 Risk management - Vocabulary
12.13.3.10.1. International guidlines
12.13.3.10.2. Pages: 24
12.13.3.11. ISO/EIC 27003:2010 Information technology - Security techniques - Information security management system implementation guidance
12.13.3.11.1. International guidlines
12.13.3.11.2. Pages: 74
12.13.3.12. ISO/EIC 27005:2013 IT Risk: Turning Business Threats Into Competitive Advantage (ISRM)
12.13.3.12.1. International guidlines
12.13.3.12.2. Process
12.13.3.12.3. Risk treatment activity
12.13.3.13. PMBOK®5 Guide (includes Risk Management guidelines in projects)
12.13.3.13.1. USA best practices
12.13.3.13.2. Pages: 46 (chapter 11)
12.13.3.13.3. Process
12.13.3.13.4. see PMBOK®5 mind map
12.13.3.14. Project Risk Analysis and Management (PRAM) Guide
12.13.3.14.1. UK guidlines
12.13.3.14.2. Pages: 186
12.14. Preventive control (ISACA®)
12.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.
12.15. Probability
12.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
12.15.2. Chance, parameters and computation, quantitative.
12.16. Project risk
12.16.1. The risk that the project is under.
12.16.2. e.g. in PRINCE2® each project risk impact is measured against all 6 project parameters
12.16.2.1. Budget
12.16.2.1.1. Project budget
12.16.2.1.2. Project risk budget
12.16.2.1.3. Project change budget
12.16.2.2. Time
12.16.2.2.1. Project time
12.16.2.2.2. Project phase time
12.16.2.2.3. Project work package time
12.16.2.3. Quality
12.16.2.3.1. quality of delivered deliverables / products
12.16.2.3.2. quality and maturity of project management practices
12.16.2.4. Scope
12.16.2.4.1. Risk of ‘fatware’ e.g. 80% of software functionalities never used
12.16.2.5. Risk
12.16.2.5.1. Overall project risk profile in risk tolerance
12.16.2.6. Benefits
12.16.2.6.1. Risk associated with project benefits (during and after the project)
12.17. Reputation risk (ISACA®)
12.17.1. The current and prospective effect on earnings and capital arising from negative public opinion.
12.18. Residual risk
12.18.1. The remaining risk after management has implemented a risk response.
12.19. Responsibility
12.19.1. Belongs to those who must ensure that the activities are completed successfully.
12.19.2. Ideally more than one person should be responsible (additional workforce, human resource backup in case of unavailability of first person).
12.19.2.1. e.g.
12.19.2.1.1. Software Developer
12.19.2.1.2. Server Administrator
12.19.2.1.3. Data Custodian
12.20. Risk
12.20.1. The potential for events and their consequences, contains both (aka. two sides of the risk coin):
12.20.1.1. Opportunities
12.20.1.1.1. for benefit (upside / benefits)
12.20.1.2. Threats
12.20.1.2.1. to success (downside / disbenefits)
12.20.2. Risk is the combination of the likelihood of events occurring and the impact those events have on the enterprise / organization.
12.20.2.1. Risk = likelihood * impact
12.21. Risk appetite
12.21.1. Risk appetite is intangible and cannot be measured directly.
12.21.1.1. Analogy of physical appetite or hunger, which cannot be directly quantified.
12.21.1.1.1. ‘I could eat a horse’
12.21.1.1.2. ‘I fancy a doughnut’
12.21.1.1.3. ‘hungry kike the wolf‘
12.21.2. Appetite is always different across organizations.
12.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).
12.21.4. Risk Appetite is connected with Risk Attitude and Risk Tolerance.
12.21.4.1. see RARA Model
12.21.4.1.1. http://www.rara-risk.com/the-rara-model.html
12.21.5. Risk appetite is directly related to an entity’s strategy.
12.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.
12.22. Risk attitude
12.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.
12.22.2. Risk Attitude is connected with Risk Appetite and Risk Tolerance.
12.22.2.1. see RARA Model
12.22.2.1.1. http://www.rara-risk.com/the-rara-model.html
12.23. Risk awareness
12.23.1. Acknowledging that risk is an integral part of the business.
12.24. Risk communication
12.24.1. Risk is to be managed, it must first be discussed and effectively communicated throughout the enterprise.
12.25. Risk culture
12.25.1. ”Culture is a socially constructed attribute of organizations that serves as the social glue binding an organization together.”
12.25.1.1. Cameron & Quinn, 2011
12.25.2. Set of shared attitudes, values and practices that characterize how an entity considers risk in its day-to-day activities.
12.25.3. For many companies, the risk culture flows from the entity’s risk philosophy and risk appetite.
12.25.4. Often one of the most if not the most important enabler!
12.25.4.1. See great talk on RSA 2014 conference about Risk / Security culture.
12.25.4.1.1. https://www.youtube.com/watch?v=bFtGogUiCXI
12.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.
12.25.6. Begins at the top (board and executive)
12.25.6.1. Set direction.
12.25.6.2. Communicate risk-aware decision making.
12.25.6.3. Reward effective risk management behaviors.
12.25.7. Risk-Aware Culture is a series of behaviors
12.25.7.1. Behaviors toward taking risk.
12.25.7.2. Behavior toward negative outcomes.
12.25.7.3. Behavior toward policy compliance.
12.25.8. Symptoms of inadequate or problematic risk culture include
12.25.8.1. Misalignment between ‘real’ culture and policies.
12.25.8.2. Misalignment between real risk appetite and translation into policies.
12.25.8.3. Existence of a “blame culture” vs ”learning culture ”.
12.26. Risk impact
12.26.1. Magnitude of harm that could be caused by a threat’s exploitation of a vulnerability.
12.27. Risk indicators (ISACA®)
12.27.1. Metrics used to indicate risk thresholds and when a risk level may be approaching a high or unacceptable level of risk.
12.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.
12.28. Risk Management Process
12.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.
12.28.2. Holistically covers all concepts and processes affiliated with managing risk, including:
12.28.2.1. Systematic application of management policies, procedures and practices.
12.28.2.2. Establishing the context.
12.28.2.3. Communicating, consulting.
12.28.2.4. Identifying.
12.28.2.5. Analysing.
12.28.2.6. Evaluating.
12.28.2.7. Treating.
12.28.2.8. Controlling.
12.28.2.9. Monitoring.
12.28.2.10. Reviewing.
12.29. Risk subcultures
12.29.1. Individual business units, functions and departments will have slightly different risk cultures.
12.30. Risk tolerance
12.30.1. 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.)
12.30.2. Risk tolerance always need to be measureable in order to be controlled.
12.30.3. "You cannot control it, if you cannot measure it."
12.30.4. Risk Tolerance is connected with Risk Attitude and Risk Appetite.
12.30.4.1. see RARA Model
12.30.4.1.1. http://www.rara-risk.com/the-rara-model.html
12.31. Risk tolerance vs Risk appetite
12.32. Risk factors (ISACA®)
12.32.1. A features that influences the likelihood and or business impact of risk scenarios.
12.32.2. A condition that can influence the frequency and/or magnitude and, ultimately, the business impact of IT-related events/scenarios.
12.33. Standard
12.33.1. Established mandatory rules, specifications and metrics used to measure compliance against quality, value, etc.
12.33.2. e.g.
12.33.2.1. A Risk Management Standard (Ferma)
12.33.2.1.1. UK standard
12.33.2.1.2. Pages: 18
12.33.2.1.3. Process
12.33.2.2. AS/NZS 4360:1995 & AS/NZS 4360:2004 Risk management
12.33.2.2.1. Australian standard
12.33.2.2.2. Pages: 28
12.33.2.2.3. Process
12.33.2.3. BS IEC 62198:2001
12.33.2.3.1. UK standard
12.33.2.4. CAN/CSA-Q850-97 - Risk Management: Guideline for Decision-Makers
12.33.2.4.1. Canadian standard
12.33.2.4.2. Pages: 62
12.33.2.4.3. Process
12.33.2.5. CEI/IEC 62198:2001: International Standard, Project Risk Management: Application Guidelines
12.33.2.5.1. Switzerland standard
12.33.2.6. IEEE Standard 1540-2001 Standard for Software Life Cycle Processes - Risk Management
12.33.2.6.1. USA standard
12.33.2.6.2. Pages: 30
12.33.2.6.3. Process
12.33.2.7. ISACA IT Audit and Assurance Standards
12.33.2.7.1. USA standards
12.33.2.7.2. http://www.isaca.org/KNOWLEDGE-CENTER/ITAF-IS-ASSURANCE-AUDIT-/IS-AUDIT-AND-ASSURANCE/Pages/ObjectivesScopeandAuthorityofITAudit.aspx
12.33.2.8. ISO 31000:2009 Risk management - Principles and guidelines
12.33.2.8.1. International norm
12.33.2.8.2. Pages: 34
12.33.2.8.3. Process
12.33.2.9. ISO/EIC 27001:2013 Information Technology - Security techniques - Information security management systems (ISMS) - Requirements
12.33.2.9.1. International norm
12.33.2.9.2. Pages: 30
12.33.2.10. JIS Q2001:2001 Guidelines for development and implementation of risk management system
12.33.2.10.1. Japan standard
12.33.2.11. ONR 49000 series
12.33.2.11.1. Australian standard
12.33.2.12. PCI DDS
12.33.2.12.1. International norm
12.34. Threat (ISACA®)
12.34.1. Actions or actors that may act in a manner that can result in loss or harm.
12.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
12.35. Vulnerability (ISACA®)
12.35.1. A (known) weakness in asset, design, implementation, operation or internal control of a process that could expose the system to adverse threats.