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.
CRISC: 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.
Official exam sources
The domain names and weightings on this page follow the published exam blueprint. Each source below records what it confirmed and when it was read, so the split can be checked rather than taken on trust.
- ISACA - CRISC exam content outlinelink and content verified 8 September 2026"The CRISC exam consists of 150 questions covering 4 job practice domains" and four weights totalling 100%: Governance 26%, Risk Assessment 22%, Risk Response and Reporting 32%, Technology and Security 20%. THIS CORRECTED A DEFECT - see the conflict note. Read over the DevTools protocol: isaca.org is a single-page app whose content arrives after the initial paint, so the page is navigated, given a fixed wall-clock wait and read from document.innerText. Public page, no sign-in.
- ISACA - get CRISC certifiedlink and content verified 8 September 2026"Have three or more years of CRISC professional work experience across at least two of the four CRISC domains", gained within the 10-year period before applying - this guide's three years and two-of-four domains, exactly. ISACA separates sitting the exam from earning the certification, and this guide has that right: "The exam is open to anyone who has an interest in information security", while certification needs verified work experience gained within the 10-year period before applying, and candidates have five years from the passing date to apply.
Settled, and recorded here. Our mock weights for domains 2 and 4 were SWAPPED against ISACA's outline, and have been corrected: Risk Assessment is 22% and Technology and Security 20%, where our practice mocks drew 20% and 22%. The question bank was never wrong - 218 / 186 / 269 / 169 of 842 questions is 25.9 / 22.1 / 31.9 / 20.1, which is ISACA's split - so only the draw disagreed, pulling two points too few from Risk Assessment and two too many from Technology and Security. Separately, this guide says there are "no substitutions or waivers" for the CRISC experience requirement; ISACA's page does not say so either way, so that sentence is unverified.