ISACACRISC68 concepts

CRISC Cheat Sheet

Quick reference for the ISACA Certified in Risk and Information Systems Control exam.

Quick Navigation

Governance Foundations (Domain 1 — 26%)Risk Assessment Concepts (Domain 2 — 22%)Risk Assessment Frameworks & Standards Risk Treatment Options (Domain 3 — 32%)Controls Design & Testing (Domain 3 — 32%)KRIs, KPIs & Risk Reporting (Domain 3 — 32%)Technology & Security Controls (Domain 4 — 20%)Data Lifecycle & Enterprise Architecture BCP / DRP & Resilience Key Exam Distinctions & Traps

Governance Foundations (Domain 1 — 26%)

Enterprise Risk Management (ERM): A holistic, organization-wide framework that integrates all risk types (strategic, operational, financial, IT, compliance) into a single coordinated approach aligned with business strategy.
Risk Appetite vs Risk Tolerance: Risk appetite is the BOARD-level strategic statement of maximum acceptable risk; risk tolerance is the OPERATIONAL variation allowed around specific targets — tolerance must always fall within appetite boundaries.
Three Lines of Defense: 1st line: business/operational management owns and manages risk daily; 2nd line: risk management and compliance provide oversight and policy; 3rd line: internal audit provides independent assurance on all of the above.
Risk Profile: A point-in-time snapshot of an organization's overall risk exposure across all domains, used to communicate the aggregate risk posture to the board and senior management.
COBIT Framework: ISACA's IT governance framework aligning IT goals with business objectives through governance and management domains; the primary IT governance reference on the CRISC exam.
ISO 31000: International standard providing principles, framework, and process guidelines for risk management applicable to any risk type in any organization; the foundational risk management standard CRISC aligns with.
COSO ERM Framework: Enterprise-wide risk management framework focused on aligning risk with strategy and performance; complements COBIT at the enterprise governance level.
Organizational Governance vs Risk Governance: Organizational governance covers strategy, structure, culture, policies, and asset management; risk governance covers ERM, three lines of defense, risk profile, appetite/tolerance, and legal/regulatory requirements.

Risk Assessment Concepts (Domain 2 — 22%)

ALE = SLE x ARO: Annual Loss Expectancy equals Single Loss Expectancy (asset value x exposure factor) multiplied by Annual Rate of Occurrence; the core quantitative risk formula tested directly on the exam.
Inherent Risk vs Residual Risk: Inherent risk is the raw exposure BEFORE any controls are applied; residual risk is what REMAINS after controls — residual risk must fall within risk tolerance or trigger additional treatment.
Risk Assessment Methodologies: Qualitative: High/Medium/Low categories, fast and subjective; Quantitative: dollar values using ALE, precise but data-intensive; Semi-quantitative: numerical scales without full monetary conversion — a hybrid approach.
Risk Register: A living document recording each risk's description, owner, likelihood, impact, inherent rating, controls, residual rating, treatment decision, and status — must be continuously updated, not a one-time exercise.
Risk Scenario Development: Creating realistic scenarios combining threat sources, vulnerabilities, assets, and business impact to drive risk assessment and treatment decisions — distinct from threat modeling which focuses only on attack vectors.
Business Impact Analysis (BIA): Identifies critical business processes and assesses the business impact (revenue, reputation, legal liability) of disruption over time; BIA must be completed BEFORE developing BCP or DRP.
MTD / RTO / RPO: Maximum Tolerable Downtime: longest acceptable outage; Recovery Time Objective: target time to restore operations; Recovery Point Objective: maximum acceptable data loss measured in time — all established by BIA.
Vulnerability Management: The continuous process of identifying, classifying, prioritizing, remediating, and verifying weaknesses in systems, processes, and people — feeds directly into risk scenario development and the risk register.

Risk Assessment Frameworks & Standards

NIST SP 800-30: NIST Guide for Conducting Risk Assessments — defines risk factors (threat sources, threat events, vulnerabilities, predisposing conditions, likelihood, impact) and the risk assessment process used across federal and private sectors.
NIST Risk Management Framework (SP 800-37): A 7-step lifecycle framework (Prepare, Categorize, Select, Implement, Assess, Authorize, Monitor) for integrating security and risk management into the system development lifecycle.
ISO 27005: International standard specifically for information security risk management, providing detailed guidance on the risk assessment and treatment process complementing ISO 31000.
FAIR Framework: Factor Analysis of Information Risk — a quantitative model that decomposes risk into measurable factors and expresses results in financial (dollar) terms using a structured probabilistic model.
OCTAVE: Operationally Critical Threat, Asset, and Vulnerability Evaluation — a self-directed, organization-focused risk assessment methodology developed by Carnegie Mellon for identifying operational risk.
Threat Landscape Analysis: Understanding and monitoring external threats (cyber attacks, natural disasters, regulatory changes) and internal threats (insider risk, human error, process failures) to keep risk scenarios current.

Risk Treatment Options (Domain 3 — 32%)

Mitigate: Implement controls to reduce the likelihood or impact of a risk event; the organization retains the risk but reduces it to within acceptable tolerance — most common risk response.
Transfer: Shift the financial impact of a risk to a third party via insurance, outsourcing, or contractual arrangement; the risk still EXISTS — reputational and regulatory responsibility typically remain with the organization.
Accept: Formally acknowledge the risk and decide to bear it without additional treatment — requires a DOCUMENTED, AUTHORIZED decision by a risk owner, not passive inaction or ignorance.
Avoid: Eliminate the activity or condition that creates the risk entirely (e.g., discontinue a product line or market exit); chosen when the risk is too high relative to the business benefit.
Risk Treatment Selection Criteria: Select treatment based on: cost-benefit analysis (treatment cost vs potential loss), alignment with risk appetite, feasibility, and whether residual risk after treatment falls within risk tolerance.
Risk and Control Ownership: Risk owners (typically business process owners — 1st line) are accountable for managing risk in their area; control owners ensure specific controls operate effectively; ownership must be formally assigned.

Controls Design & Testing (Domain 3 — 32%)

Control Types by Function: Preventive: stop events from occurring (access controls, encryption); Detective: identify events that have occurred (audit logs, IDS); Corrective: restore after events (patch, backups); Compensating: alternative when primary is impractical; Deterrent: discourage events.
Control Design Principles: Controls must be appropriate to the risk level, cost-effective relative to the potential loss, aligned with business objectives, and sustainable to operate over time without excessive burden.
Control Testing Methods: Self-assessment (CSA): management evaluates own controls, builds ownership; Compliance testing: confirms controls operate as documented; Substantive testing: verifies data accuracy; Penetration testing: simulates real attacks; Continuous monitoring: real-time automated assessment.
Control Effectiveness vs Control Design: Control design proves a control is appropriate for the risk; control effectiveness (via testing) proves it actually works in practice — a well-designed but untested control provides false assurance.
Control Self-Assessment (CSA): Technique where management and staff evaluate control effectiveness within their own area; advantages include ownership and risk awareness; limitations include bias and potential skill gaps.
NIST SP 800-53: A comprehensive catalog of security and privacy controls organized into families (Access Control, Incident Response, etc.); widely referenced as a control selection and implementation framework.

KRIs, KPIs & Risk Reporting (Domain 3 — 32%)

Key Risk Indicators (KRIs): FORWARD-LOOKING metrics providing early warning when risk exposure is approaching or exceeding defined thresholds — they signal potential future problems before they materialize.
Key Performance Indicators (KPIs): BACKWARD-LOOKING metrics measuring how effectively processes or controls have performed against targets — they reflect past results, not future risk signals.
Key Control Indicators (KCIs): Metrics specifically measuring the effectiveness of individual controls; a strong KCI shows a control is working; strong KPIs do NOT guarantee low risk — they measure different things.
KRI Design Requirements: Effective KRIs must be: measurable with reliable data, relevant to specific risk appetite/tolerance boundaries, capable of providing early warning with sufficient lead time, and linked to a defined threshold that triggers a response.
Risk Reporting by Audience: Board: strategic risk summaries tied to business objectives and risk appetite; Management: operational risk dashboards with KRI trends; Regulators: compliance-focused reports meeting mandatory disclosure requirements.
Emerging Risk Identification: Ongoing process of scanning the internal and external environment for new or evolving risks from technology shifts, regulatory changes, geopolitical events, and market disruptions — feeds the risk register.
Third-Party Risk Management Lifecycle: Five phases: vendor selection/due diligence, contract requirements (SLAs, right-to-audit, data protection clauses), onboarding controls, ongoing monitoring/periodic reassessment, and exit/offboarding strategy.

Technology & Security Controls (Domain 4 — 20%)

Zero Trust Architecture: Never trust, always verify — every access request is authenticated and authorized regardless of network location or prior session; implemented via micro-segmentation, least privilege, and continuous validation.
Recovery Site Types: Hot site: fully operational, data replicated in near-real-time, highest cost, shortest RTO (hours); Warm site: infrastructure ready but data must be loaded, moderate cost/RTO (hours to days); Cold site: facility only, lowest cost, longest RTO (days to weeks).
DR Testing Methods: Tabletop: discussion-only walkthrough; Walkthrough/checklist: review plan documentation; Simulation: role-play without actual failover; Parallel test: activate recovery site while production runs; Full interruption: actual cutover to recovery site — most disruptive but highest assurance.
SDLC Security Integration: Security requirements must be addressed at EVERY SDLC phase (requirements, design, development, testing, deployment, maintenance) — vulnerabilities caught late in testing cost exponentially more to fix than those caught in requirements.
Cloud Shared Responsibility Model: Cloud provider secures the infrastructure (hardware, hypervisor, facilities); customer is responsible for data classification, access controls, configurations, and applications — data sovereignty and jurisdiction must be assessed.
Change Management Process: All changes — including emergency changes — must follow: request, risk assessment, approval/rejection, implementation, post-implementation review, and closure; skipping risk assessment is never acceptable.
Emerging Technology Risks: Cloud: shared responsibility gaps, data sovereignty; AI/ML: bias, transparency, adversarial manipulation; IoT: expanded attack surface, patch complexity; Blockchain: immutability challenges, key management; DevSecOps: pipeline security, dependency risks.

Data Lifecycle & Enterprise Architecture

Data Lifecycle Management Stages: Creation, classification, storage, use, sharing, archival, and destruction — privacy and security controls must be applied at each stage appropriate to the data's classification level.
Data Classification: Assigns sensitivity labels (e.g., Public, Internal, Confidential, Restricted) to data to determine which controls, access rights, retention periods, and destruction methods apply.
Secure Data Destruction: Methods must match classification level: deletion/overwrite for low-sensitivity, cryptographic erasure for encrypted data, degaussing or physical destruction for highly sensitive media.
Enterprise Architecture Frameworks: TOGAF and Zachman provide structured approaches to aligning IT architecture with business strategy — architecture decisions (cloud vs on-premise, centralized vs distributed) directly create risk trade-offs that must be assessed.
IT Operations Risk Areas: Change management, configuration management, patch management, release management, and incident management processes are all sources of operational IT risk requiring controls and monitoring.
Project Risk Management: Identifies and manages risks specific to IT projects (scope creep, resource constraints, technology uncertainties, vendor dependencies); project risks are escalated to the enterprise risk register when they exceed project-level tolerance.

BCP / DRP & Resilience

BCP vs DRP: Business Continuity Plan covers people, processes, facilities, and technology to maintain operations during any disruption; Disaster Recovery Plan is IT-specific and is a SUBSET of BCP — DRP is contained within BCP.
BIA → BCP → DRP Sequence: BIA MUST be completed first to identify critical processes and establish MTD/RTO/RPO; BCP is then developed using BIA output; DRP is developed as a component of BCP to support identified IT recovery priorities.
BIA = Business Impact, Not Technical Impact: BIA measures disruption impact in business terms — revenue loss, regulatory fines, reputational harm, customer attrition — NOT system downtime metrics alone; confusing technical metrics with business impact is a common exam error.
BCP / DRP Testing Methods: Tabletop: discussion only, no activation; Walkthrough: review documentation; Simulation: role-play scenarios without actual failover; Parallel: activate recovery site while production continues; Full interruption: actual cutover — most disruptive, highest assurance; tests must be conducted regularly.
Incident Response Plan (IRP) vs DRP: IRP focuses on containing and eradicating a security incident (e.g., breach, ransomware) while the environment is still active; DRP activates after a disruption to restore IT operations — IRP may trigger DRP but they are separate plans.
BCP / DRP Plan Maintenance: Plans must be reviewed and updated after every significant change (new systems, org restructuring, regulatory change) and after each test or real activation — outdated BCP/DRP is a critical risk in itself.

Key Exam Distinctions & Traps

Management Mindset vs Technical Mindset: CRISC always selects the management/governance answer over the technical implementation answer — when multiple options seem correct, choose the one a risk manager or executive would take, not an engineer.
Risk Transfer Does Not Eliminate Accountability: Purchasing insurance or outsourcing a process shifts the financial impact but reputational risk and regulatory/legal responsibility typically remain with the originating organization.
Risk Acceptance Requires Authorization: Accepting a risk is NOT the same as ignoring it — acceptance requires a formal, documented decision signed off by an authorized risk owner; undocumented inaction is a control failure.
Residual Risk Triggers More Action: If residual risk after controls still exceeds tolerance, the FIRST action is to escalate to management for a formal decision (additional controls, transfer, or documented acceptance) — never unilaterally raise tolerance.
Policies Require Enforcement: Documented policies that are not enforced are ineffective — when staff ignore existing policies, the root cause is typically a cultural issue requiring leadership commitment, not stronger policy language.
Third-Party Risk Continues Post-Contract: Vendor risk management does not end at contract signing — ongoing monitoring, periodic reassessment, and defined exit procedures are required throughout the entire vendor relationship lifecycle.
Three Lines ≠ Three Separate Teams: The three lines of defense is a MODEL for separating risk functions, not a headcount requirement — in smaller organizations, the same people may fulfill multiple line responsibilities, but the FUNCTIONS must remain operationally distinct.
Hot Site = Highest Cost, Shortest RTO: The cost-vs-recovery-time trade-off is a frequent exam topic: hot site costs the most but recovers fastest; cold site costs the least but takes the longest to activate — match selection to BIA-defined RTO.

Ready to test yourself?

Start a timed CRISC mock exam or review practice questions by domain.