Domain 1: Governance
- Accountability for outsourced functions stays with the organization; a third party takes on contractual responsibilities but cannot relieve the enterprise of accountability to its stakeholders and regulators.
- The board sets and formally approves the overall risk appetite (reflecting its ultimate accountability), and senior management translates that appetite into measurable risk tolerance ranges for specific objectives and processes.
- In the three lines model, external audit is NOT a line; the three internal lines are operational management, oversight/risk functions, and internal audit, while external audit provides independent assurance from outside.
- The risk owner is accountable for ensuring a specific risk is managed to an acceptable level and for its treatment; the control owner is accountable only for a specific control, so the two roles often rest with different people.
- Persistent resourcing shortfalls should be escalated to leadership with a documented business case, not resolved by quietly reducing risk-work scope or quality.
- Document hierarchy: a policy states intent, a standard specifies mandatory measurable requirements that operationalize the policy, and procedures give step-by-step instructions approved at the department or process-manager level.
- A risk universe is the comprehensive inventory of risk categories used to ensure identification and assessment cover the enterprise's full scope.
- Out-of-cycle policy/governance review is triggered by material regulatory change, a merger or acquisition, entering a new line of business, or a material control failure - not by waiting for the scheduled cycle.
- Systems feeding data into a public company's quarterly financial statements fall under SOX internal control over financial reporting (ICFR).
- A data owner is accountable for a data asset while a data steward manages day-to-day data quality, definitions, and consistent usage on the owner's behalf.
- Board-level risk reporting should present aggregated, appetite-relative themes rather than granular operational detail, and asset inventories should record owner, classification/criticality, and location.
- Key risk indicators and their thresholds must be reviewed and adjusted as the risk environment changes, since fixed indicators lose relevance over time.
Domain 2: IT Risk Assessment
- A well-formed IT risk scenario specifies the actor (threat source), the threat type/event, the affected asset, and the timing/duration, giving enough detail to assess likelihood and impact.
- Recovery Time Objective (RTO) is the target duration to restore a process after disruption; Recovery Point Objective (RPO) is tolerable data loss/currency, and Maximum Tolerable Downtime (MTD) is the outer limit RTO must stay within.
- Consolidating multiple critical applications or business units onto a single cloud region, vendor, or key person creates concentration risk, where one failure causes a correlated enterprise-wide impact.
- Current (residual) risk reflects exposure that exists right now under the controls actually operating; a well-designed control that has never been executed fails on operating effectiveness, not design.
- Vulnerability scans give broad technical inventory, architecture reviews reveal design weaknesses, and penetration tests confirm which vulnerabilities are realistically exploitable - together forming a rounded technical picture.
- Risk velocity (how quickly a scenario could hit the organization) is a valid factor for ranking scenarios that have similar likelihood and impact.
- Monte Carlo simulation runs many randomized iterations across ranges of input assumptions to produce a distribution of possible outcomes for quantitative analysis.
- Top-down scenario development starts from business objectives and senior management's view of what could threaten goals; industry/threat reports act as benchmarks prompting the enterprise to test whether similar scenarios apply to it.
- Root cause analysis traces an incident back through contributing factors, and organizing causes into categories such as people, process, technology, and environment prevents premature fixation on one cause.
- Common analysis pitfalls to guard against include cognitive bias, poor data quality, and false precision; cross-functional participation and structured facilitation improve scenario completeness.
- A significant change in the environment (such as migrating backup infrastructure to a new provider) undermines prior audit conclusions and calls for fresh evidence.
- The risk owner is accountable for keeping their risk register entries accurate and current.
Domain 3: Risk Response and Reporting
- The four risk response options are mitigate (treat), transfer/share, avoid, and accept; when a control's cost far exceeds the risk reduction, a cheaper alternative or accepting the residual risk is more defensible.
- Control types by function: preventive (stops an event, e.g. pre-hire screening), detective (identifies an event, e.g. a SOC), deterrent (discourages an actor, e.g. warning signage), and corrective; physical controls include fencing, guard patrols, and biometric readers.
- A compensating control is justified only when the primary control is technically infeasible on constrained systems or its cost is clearly disproportionate to the risk reduction achieved.
- A key risk indicator must be measurable - expressible in consistent quantifiable terms that allow comparison across periods - and monitored more frequently than the longer-term strategic risk appetite.
- Continuous control monitoring uses automated testing to provide ongoing assurance about control effectiveness between periodic audit cycles.
- Predefined, objective escalation thresholds (a defined loss amount, control-failure severity, or risk-rating change) remove ambiguity about when an event must be escalated outside the normal cycle.
- A recurring pattern of missed remediation deadlines without meaningful progress is the signal to escalate; when a date will slip, the control owner should formally request a documented revised date rather than let the record go stale.
- Third-party risk: contract renewal is a natural trigger to reassess a vendor's risk profile, a breach-notification clause sets an explicit disclosure clock (e.g. 24 or 72 hours), and routine reliance on an independent SOC 2 Type II report reserves onsite audits for elevated-risk cases.
- Confirmed reduction in likelihood or impact from an effective control should be reflected by updating that risk's residual rating.
- Reporting must flag appetite breaches together with the response-plan status so management can act; a heat map alone lacks the detail to justify specific treatment decisions.
- Internal audit independence is strengthened when it reports functionally to the audit committee or board rather than to the management whose processes it reviews.
- Reported control status cannot be trusted while an underlying data-feed issue is unresolved, and a maturity gap between regions points to a need to standardize the process enterprise-wide.
Domain 4: Information Technology and Security
- Contractual data portability and defined exit-assistance provisions directly reduce cloud vendor lock-in by giving a practical path to migrate away from a provider.
- Incident management restores service during an outage, while problem management investigates root cause and drives permanent fixes to prevent recurrence.
- Data should be classified at the point of creation so downstream access, storage, and transmission controls match its true sensitivity from the start.
- Least privilege grants only the access a role requires; a broad department template over-provisions entitlements, which differs from segregation-of-duties concerns over conflicting tasks.
- Shared generic or fixed factory administrator credentials prevent actions from being traced to an individual and let anyone who knows them access every device, undermining accountability at scale.
- Because public cloud infrastructure is multi-tenant, a failure of the logical controls that separate tenants could expose or affect another customer's workload.
- Defense in depth layers independent protections at the network, host, and application levels so no single control failure is catastrophic.
- The incident response lifecycle relies on a preparation phase (trained people, defined roles, ready tools) and a lessons-learned review that captures what worked and failed to improve plans and controls.
- Aggregating logs into a centralized platform (SIEM) enables correlation of related events and improves detection; a cloud access security broker (CASB) surfaces connections to unsanctioned cloud (shadow IT) services.
- Environmental controls such as redundant power with UPS and water-detection sensors protect data center availability from physical hazards.
- Involving risk and security during target-state architecture design lets control requirements shape the design when changes are cheapest, avoiding later technical debt.
- Layered protection over third-party remote access to sensitive systems combines multi-factor authentication, device security-posture verification, and session recording.
ISACA CRISC (Certified in Risk and Information Systems Control) exam tips
- CRISC answers are almost always about accountability and appetite: when a question asks 'who is responsible' or 'what should you do first,' favor the risk owner, senior management, or the board over a technician or a documentation task.
- Distinguish the paired terms the exam loves to test: risk owner vs control owner, appetite vs tolerance, RTO vs RPO vs MTD, incident vs problem management, and inherent vs residual (current) risk.
- When two answers both look correct, pick the one that addresses the root cause or provides decision-useful information to management, not the one that merely restores service or reports a symptom.
- For control questions, first classify by function (preventive, detective, deterrent, corrective) and by type (physical, technical, administrative) before choosing - the wording usually maps cleanly to one category.
- Read every scenario as a business-risk decision, not a purely technical one: the best answer aligns the response with risk appetite, cost-benefit, and stakeholder accountability.
Study guide FAQ
How many questions is the CRISC exam and how long do I get?
The CRISC exam has 150 multiple-choice questions and you are given 4 hours (240 minutes) to complete it.
What score do I need to pass CRISC?
ISACA uses a scaled score from 200 to 800, and you need a 450 or higher to pass. The scaled score is not a simple percentage of questions correct.
What are the four CRISC domains and their weights?
The domains are Governance (26%), IT Risk Assessment (20%), Risk Response and Reporting (32%), and Information Technology and Security (22%). Risk Response and Reporting carries the most weight.
Does CRISC require work experience to become certified?
Yes. Passing the exam is separate from certification; ISACA requires a minimum of three years of cumulative relevant experience across at least two CRISC domains, and there are no substitutions or waivers for this requirement.