CRISC Exam Domains and Weights

Current CRISC domains and weights

ISACA's current CRISC exam content outline became available on November 3, 2025. It contains four job practice domains. The main change from the previous outline was the redistribution of two percentage points from Technology and Security to Risk Assessment. Candidates testing in 2026 should use the current outline and materials aligned to its task statements.

Risk Response and Reporting is the largest domain. The weights are useful when planning preparation, but they do not guarantee an exact number of questions from each area. They also do not create four independent pass marks. ISACA's Candidate Guide says the overall score is based on total scored items answered correctly and domain feedback is informational.

Domain 1: Governance

Governance establishes how the organization makes and oversees IT risk decisions. The outline includes strategy and objectives, organizational structure, roles and responsibilities, culture and ethics, policies and standards, business processes and resilience, and asset management. Risk governance topics include enterprise risk management, lines of defense, the organization's risk profile, appetite and tolerance, and applicable frameworks or obligations.

A candidate should be able to connect a technology risk to enterprise objectives. For example, an online service outage may affect revenue, customer service, contractual obligations, and reputation. Governance establishes who owns the service, which executive can approve risk treatment, and how risk is escalated. A security or risk professional may present analysis and recommendations; the organization defines who can accept the residual risk.

Questions may test whether policy, authority, or risk tolerance should be clarified before a control choice. A risk register does not establish risk appetite, and a technical team cannot necessarily accept business impact simply because it operates the system. Look for the governance gap the scenario actually describes.

Domain 2: Risk Assessment

Risk Assessment covers identifying events and constructing scenarios, understanding threats and vulnerabilities, assessing likelihood and impact, and analyzing inherent and residual risk. The outline includes threat modeling, vulnerability management, business impact analysis, risk registers, assessment concepts and standards, and analysis methods.

A risk scenario links a possible event to an asset or process and a business consequence. 'A critical API has a weakness' is not yet a complete risk description. Consider how it could be exploited, which service depends on it, what data or operations could be affected, existing safeguards, likelihood, and impact. Distinguish a vulnerability from the risk it creates.

Business impact analysis helps assess consequences if a process or service is disrupted. Inherent risk is exposure before considering controls; residual risk remains after controls are considered. A control is not effective merely because policy requires it. Use evidence such as test results, access records, incident history, or configuration review to evaluate control performance.

Domain 3: Risk Response and Reporting

This domain includes response choices, risk and control ownership, supplier and supply-chain risk, issues and exceptions, control frameworks and types, control design and implementation, testing, action plans, monitoring, metrics, and reporting. It is the broadest domain because it connects the assessment to the treatment and ongoing oversight.

Risk treatment commonly includes mitigation, acceptance, avoidance, or transfer. The correct response depends on risk criteria, business objectives, cost, obligations, and the decision maker's authority. Risk owner and control owner are not always the same person. The risk owner is accountable for the decision; control owners operate or monitor the safeguards. A CRISC professional may facilitate analysis and follow up on action plans.

Reporting should make data decision-useful. A key risk indicator can signal changing exposure; a key control indicator can describe control performance. Define what each metric measures, its source, owner, interval, threshold, and escalation. A dashboard with inconsistent data or hidden assumptions can create false confidence. The candidate should recognize when data must be validated before reporting a conclusion.

Supplier risk adds dependencies beyond the organization's direct control. Assess the service, data, access, concentration, and contractual obligations. Assign an internal owner, agree on requirements and evidence, monitor performance, and plan for disruption or exit. A supplier contract may transfer some financial risk but does not automatically remove the customer's responsibilities.

Domain 4: Technology and Security

Technology and Security connects technology practices to risk management and security frameworks. Topics include technology principles and roadmaps, enterprise architecture, operations such as change and incident management, the system development lifecycle, data lifecycle management, portfolio and project management, resilience, disaster response and recovery, and security awareness.

The CRISC perspective is not to memorize products. It is to understand how technology choices create or reduce exposure and how controls fit the organization's operating model. A new architecture might improve scalability while creating a third-party dependency. A change process may document approvals but still fail to validate deployment. A backup may exist but not meet recovery needs if restores are untested.

For development and projects, integrate risk and control requirements early enough to influence design. Assess changes to the environment, data, vendors, and dependencies. For operations, use asset, change, incident, and problem information to detect emerging risks. For resilience, compare recovery capability with business impact and accepted objectives.

A worked case across all four domains

A retailer plans to let a payment provider host a customer rewards database. Governance assigns the data owner and risk decision authority and defines requirements for service availability and data protection. Risk Assessment maps the data flows, provider access, threat scenarios, likelihood, impact, and existing safeguards. Risk Response and Reporting selects controls, clarifies responsibilities in the contract, tracks remediation, tests safeguards, and reports residual exposure. Technology and Security reviews architecture, identity integration, change practices, data retention, monitoring, and recovery.

Suppose later evidence shows that access reviews are incomplete. Risk Assessment evaluates which accounts and data are exposed. Response identifies an owner, immediate treatment, corrective action, and monitoring. Governance escalates the decision if residual risk exceeds tolerance. Technology and Security examines whether the identity integration and review process work as intended. The exam may focus on one domain, but the scenario can rely on concepts from several.

How to study the outline

Read the task statements beneath each domain rather than stopping at headings. For each task, write the decision, actor, evidence, and follow-up you should know. For example, risk treatment asks who owns the choice and how it will be monitored; reporting asks whether the data are valid and useful to the audience. This turns a syllabus into applied knowledge.

Give Risk Response and Reporting sustained time because it represents 32 percent of the exam, but do not ignore Governance, Risk Assessment, or Technology and Security. Cross-domain scenarios can make a candidate miss a question if they focus only on the technology mentioned in the stem. Ask whether the real question concerns authority, assessment, treatment/reporting, or technology practice.

Use mixed practice after reviewing each domain. Track errors by task and reasoning cause. If you repeatedly choose a control before clarifying the risk owner, study governance and response together. If you confuse a vulnerability with residual risk, work more assessment cases. If a metric is poorly defined, practise validation and reporting.

Common outline errors

• Using the former Risk Assessment 20% and Technology and Security 22% weights instead of the 2025 version.
• Treating weights as a guaranteed question count or a domain-specific passing score.
• Studying controls without learning risk ownership, assessment, treatment, and monitoring.
• Treating a vendor contract as proof that all risk has been transferred.
• Confusing a risk indicator with proof of an incident or control failure.
• Using generic IT knowledge without relating technology choices to business objectives and risk criteria.

The CRISC outline is a connected risk process. Governance sets objectives and authority, assessment describes exposure, response selects and monitors treatment, and Technology and Security applies the process to real systems and practices. Learn the current tasks, practise a clear decision path, and use the weights to allocate attention without inventing score rules.