ISACA
Expert
CRISC
Certified in Risk and Information Systems Control
The CRISC (Certified in Risk and Information Systems Control) certification validates expertise in identifying and managing IT risk and implementing and maintaining information systems controls. Offered by ISACA, CRISC is designed for IT professionals who design, implement, monitor, and maintain information systems controls.
The exam covers five domains: IT Risk Identification (27%), IT Risk Assessment (28%), Risk Response and Mitigation (23%), Risk and Control Monitoring and Reporting (16%), and Information Technology and Security (6%). Candidates must demonstrate the ability to identify IT risks, assess risk impact and likelihood, develop risk response strategies, monitor control effectiveness, and integrate IT security principles.
CRISC is ideal for risk management professionals, IT security managers, business analysts, and compliance officers. The exam features 150 multiple-choice questions administered over 4 hours, with a scaled passing score of 450 out of 800 (approximately 56%). CRISC certification requires a minimum of three years of cumulative work experience in at least two of the four CRISC domains performed within the 10-year period preceding the application date.
Updated 2024
Cybersecurity
150
Questions
6
Practice Tests
56%
Pass Score
68
Views
0
Total Attempts
0%
Avg. Score
0%
Pass Rate
0
Discussions
CRISC Practice Exam 1
Comprehensive 50-question practice exam covering all five CRISC domains: IT Risk Identification, IT Risk Assessment, Risk Response and Mitigation, Risk and Control Monitoring and Reporting, and Information Technology and Security.
50 Q
120 minutes
70%
CRISC Practice Exam 2
Comprehensive 50-question practice exam covering all five CRISC domains: IT Risk Identification, IT Risk Assessment, Risk Response and Mitigation, Risk and Control Monitoring and Reporting, and Information Technology and Security.
50 Q
120 minutes
70%
CRISC Practice Exam 3
Comprehensive 50-question practice exam covering IT risk identification, IT risk assessment, risk response and mitigation, risk and control monitoring and reporting, and information technology and security across all CRISC domains.
50 Q
120 minutes
70%
CRISC Practice Exam 4
Comprehensive 50-question practice exam covering all five CRISC domains.
50 Q
120 minutes
70%
CRISC Practice Exam 5
Comprehensive 50-question practice exam covering all five CRISC domains including IT risk identification, risk assessment, risk response and mitigation, monitoring and reporting, and information technology and security.
50 Q
120 minutes
70%
CRISC Practice Exam 6
Comprehensive 50-question practice exam covering all five CRISC domains.
50 Q
120 minutes
70%
Unlock All Content for CRISC
6 Practice Test(s) + Flash Cards — 3 months access
€39.99
€26.99
Save 30%
or included with Monthly subscription / Content Bundle
Preview (10 / 120)
What is IT risk identification and why is it the first step in the risk management lifecycle?
IT risk identification is the process of discovering, recognizing, and documenting IT-related risks that could affect business objectives. It is the first step because organizations cannot assess, respond to, or monitor risks they have not yet identified. A thorough identification process forms the foundation for all subsequent risk management activities.
What is the difference between a threat, a vulnerability, and a risk in the IT context?
A threat is any potential event or actor that could exploit a weakness, such as a hacker or natural disaster. A vulnerability is a weakness in a system, process, or control that can be exploited. A risk is the combination of the likelihood that a threat will exploit a vulnerability and the resulting impact on the organization.
What are the primary categories of IT risk?
IT risks are commonly categorized as strategic risks (misalignment of IT with business goals), operational risks (failures in IT processes, people, or systems), compliance risks (violations of laws or regulations), project risks (failures in IT project delivery), and security risks (unauthorized access, data breaches, or cyberattacks).
What is a risk register and what information does it typically contain?
A risk register is a centralized document or database used to record and track identified risks. It typically contains the risk description, owner, category, likelihood, impact, risk rating, current controls, planned responses, status, and dates for review. It serves as a living record throughout the risk management lifecycle.
How do risk scenarios help in IT risk identification?
Risk scenarios describe plausible events that could lead to a negative business impact. They connect threat actors, threat types, events, assets, and time dimensions into a narrative. COBIT and ISACA promote risk scenarios as a structured method for identifying and communicating IT risks in business-relevant terms.
What is the role of the organizational risk appetite in risk identification?
Risk appetite defines the amount and type of risk an organization is willing to accept in pursuit of its objectives. During identification, risk appetite helps prioritize which risks are most relevant, determine what level of detail is needed, and set boundaries for acceptable versus unacceptable risk exposure.
What is the COBIT 5 for Risk framework and how does it support risk identification?
COBIT 5 for Risk provides a comprehensive framework for IT risk management based on COBIT principles. It supports risk identification through risk scenarios, risk factors analysis, and integration with enterprise governance processes. It defines a risk function model that links IT risk to business objectives and stakeholder value.
What techniques are commonly used to identify IT risks?
Common techniques include brainstorming sessions, interviews with stakeholders, Delphi technique, SWOT analysis, root cause analysis, event tree analysis, scenario analysis, historical data review, industry benchmarking, vulnerability assessments, and facilitated risk workshops. Multiple techniques are often combined for comprehensive coverage.
What is a risk event and how is it different from a risk condition?
A risk event is a specific occurrence or incident that, if it materializes, will cause a positive or negative impact. A risk condition is a pre-existing state or circumstance that increases the likelihood or impact of a risk event, such as outdated software or lack of trained staff. Conditions enable events.
How does asset identification and valuation contribute to IT risk identification?
Identifying and valuing IT assets such as hardware, software, data, and intellectual property is essential because risk only exists in relation to assets of value. Understanding what assets exist, their business criticality, and their sensitivity allows organizations to focus risk identification on the most important areas.
Flash Cards
cards covering key 120 concepts CRISC
or included with Monthly subscription / Content Bundle
110 more cards available after unlock
Available Languages
English
Japanese
Korean
Chinese
Spanish
Exam Topics
1
41 Q
IT Risk Identification
Collect and analyze business and IT objectives, threats, and vulnerabilities to identify IT risk scenarios and their potential impact.
2
42 Q
IT Risk Assessment
Analyze and evaluate IT risk to determine the likelihood and impact of identified risk scenarios using qualitative and quantitative methods.
3
35 Q
Risk Response and Mitigation
Develop and implement risk response strategies, including avoidance, mitigation, transfer, and acceptance, and ensure controls are in place.
4
24 Q
Risk and Control Monitoring and Reporting
Monitor and report on IT risk and control performance to ensure effectiveness and communicate risk posture to stakeholders.
5
8 Q
Information Technology and Security
Understand IT and security concepts, including network infrastructure, application development, and security frameworks.
CRISC Cheat Sheet
Quick reference guide - 6 sections
ISACA CRISC - Certified in Risk and Information Systems Control
The CRISC certification validates your expertise in identifying, assessing, responding to, and monitoring information technology risk, as well as designing and implementing information systems controls to mitigate that risk. Issued by ISACA, CRISC is globally recognized as the premier certification for IT risk management professionals who work at the intersection of IT and business risk. The certification is designed for IT professionals, risk professionals, control professionals, business analysts, project managers, and compliance professionals who identify and manage IT risks through the development, implementation, and maintenance of appropriate information systems controls. CRISC holders demonstrate a deep understanding of how IT risk impacts business operations and how to align risk management practices with organizational objectives. The exam tests your ability to apply risk management frameworks like COBIT, ISO 31000, and NIST RMF in real-world scenarios, evaluate risk appetite and tolerance, design control frameworks, select appropriate risk response options, and establish key risk indicators for ongoing monitoring. CRISC is particularly valued in governance, risk, and compliance (GRC) roles, and is frequently required for IT risk management, IT audit, and information security governance positions. Maintaining the certification requires 20 CPE hours annually and at least 120 CPE hours over three years, plus payment of annual maintenance fees to ISACA.
Exam Details
| Exam Code | CRISC |
| Duration | 240 minutes (4 hours) |
| Number of Questions | 150 multiple-choice questions |
| Passing Score | 450 / 800 (scaled score) |
| Cost | $575 USD (ISACA members) / $760 USD (non-members) |
| Experience Requirement | Minimum 3 years in at least 2 of 4 CRISC domains, with one in Domain 1 or 2 |
| Question Types | Multiple choice (single answer), scenario-based |
| Certification Level | Professional / Expert |
Domain Weights
| Domain | Weight |
|---|---|
| Domain 1: Governance | 26% |
| Domain 2: IT Risk Assessment | 20% |
| Domain 3: Risk Response and Reporting | 32% |
| Domain 4: Information Technology and Security | 22% |
Study Tips
- Domain 3: Risk Response and Reporting carries the heaviest weight at 32%; master risk response options (accept, mitigate, transfer, avoid), control design and implementation, and risk reporting to stakeholders as these will dominate the exam
- Domain 1: Governance (26%) tests your understanding of organizational strategy, risk appetite, risk tolerance, and how IT risk management aligns with enterprise objectives; know how governance frameworks like COBIT 2019 establish the risk management foundation
- ISACA exam questions are scenario-based and focus on what you should do FIRST or what is the BEST course of action; always consider the organizational context, risk appetite, and stakeholder communication before selecting technical answers
- Understand the complete risk management lifecycle: identify risks, analyze and evaluate them, determine the appropriate response, implement controls, monitor through KRIs, and report to management and the board; questions frequently test your knowledge of the correct sequence and dependencies between these steps
- Know the differences between frameworks: COBIT 2019 focuses on IT governance and management, ISO 31000 provides general risk management principles, NIST RMF is specific to information systems security, and ISO 27005 focuses on information security risk management; understand when each is most appropriate
- Quantitative vs qualitative risk analysis is heavily tested; know when to use each method, understand ALE/SLE/ARO calculations, and recognize that qualitative analysis is used when data is insufficient for quantitative methods or when a quick initial assessment is needed
- Practice with the ISACA Review Manual and Question Database; the official CRISC Review Manual is the single best resource as it maps directly to the exam domains and uses ISACA's terminology and methodology
IT Risk Management Frameworks
| Framework | Description |
|---|---|
| COBIT 2019 | ISACA's framework for governance and management of enterprise IT; built on six principles: provide stakeholder value, holistic approach, dynamic governance system, governance distinct from management, tailored to enterprise needs, and end-to-end governance system; defines 40 governance and management objectives organized into five domains: Evaluate Direct and Monitor (EDM), Align Plan and Organize (APO), Build Acquire and Implement (BAI), Deliver Service and Support (DSS), and Monitor Evaluate and Assess (MEA); COBIT 2019 introduces design factors (enterprise strategy, IT-related goals, risk profile, enterprise size, threat landscape) to tailor the governance system; capability maturity model uses levels 0-5 to assess process maturity; directly integrates with CRISC concepts through APO12 Manage Risk and EDM03 Ensured Risk Optimization |
| ISO 31000:2018 | International standard providing principles, framework, and process for managing risk; applies to any type of risk, not IT-specific; eight principles: integrated, structured and comprehensive, customized, inclusive, dynamic, best available information, human and cultural factors, and continual improvement; risk management process: communication and consultation, scope context and criteria, risk assessment (identification, analysis, evaluation), risk treatment, monitoring and review, recording and reporting; emphasizes that risk management should be embedded into organizational governance and decision-making at all levels; provides a common risk vocabulary across business units |
| NIST Risk Management Framework (RMF) | NIST SP 800-37 provides a structured process for integrating security and risk management into system development lifecycle; seven steps: Prepare (establish context and priorities), Categorize (information systems based on impact analysis using FIPS 199: low, moderate, high), Select (security controls from NIST SP 800-53 catalog), Implement (deploy controls), Assess (evaluate control effectiveness), Authorize (risk-based decision by authorizing official to accept residual risk), and Monitor (ongoing assessment of controls); mandatory for US federal agencies; widely adopted by private sector; ties security to business impact through categorization |
| ISO 27005:2022 | International standard specifically for information security risk management; supports the requirements of ISO 27001 ISMS; risk management process: context establishment, risk identification, risk analysis, risk evaluation, risk treatment, risk acceptance, risk communication and consultation, risk monitoring and review; aligns with the ISO 31000 framework while providing specific guidance for information security risks; defines risk criteria including risk acceptance criteria, risk evaluation criteria, and impact criteria |
Exam Tip: Know the key differences between frameworks. COBIT 2019 is ISACA's own framework and heavily favored on CRISC exams for IT governance questions. ISO 31000 is the broadest (all risk types), NIST RMF is systems-focused with mandatory federal compliance, and ISO 27005 specifically addresses information security risk within an ISMS. When the exam asks about aligning IT risk with business objectives, think COBIT first.
Risk Appetite, Tolerance, and Capacity
| Concept | Description |
|---|---|
| Risk Appetite | The broad level of risk an organization is willing to accept in pursuit of its strategic objectives; set by the board of directors and senior management; expressed qualitatively (conservative, moderate, aggressive) or quantitatively (maximum acceptable loss, target risk levels); different business units may have different risk appetites aligned to their functions; risk appetite statements guide risk-based decision-making across the enterprise and must be communicated to all stakeholders involved in risk decisions |
| Risk Tolerance | The acceptable variation from the risk appetite for specific risk categories or objectives; more granular than risk appetite; typically expressed as thresholds or ranges (e.g., system downtime tolerance of 4 hours per quarter, maximum acceptable data loss of 1 hour via RPO); when risk levels exceed tolerance thresholds, escalation and corrective action are required; risk tolerance must be measurable and monitored through KRIs |
| Risk Capacity | The maximum amount of risk an organization can absorb before it threatens survival or solvency; an objective measure based on financial reserves, insurance coverage, operational resilience, and regulatory capital requirements; risk appetite must always be set below risk capacity; organizations that operate near their risk capacity have little buffer for unexpected losses |
| Risk Culture | The values, beliefs, knowledge, attitudes, and understanding about risk shared throughout the organization; a mature risk culture means employees at all levels understand and actively participate in risk management; indicators of strong risk culture: tone at the top from leadership, risk awareness in daily decisions, open communication about risk events without blame, integration of risk considerations into performance management and incentives |
Organizational Governance and IT Risk Alignment
| Concept | Description |
|---|---|
| Three Lines Model | Governance framework defining roles in risk management; First Line: operational management and staff who own and manage risks daily (business units, IT operations); Second Line: risk management and compliance functions that provide oversight, frameworks, tools, and challenge (CISO, risk management team, compliance); Third Line: internal audit provides independent assurance on the effectiveness of governance and risk management; the board and senior management sit above all three lines with ultimate accountability; external audit and regulators provide additional assurance outside the model |
| IT Risk Management Policy | Formal document approved by senior management or the board that defines the organization's approach to IT risk management; includes scope, objectives, roles and responsibilities, risk assessment methodology, risk appetite and tolerance statements, risk reporting requirements, escalation procedures, and review frequency; must be communicated to all relevant stakeholders and reviewed at least annually or when significant changes occur; serves as the foundation for all IT risk management activities |
| Risk Ownership | Each identified risk must have a designated risk owner who is accountable for managing the risk within acceptable levels; risk owners are typically senior managers or executives with authority and resources to implement risk responses; risk owners are responsible for monitoring risk levels, ensuring controls are operating effectively, reporting on risk status, and escalating when risk exceeds tolerance; the risk management function facilitates and coordinates but does not own the risks |
| Enterprise Risk Management Integration | IT risk management must be integrated with enterprise risk management (ERM) to ensure a holistic view of organizational risk; IT risks should be reported using the same language and metrics as other risk categories (financial, operational, strategic, compliance); the risk register should consolidate IT risks with business risks; IT risk assessment results feed into enterprise-level risk aggregation and reporting to the board |
Exam Tip: Governance questions often ask who is ultimately accountable for IT risk management. The answer is always the board of directors or senior management, not the IT department or the risk management team. The board sets risk appetite, approves the risk management policy, and ensures adequate resources are allocated. Risk management practitioners execute the strategy but do not own the accountability.
Legal, Regulatory, and Compliance Requirements
- Regulatory Compliance: Organizations must identify all applicable laws, regulations, and industry standards that impact their IT environment; examples include GDPR (data protection), SOX (financial controls), HIPAA (healthcare data), PCI DSS (payment card data), Basel III (banking), and sector-specific regulations; non-compliance introduces legal risk, financial penalties, and reputational damage that must be factored into risk assessments
- Contractual Obligations: Third-party contracts, service level agreements (SLAs), and non-disclosure agreements create obligations that must be assessed for IT risk implications; vendor contracts should include right-to-audit clauses, data protection requirements, incident notification timelines, and termination conditions; contract risk is an often-overlooked component of IT risk assessment
- Risk-Based Compliance: Rather than a checkbox approach, mature organizations use risk-based compliance where the effort invested in compliance activities is proportional to the risk level; higher-risk regulatory requirements receive more resources and attention; compliance gaps are treated as risks and entered into the risk register with appropriate response plans
- Ethics and Professional Standards: ISACA's Code of Professional Ethics and IT Audit and Assurance Standards apply to CRISC holders; risk professionals must maintain independence and objectivity, protect confidential information, report material findings to appropriate parties, and pursue continuing professional education to maintain competency
Risk Identification
| Technique | Description |
|---|---|
| Risk Scenarios | Structured descriptions of potential risk events using the format: threat actor exploits vulnerability in asset causing impact to business objective; COBIT 2019 risk scenarios include IT benefit/value enablement scenarios, IT programme and project delivery scenarios, and IT operations and service delivery scenarios; scenarios should cover the full spectrum of threats (malicious, accidental, environmental, technical failure) and be specific enough to support meaningful analysis; use scenario development workshops with cross-functional stakeholders to identify scenarios that matter most to the organization |
| Threat and Vulnerability Analysis | Threats are potential events that could exploit vulnerabilities; categories include natural disasters, malicious actors (external hackers, insiders, nation-states), system failures, human error, and supply chain disruptions; threat intelligence sources include industry ISACs, government advisories (CISA, CERT), commercial feeds, and dark web monitoring; vulnerabilities are weaknesses in systems, processes, or controls that can be exploited; identified through vulnerability scanning, penetration testing, configuration audits, and process reviews; threat and vulnerability pairs drive risk scenario development |
| Risk Identification Methods | Multiple methods should be used to ensure comprehensive coverage; includes historical analysis (review past incidents and near-misses), brainstorming sessions with subject matter experts, Delphi technique (anonymous expert consensus), SWOT analysis, process flow analysis (identify failure points in business processes), IT asset inventory review, compliance gap analysis, audit findings, and industry benchmarking; risk identification should be an ongoing activity, not a one-time exercise; trigger events for re-identification include organizational changes, new technologies, regulatory changes, and significant incidents |
| Risk Register | Central repository documenting all identified risks and their attributes; each entry includes risk ID, description, risk category, threat source, vulnerability, affected assets, likelihood, impact, inherent risk rating, existing controls, residual risk rating, risk owner, risk response, target risk level, KRIs, and review date; the risk register is a living document updated through regular reviews, incident post-mortems, audit findings, and environmental changes; serves as the primary input for risk reporting to management and the board |
Exam Tip: Risk identification must be comprehensive and ongoing. The exam frequently tests the difference between inherent risk (risk before controls) and residual risk (risk after controls are applied). Also know that risk scenarios should be developed with input from both IT and business stakeholders to ensure all relevant perspectives are captured.
Risk Analysis Methods
| Method | Description |
|---|---|
| Qualitative Risk Analysis | Uses descriptive scales (High, Medium, Low or 1-5) to rate likelihood and impact; results plotted on a risk matrix (heat map) for visualization and prioritization; advantages: faster to perform, does not require precise data, easier for stakeholders to understand, useful for initial screening; disadvantages: subjective, inconsistent ratings between assessors, difficult to perform cost-benefit analysis on controls; best used when historical loss data is unavailable, when a rapid assessment is needed, or for initial risk screening to prioritize which risks warrant deeper quantitative analysis |
| Quantitative Risk Analysis | Uses numerical values and calculations to express risk in monetary terms; key formulas: Single Loss Expectancy (SLE) = Asset Value (AV) x Exposure Factor (EF); Annualized Rate of Occurrence (ARO) = estimated frequency per year; Annualized Loss Expectancy (ALE) = SLE x ARO; ALE is the expected annual monetary loss from a specific risk; advantages: enables cost-benefit analysis (compare ALE reduction to control cost), provides objective data for management decisions, facilitates risk aggregation; disadvantages: requires reliable historical data, time-consuming, difficult to quantify intangible impacts like reputation; Monte Carlo simulation provides probability distributions rather than single-point estimates |
| Semi-Quantitative Analysis | Hybrid approach using numerical scales (1-10 or 1-100) with defined criteria for each level; provides more granularity than pure qualitative but does not require the precise data of full quantitative analysis; risk scores calculated by multiplying likelihood and impact ratings; allows ranking and prioritization while acknowledging the limitations of available data; commonly used in practice because it balances rigor with practicality |
| Impact Assessment Categories | Financial impact (direct costs, fines, lost revenue, remediation expenses); operational impact (business process disruption, productivity loss, service level breaches); reputational impact (customer trust, brand value, market position); legal and regulatory impact (compliance violations, litigation, regulatory sanctions); strategic impact (ability to achieve business objectives, competitive disadvantage); safety impact (harm to individuals); each risk should be assessed across multiple impact categories as a single event may trigger cascading effects |
Risk Evaluation and Prioritization
| Concept | Description |
|---|---|
| Risk Heat Map | Visual representation of risks plotted on a matrix with likelihood on one axis and impact on the other; color-coded zones: red (critical, immediate action required), orange/amber (high, management attention needed), yellow (moderate, monitor and manage), green (low, accept and monitor); helps management quickly understand the risk landscape and focus resources on the most significant risks; used extensively in risk reporting to boards and steering committees |
| Risk Aggregation | Combining individual risks to understand the cumulative risk exposure; correlated risks may amplify each other (a cyberattack may trigger both data loss and reputational damage simultaneously); portfolio view of risk helps identify concentration risk (too many critical risks in one area) and systemic risk (interconnected risks that could cascade); aggregated risk levels must be compared against enterprise risk capacity and appetite |
| Inherent vs Residual vs Target Risk | Inherent risk is the risk level before any controls are applied (theoretical maximum exposure); current residual risk is the risk remaining after existing controls are considered; target residual risk is the desired risk level after planned risk responses are implemented; the gap between current residual risk and target risk drives risk response planning and resource allocation; all three should be tracked in the risk register |
| Business Impact Analysis (BIA) | Process to determine the criticality of business processes and the impact of disruption; identifies Recovery Time Objective (RTO), the maximum acceptable downtime before business impact becomes unacceptable; Recovery Point Objective (RPO), the maximum acceptable data loss measured in time; Maximum Tolerable Downtime (MTD), the absolute longest a process can be unavailable before the organization faces existential threat; BIA results directly feed into risk assessment by quantifying the impact dimension of IT risk scenarios and are essential for disaster recovery and business continuity planning |
Exam Tip: Know the quantitative formulas cold: SLE = AV x EF, ALE = SLE x ARO. When comparing risk response options, calculate the ALE before and after controls, then compare the ALE reduction to the cost of the control. A control is justified when its annual cost is less than the ALE reduction it provides. Also remember that BIA determines the IMPACT, not the likelihood.
IT Risk Assessment Process
- Scope and Context: Define what is included in the assessment (business processes, IT systems, data assets, third-party services); establish the assessment criteria (risk scales, impact categories, likelihood definitions); identify stakeholders and their information needs; understand the regulatory and business environment that influences risk priorities
- Asset Identification and Valuation: Create and maintain an inventory of IT assets including hardware, software, data, infrastructure, and people; classify assets by criticality and sensitivity; determine asset values based on replacement cost, revenue contribution, regulatory importance, and strategic significance; asset valuation is essential for quantitative risk analysis and control cost justification
- Control Assessment: Evaluate the effectiveness of existing controls in mitigating identified risks; control testing methods include inquiry, observation, inspection, and re-performance; identify control gaps and weaknesses that increase residual risk; document control deficiencies for remediation and factor them into residual risk ratings
- Third-Party Risk Assessment: Evaluate risks introduced by vendors, suppliers, cloud providers, and other third parties; assess vendor security posture through questionnaires, SOC 2 reports, ISO 27001 certification, penetration test results, and right-to-audit clauses; fourth-party risk (your vendor's vendors) must also be considered; third-party risk should be proportional to the criticality and sensitivity of the services and data involved
Risk Response Options
| Response | Description |
|---|---|
| Risk Mitigation (Reduction) | Implement controls to reduce the likelihood and/or impact of the risk to within acceptable levels; the most common risk response; includes preventive controls (stop the risk event from occurring), detective controls (identify when a risk event has occurred), and corrective controls (restore normal operations after a risk event); control selection should be based on cost-benefit analysis comparing the cost of the control to the reduction in expected loss; controls may address the threat (security awareness training), the vulnerability (patching), or the impact (backup and recovery); multiple layers of controls (defense in depth) provide more reliable risk reduction |
| Risk Acceptance | Consciously decide to accept the risk without additional mitigation because it falls within the organization's risk appetite and tolerance; must be a formal, documented decision by the appropriate risk owner with authority to accept the risk; acceptance is appropriate when the cost of mitigation exceeds the expected loss, when the risk is very low, or when the risk is inherent to a business activity that generates value exceeding the risk; unaccepted risks that exceed tolerance must be escalated; risk acceptance should be periodically reviewed as conditions change |
| Risk Transfer (Sharing) | Shift part or all of the financial consequence of a risk to a third party; common methods include cyber insurance (transfers financial impact of breaches, ransomware, business interruption), outsourcing (transfers operational risk to a service provider, but accountability remains with the organization), contractual risk allocation (indemnification clauses, limitation of liability, SLAs with penalties); important: risk transfer does not eliminate accountability or reputational risk; the organization retains responsibility for managing the risk and ensuring the transfer mechanism is effective and adequate |
| Risk Avoidance | Eliminate the risk entirely by removing the risk source or discontinuing the activity that generates the risk; examples include not entering a risky market, decommissioning a legacy system with unacceptable vulnerabilities, not collecting sensitive data that is not business-critical; avoidance also means foregoing the potential benefit associated with the activity; appropriate when the risk far exceeds the potential reward or when no acceptable level of mitigation can be achieved within cost constraints; may not always be feasible for risks inherent to the core business |
Exam Tip: The exam heavily tests risk response selection. Always consider: (1) Is the residual risk within risk appetite? If yes, accept. (2) Can controls reduce risk cost-effectively? If yes, mitigate. (3) Can a third party absorb the financial impact? If yes, transfer. (4) Is the risk unacceptable and the activity non-essential? If yes, avoid. The BEST response depends on organizational context, not just the risk level.
Control Design and Implementation
| Control Type | Description |
|---|---|
| Preventive Controls | Designed to prevent a risk event from occurring; examples: access controls and authentication (prevent unauthorized access), input validation (prevent injection attacks), segregation of duties (prevent fraud), change management procedures (prevent unauthorized changes), encryption (prevent unauthorized data disclosure), firewalls and network segmentation (prevent network intrusions), security awareness training (prevent social engineering); most cost-effective when they successfully prevent high-impact events |
| Detective Controls | Designed to identify and alert when a risk event occurs or has occurred; examples: intrusion detection systems (detect network attacks), log monitoring and SIEM (detect anomalous activity), reconciliation processes (detect data discrepancies), audit trails (detect unauthorized changes), vulnerability scanning (detect weaknesses), anomaly detection using AI/ML (detect behavioral deviations), continuous monitoring (detect control failures); detective controls are essential because no preventive control is 100% effective |
| Corrective Controls | Designed to restore normal operations and minimize impact after a risk event; examples: incident response procedures (contain and remediate security incidents), disaster recovery plans (restore IT services), backup and restore processes (recover data), patch management (fix vulnerabilities after discovery), anti-malware remediation (remove infections), insurance claims (recover financial losses); corrective controls reduce the impact dimension of risk |
| Compensating Controls | Alternative controls implemented when the primary control is not feasible or cost-effective; must provide an equivalent level of risk reduction; examples: if automated access reviews are not possible, implement manual quarterly reviews with management sign-off; if full disk encryption cannot be deployed on legacy systems, implement physical security controls and network isolation; compensating controls must be documented with justification for why the primary control is not used and evidence that the compensating control adequately addresses the risk |
Key Risk Indicators (KRIs)
| Concept | Description |
|---|---|
| KRI Definition | Metrics used to provide an early warning that risk exposure is changing and may be approaching or exceeding risk tolerance thresholds; effective KRIs are measurable, predictive (leading rather than lagging), relevant to specific risks, sensitive to changes in the risk environment, comparable over time, and cost-effective to collect; each KRI should have a defined owner, data source, collection frequency, and threshold levels (green/yellow/red) aligned to risk tolerance |
| KRI Examples | Number of unpatched critical vulnerabilities (cybersecurity risk); number of failed login attempts per day (unauthorized access risk); percentage of employees who completed security awareness training (human risk); mean time to detect and respond to incidents (operational risk); number of overdue audit findings (compliance risk); system availability percentage (operational risk); number of access rights violations (access control risk); volume of sensitive data transferred externally (data leakage risk); number of third-party security incidents (vendor risk); percentage of IT projects exceeding budget or timeline (project risk) |
| KRI vs KPI vs KCI | Key Risk Indicators (KRIs) measure the level of risk exposure and provide early warning of increasing risk; Key Performance Indicators (KPIs) measure how well a process or activity is performing against objectives; Key Control Indicators (KCIs) measure the effectiveness of specific controls in operating as designed; these metrics are complementary: declining KPI performance may signal increasing risk (leading to KRI threshold breach), and KCI failures explain why residual risk is rising; a comprehensive risk monitoring program uses all three |
Risk Reporting and Communication
- Board and Executive Reporting: Risk reports to the board should be concise, strategic, and focused on risks that could impact business objectives; include risk heat maps showing the top risks, trend analysis showing risk movement over time, KRI dashboard with threshold status, risk appetite utilization, emerging risks, and recommendations for board decisions; frequency is typically quarterly with ad-hoc reporting for significant events; use business language rather than technical jargon
- Management Reporting: More detailed than board reporting; includes risk register summaries by business unit or domain, control effectiveness assessments, remediation progress tracking, incident analysis and lessons learned, third-party risk status, and resource requirements for risk response implementation; monthly or as needed based on risk dynamics
- Operational Reporting: Tactical reports for risk owners and control operators; includes real-time KRI dashboards, control test results, vulnerability scan findings, incident tickets, compliance status, and action item tracking; daily or weekly frequency enables timely response to emerging issues
- Risk Escalation: Defined escalation procedures ensure that risks exceeding tolerance thresholds are promptly communicated to the appropriate authority level for decision-making; escalation triggers include KRI threshold breaches, material incidents, control failures, audit findings rated as high or critical, regulatory findings, and emerging threats; escalation paths should be documented, tested, and understood by all risk stakeholders
Exam Tip: Risk reporting questions frequently ask about the appropriate level of detail for different audiences. The board needs a strategic summary with clear risk trends and decisions required. Management needs operational detail for action. The exam also tests understanding that risk reporting must be timely, accurate, complete, and relevant to the audience's decision-making needs.
IT Control Frameworks and Standards
| Framework / Standard | Description |
|---|---|
| NIST Cybersecurity Framework (CSF) | Voluntary framework organized into six core functions: Govern (establish and monitor cybersecurity risk management strategy, expectations, and policy), Identify (understand assets, suppliers, and risks), Protect (safeguards to manage cybersecurity risk including access control, awareness training, data security, platform security), Detect (find and analyze possible cybersecurity attacks and compromises through continuous monitoring and anomaly detection), Respond (actions taken regarding a detected cybersecurity incident including incident management, analysis, mitigation, reporting, and communication), and Recover (restore assets and operations affected by an incident including recovery planning and communication); implementation tiers measure organizational maturity from Partial (Tier 1) to Adaptive (Tier 4); profiles enable organizations to align the framework to their specific risk environment |
| ISO 27001 / 27002 | ISO 27001 specifies requirements for establishing, implementing, maintaining, and continually improving an Information Security Management System (ISMS); certification requires an independent audit by an accredited certification body; uses the Plan-Do-Check-Act (PDCA) cycle for continuous improvement; ISO 27002 provides detailed implementation guidance for the 93 controls organized into four themes: organizational controls (37), people controls (8), physical controls (14), and technological controls (34); Annex A of ISO 27001 references these controls which must be addressed through a Statement of Applicability (SoA) documenting which controls are selected, why, and their implementation status |
| NIST SP 800-53 | Comprehensive catalog of security and privacy controls for information systems; over 1,000 controls organized into 20 families including Access Control (AC), Audit and Accountability (AU), Configuration Management (CM), Contingency Planning (CP), Identification and Authentication (IA), Incident Response (IR), Risk Assessment (RA), System and Communications Protection (SC), and System and Information Integrity (SI); control baselines defined for Low, Moderate, and High impact systems per FIPS 199; mandatory for US federal systems; widely used by private sector for comprehensive control coverage |
| CIS Controls | 18 prioritized cybersecurity best practices developed by the Center for Internet Security; organized into three implementation groups: IG1 (essential cyber hygiene for all organizations), IG2 (for organizations managing sensitive data), and IG3 (for organizations facing sophisticated attacks); top controls include inventory of enterprise assets, inventory of software assets, data protection, secure configuration, account management, access control management, continuous vulnerability management, and audit log management; pragmatic and action-oriented compared to more comprehensive frameworks |
IT General Controls
| Control Area | Description |
|---|---|
| Access Control | Logical access controls ensure only authorized users can access systems and data; includes identification (unique user IDs), authentication (passwords, MFA, biometrics, certificates), and authorization (role-based access control, least privilege, need-to-know); user access provisioning and deprovisioning procedures; periodic access reviews to verify appropriateness; privileged access management for administrator accounts; segregation of duties to prevent any single individual from performing conflicting functions (e.g., developer and deployer, requestor and approver) |
| Change Management | Formal process for managing changes to IT systems to prevent unauthorized, untested, or disruptive modifications; includes change request submission with business justification, impact and risk assessment, testing in non-production environment, approval by change advisory board (CAB) or designated authority, scheduled implementation with rollback plan, post-implementation review; change types: standard (pre-approved, low-risk), normal (follows full process), and emergency (expedited approval with post-implementation review); prevents unauthorized changes that could introduce vulnerabilities or system instability |
| IT Operations | Controls ensuring the reliable and secure operation of IT infrastructure and services; includes job scheduling and monitoring, backup management (schedule, retention, testing, offsite storage), system monitoring and alerting, capacity management, incident management (detect, log, categorize, prioritize, investigate, resolve, close), problem management (root cause analysis of recurring incidents), and service level management (SLA monitoring and reporting); operations controls provide the foundation for continuous service delivery |
| System Development Lifecycle (SDLC) | Controls embedded throughout the software development process to ensure security and quality; requirements phase: security requirements, data classification, compliance requirements; design phase: threat modeling, security architecture review; development phase: secure coding standards, peer code review, static application security testing (SAST); testing phase: dynamic application security testing (DAST), penetration testing, user acceptance testing; deployment phase: change management, configuration management; maintenance: vulnerability management, patching; DevSecOps integrates security throughout the CI/CD pipeline |
Exam Tip: IT General Controls (ITGCs) are pervasive controls that affect the reliability of all IT-dependent processes. If ITGCs are weak (e.g., poor change management, inadequate access controls), application-level controls cannot be relied upon. The exam tests understanding that ITGC weaknesses have a cascading impact on the overall control environment and increase residual risk across multiple business processes.
Control Monitoring and Continuous Improvement
| Activity | Description |
|---|---|
| Control Self-Assessment (CSA) | Process where control owners evaluate the design adequacy and operating effectiveness of their own controls; uses structured questionnaires, workshops, or surveys; provides first-line assurance that controls are functioning; identifies control weaknesses early before they are found by audit; results feed into risk assessments and control improvement plans; cost-effective complement to independent audit testing but does not replace it due to potential bias |
| Continuous Control Monitoring (CCM) | Automated, near-real-time monitoring of control effectiveness using technology; examples: automated access review tools that flag excessive permissions, SIEM correlation rules that detect control bypasses, configuration compliance scanning that identifies drift from security baselines, automated reconciliation of financial transactions; provides timely detection of control failures versus periodic manual testing; reduces the window of exposure between a control failure and its detection; increasingly important as organizations adopt cloud and DevOps |
| Internal Audit Testing | Independent evaluation of control design and operating effectiveness by the internal audit function (third line); testing methods: inquiry (asking control operators), observation (watching controls being performed), inspection (examining evidence and documentation), re-performance (independently executing the control procedure); sampling methodologies: statistical sampling (allows extrapolation), judgmental sampling (targeted based on auditor expertise); audit findings rated by severity and tracked through remediation; provides objective assurance to the board on the control environment |
| Control Maturity Assessment | Evaluate the maturity of controls and risk management processes using capability maturity models; typical levels: Initial/Ad Hoc (processes are unpredictable and reactive), Managed (processes are planned and performed), Defined (processes are characterized and documented organization-wide), Quantitatively Managed (processes are measured and controlled using metrics), Optimizing (focus on continuous improvement through innovation); maturity assessment helps identify improvement priorities and benchmark against industry peers; higher maturity correlates with lower risk and more efficient operations |
Information Security and Emerging Technology Risk
- Business Continuity and Disaster Recovery: BCP ensures critical business functions continue during and after a disruption; DRP specifically addresses IT system and data recovery; key components include business impact analysis (BIA) to determine critical processes and recovery objectives, risk assessment of potential disruption scenarios, recovery strategies (hot/warm/cold sites, cloud-based DR, data replication), plan documentation and communication, regular testing (tabletop exercises, walkthroughs, functional tests, full interruption tests), and plan maintenance to reflect changes in the business and technology environment
- Cloud Computing Risk: Shared responsibility model defines which controls are the cloud provider's responsibility versus the customer's, varying by service model (IaaS, PaaS, SaaS); risks include data sovereignty and jurisdiction issues, vendor lock-in, multi-tenancy vulnerabilities, API security, shadow IT (unauthorized cloud adoption), loss of visibility and control, and supply chain risk; mitigation includes cloud security posture management, CASB deployment, contractual protections, and exit strategy planning
- Third-Party and Supply Chain Risk: Organizations increasingly depend on third-party services creating risk beyond their direct control; vendor risk management lifecycle: due diligence before onboarding, contractual protections (SLA, right-to-audit, data protection clauses, incident notification), ongoing monitoring (SOC reports, security assessments, KRI tracking), and termination planning; fourth-party risk (vendors of vendors) creates cascading exposure; concentration risk when multiple critical functions depend on the same vendor
- Emerging Technology Risk: New technologies introduce novel risks that existing frameworks may not fully address; AI and machine learning risks include algorithmic bias, data poisoning, model explainability, and privacy concerns; IoT risks include expanded attack surface, weak authentication, unpatched firmware, and data privacy; blockchain risks include smart contract vulnerabilities, key management, and regulatory uncertainty; organizations should evaluate emerging technology risks before adoption using a structured technology risk assessment process
Quantitative Risk Analysis Formulas
| Formula | Definition | Example |
|---|---|---|
| SLE = AV x EF | Single Loss Expectancy = Asset Value x Exposure Factor; the expected monetary loss each time a risk event occurs | Server worth $100,000 with 40% EF: SLE = $100,000 x 0.4 = $40,000 |
| ALE = SLE x ARO | Annualized Loss Expectancy = SLE x Annualized Rate of Occurrence; expected annual loss from a specific risk | SLE of $40,000 occurring twice per year: ALE = $40,000 x 2 = $80,000 |
| Risk Value = Likelihood x Impact | Semi-quantitative risk score using rating scales (e.g., 1-5); used for prioritization and heat map placement | Likelihood=4, Impact=5: Risk Score = 20 (Critical on a 1-25 scale) |
| Control Value = ALE(before) - ALE(after) - Control Cost | Net benefit of implementing a control; positive value means the control is cost-justified | ALE drops from $80K to $20K; control costs $30K/yr: Value = $80K - $20K - $30K = $30K net benefit |
| ROSI = (ALE Reduction - Control Cost) / Control Cost | Return on Security Investment; measures the efficiency of security spending as a percentage return | ALE reduction $60K, Control cost $30K: ROSI = ($60K - $30K) / $30K = 100% |
Risk Management Lifecycle Quick Reference
| Phase | Key Activities |
|---|---|
| 1. Establish Context | Define scope, objectives, risk criteria, risk appetite, risk tolerance, stakeholders, regulatory requirements, and organizational context |
| 2. Risk Identification | Identify threats, vulnerabilities, assets, existing controls, and develop risk scenarios; populate the risk register |
| 3. Risk Analysis | Assess likelihood and impact using qualitative, semi-quantitative, or quantitative methods; determine inherent and residual risk levels |
| 4. Risk Evaluation | Compare risk levels against risk criteria and tolerance; prioritize risks for treatment; create risk heat maps |
| 5. Risk Response | Select and implement risk response: mitigate, accept, transfer, or avoid; design and deploy controls; assign risk owners |
| 6. Control Monitoring | Track KRIs, test control effectiveness, perform CSA, conduct audits, and continuously monitor the risk environment |
| 7. Reporting and Communication | Report risk status to board, management, and operational teams; escalate risks exceeding tolerance; document decisions |
Framework Comparison Quick Reference
| Framework | Focus | Best For |
|---|---|---|
| COBIT 2019 | IT governance and management | Aligning IT with business objectives, enterprise IT governance |
| ISO 31000 | General risk management principles | Enterprise-wide risk management across all risk types |
| NIST RMF (SP 800-37) | Information system security risk | Federal agencies, system authorization, security categorization |
| ISO 27005 | Information security risk management | Supporting ISO 27001 ISMS implementation |
| NIST CSF | Cybersecurity risk management | Organizing cybersecurity program, maturity assessment |
| NIST SP 800-53 | Security and privacy controls catalog | Comprehensive control selection, federal compliance |
| CIS Controls | Prioritized cybersecurity actions | Practical, actionable security improvements, quick wins |
Common Exam Scenario Decision Guide
| Scenario | Best Action |
|---|---|
| Risk exceeds tolerance but is within appetite | Implement risk response to bring within tolerance; escalate to risk owner for approval of response plan |
| New IT system being deployed | Perform risk assessment BEFORE deployment; identify controls during design phase; integrate into risk register |
| Control cost exceeds potential loss | Risk acceptance is appropriate; document the decision formally with risk owner approval |
| KRI breaches red threshold | Immediate escalation per defined procedures; investigate root cause; assess if risk response plan needs updating |
| Audit finds control weakness | Assess impact on residual risk; develop remediation plan with timeline; update risk register; report to management |
| New regulation requires compliance | Perform gap analysis against requirements; assess non-compliance risk; implement controls; update policies and risk register |
| Third party suffers a breach | Activate incident response; assess impact on your data and systems; review contractual obligations; update vendor risk assessment |
Exam Tip: CRISC exam questions always have a BEST answer among the options. When in doubt, prioritize: (1) protecting the organization's objectives, (2) following established processes and frameworks, (3) communicating with and getting approval from appropriate stakeholders, and (4) documenting decisions. Avoid answers that skip steps, bypass governance, or make unilateral technical decisions without business context.