CRISC Certified in Risk and Information Systems Control Exam Topics and Questions

Governance is where the CRISC exam establishes the foundation for everything else. Before you can assess or respond to risk, you need to understand the organizational machinery inside which risk lives: strategy, structure, culture, and the enterprise-wide frameworks that shape how decisions get made. At 26 percent of the exam, this is the domain where gaps in your understanding of how organizations govern IT risk will cost you the most marks.

– Strategy, structure, and the operating environment

Strategy, goals, and objectives matter here because risk only has meaning relative to what the organization is trying to achieve. An IT risk that threatens a low-priority process is not the same as one that threatens a revenue-critical one. Organizational structure and roles determine who owns decisions and who is accountable for outcomes. The exam tests whether you can read a structure and identify where accountability sits, not just name the roles.

Culture and ethics are less tangible but equally examinable. ISACA treats ethical behavior as a governance control, and the exam will present scenarios where the culturally expected response conflicts with the formally correct one. Policies and standards are the instruments through which governance is exercised day to day. Know how policies sit above standards and how standards sit above procedures, because hierarchy questions appear frequently.

Business processes and resilience, including DRP and BCP, are tested in the governance context because continuity planning is a governance responsibility before it is a technical one. Asset management closes this group: the exam asks you to connect asset classification to risk ownership.

– Enterprise risk governance and the frameworks that shape it

Enterprise Risk Management gives the exam its broadest canvas. ERM connects IT risk to the organization's overall risk posture, and CRISC candidates are expected to understand that IT risk does not exist in a silo. Questions in this space often present a scenario where an IT risk decision must be escalated or integrated with an ERM process.

Lines of defense is one of the most directly tested sub-topics in this domain. The three-lines model determines who identifies risk, who manages it, and who provides independent assurance. Mixing up the second and third lines is a common source of lost marks.

Risk profile captures the aggregate picture of risk at a point in time. Risk appetite defines how much risk the organization will accept in pursuit of objectives; risk tolerance defines the acceptable deviation from that appetite. These two are frequently conflated, and the exam exploits that confusion deliberately.

Risk frameworks, along with legal, regulatory, and contractual requirements, round out the domain. ISACA expects you to know how frameworks like COBIT relate to risk governance, and how regulatory obligations shape what risk responses are even permissible.

How GOVERNANCE is tested

At 26 percent, governance carries more weight than any other domain on the exam. Expect scenario-based items that place you inside an organization with a described structure, culture, or strategic context, then ask you to make a governance-level judgment. The trap in this domain is defaulting to technically sound answers that ignore the organizational layer. An answer that is correct in isolation often loses to one that accounts for the governance structure around it.

Lines of defense questions reward candidates who can assign a specific activity to the right line without hesitation. Risk appetite versus risk tolerance items reward precision: the two concepts are related but not interchangeable, and the exam will construct scenarios where only one applies.

Culture and ethics items are particularly difficult because the scenario often makes the wrong choice look reasonable. ISACA's position is consistent: formal governance obligations outweigh cultural norms when they conflict.

Items on policies and standards reward candidates who know the hierarchy and can apply it to a specific scenario. Reading a governance scenario carefully for clues about organizational structure before evaluating the options is the discipline this domain demands.

Where governance sets the organizational context, risk assessment is where you do the analytical work: identifying what can go wrong and determining how seriously to take it. This domain tests your ability to move from a business environment to a structured picture of threats, vulnerabilities, and risk scenarios, and then to quantify or qualify what you find. The analytical judgment required here is different from the policy-level thinking governance demands, and candidates who treat the two the same tend to drop marks in both.

– Identifying what can go wrong

Risk events are the starting point: discrete occurrences that, if they materialize, would affect the organization's objectives. The exam expects you to distinguish between a threat, a vulnerability, and a risk event, because conflating them leads to wrong responses in scenario questions.

Threat modeling and the threat landscape test whether you can categorize threats by source and type, and whether you can apply that categorization to a specific organizational context. ISACA does not reward abstract threat theory; it rewards applied identification.

Vulnerability management in the risk assessment context is about identification and prioritization, not remediation. The exam will test whether you know where vulnerability management sits in the risk lifecycle, and whether you can distinguish a vulnerability from a threat or a control gap.

Risk scenario development and evaluation is the most integrative sub-topic in this group. A well-constructed risk scenario connects a threat source to a threat event to an affected asset and an estimated impact. The exam tests whether you can evaluate a scenario for completeness and realism, not just whether you can name the components.

– Analyzing and quantifying what you find

Risk assessment concepts and standards give the exam its methodological backbone. ISACA expects familiarity with both qualitative and quantitative approaches, and with when each is appropriate. The exam does not ask you to perform complex calculations, but it does ask you to understand what a quantitative output means and when qualitative judgment is the more defensible choice.

Business Impact Analysis sits at the intersection of risk assessment and business continuity. In the CRISC context, BIA is a tool for understanding which processes are most critical to organizational objectives, and therefore which risks to prioritize. The exam tests BIA as an input to risk analysis, not as a standalone exercise.

The risk register is the artifact that captures all of this. Questions about the risk register test whether you know what belongs in it, who maintains it, and how it is used in decision-making.

Risk analysis methodologies and the distinction between inherent and residual risk close this group. Inherent risk is the exposure before controls; residual risk is what remains after. The exam tests whether you can apply that distinction in a scenario where a control has been partially implemented, which is where most candidates lose marks.

How RISK ASSESSMENT is tested

Risk assessment items at 22 percent demand analytical precision rather than definitional recall. The exam presents a scenario with a described environment, a threat or vulnerability, and asks you to make an assessment judgment: how likely, how severe, how to prioritize. Items reward candidates who apply a structured methodology rather than intuition.

The inherent versus residual risk distinction is a reliable source of difficult items. Scenarios will describe a partially controlled environment and ask you to characterize the remaining exposure. Candidates who have not internalized the distinction between the two will default to the wrong frame.

Threat modeling items reward the ability to match a threat source to the correct category and to identify which organizational assets are in scope. The exam is not testing memorized threat taxonomies; it is testing applied identification in context.

BIA items reward candidates who understand that criticality drives prioritization, not the other way around. Risk register questions reward process knowledge: who updates it, when, and under what conditions.

The most common failure mode in this domain is treating risk analysis as a purely technical exercise. ISACA consistently rewards answers that connect analytical outputs to business objectives and decision-making.

Risk response and reporting is the largest domain on the exam at 32 percent, and it earns that weight. Once you have assessed risk, you have to decide what to do about it, implement controls to do it, and then demonstrate to stakeholders that it is working. This domain spans three distinct activities: choosing and owning a response, designing and implementing controls, and monitoring and reporting on outcomes. Weakness in any one of the three will show up clearly in your score.

– Choosing a response and owning the outcome

Risk response options are the classic four: accept, avoid, mitigate, and transfer. The exam does not test whether you can name them; it tests whether you can select the right one given a specific risk profile, risk appetite, and cost constraint. Scenarios will be constructed so that more than one option appears defensible, and the strongest choice will be the one aligned to the organization's stated appetite and the residual risk target.

Risk and control ownership is where accountability is assigned. The exam distinguishes between the risk owner, who is accountable for the risk, and the control owner, who is responsible for the control that addresses it. These are not always the same person, and scenarios that conflate them are a deliberate trap.

Vendor and supply chain risk management tests whether you understand that third-party relationships extend your organization's risk boundary. The exam asks about due diligence, contractual risk transfer, and ongoing monitoring of vendor controls.

Issues, findings, exceptions, and exemptions management tests the lifecycle of a control gap: how it is documented, escalated, tracked, and closed. The distinction between an exception (a temporary deviation with approval) and an exemption (a permanent one) is a specific and frequently tested point.

– Designing and implementing controls

Control frameworks, types, and standards give CRISC candidates a structured vocabulary. The exam expects you to classify controls by type (preventive, detective, corrective) and by nature (manual, automated, physical). More importantly, it tests whether you can select the right type of control for a given risk scenario, not just define the categories.

Control design, selection, implementation, and analysis is the most technically demanding sub-topic in this group. Design questions test whether a proposed control actually addresses the identified risk, whether it is proportionate to the risk level, and whether it introduces new risks of its own. Analysis questions test whether an existing control is operating as intended.

Control testing methodologies round out this group. The exam asks about testing approaches, including walkthroughs, observations, and testing of operating effectiveness, and about when each is appropriate. Candidates often lose marks here by selecting a testing approach that is too light for the risk level described in the scenario.

– Monitoring, measuring, and communicating risk

Risk action plans track what was decided and whether it happened. The exam tests action plan content and governance: who approves them, who monitors progress, and what happens when a milestone is missed.

Data collection, aggregation, analysis, and validation underpin everything in this group. Without reliable data, risk metrics are meaningless. The exam tests whether you understand the quality requirements for risk data and the consequences of acting on data that has not been validated.

Risk and control metrics, including KRIs, KCIs, and KPIs, are heavily tested. KRIs measure exposure to future risk; KCIs measure how well a control is performing; KPIs measure operational performance more broadly. The exam will present a metric and ask you to classify it correctly, or present a scenario and ask which metric type is most appropriate.

Monitoring techniques and reporting techniques, including heatmaps, scorecards, and dashboards, are tested on fitness for purpose. A heatmap communicates risk magnitude to a board audience; a detailed control scorecard serves a different one. Emerging risk monitoring closes the domain and tests whether you can distinguish an early warning signal from a realized risk event.

How RISK RESPONSE AND REPORTING is tested

At 32 percent, this domain will determine whether you pass. Items here are almost entirely scenario-based, and they are constructed to test judgment across all three sub-domains in combination. A scenario might describe a risk that has been assessed, ask you to select a response, and then ask a follow-up about the control type that would implement it.

The response options sub-topic rewards candidates who can read organizational context: the same risk might call for mitigation in one organization and acceptance in another, depending on appetite and cost. Items that describe a control failure reward candidates who know the difference between a control deficiency, an exception, and an exemption, and who understand the escalation path for each.

Metric classification items are precise and unforgiving. Mixing up a KRI and a KCI in a scenario question costs the mark entirely. Reporting technique items reward candidates who match the communication format to the audience and the decision being made.

The most common failure mode in this domain is treating risk response as purely a technical control problem. ISACA consistently rewards answers that account for ownership, stakeholder communication, and the ongoing monitoring obligation, not just the initial control selection.

After three domains focused on governance, assessment, and response, technology and security is where the exam tests whether you can apply all of that to a specific technical and operational context. At 20 percent, it is the smallest domain by weight, but it covers a wide surface: from enterprise architecture and SDLC to data privacy and security awareness. Candidates with a strong technical background sometimes underestimate this domain because the questions are not about technical depth; they are about applying risk and security principles to technology decisions.

– Technology principles, architecture, and the development lifecycle

Technology principles are the foundational concepts that underpin sound IT risk management: separation of duties in system design, least privilege, defense in depth. The exam tests these as risk principles applied to technology, not as security configurations.

Technology roadmaps and enterprise architecture matter because risk management must align with where the organization's technology is going, not just where it is today. EA provides the structured view of systems, data, and dependencies that makes risk assessment tractable at scale. The exam tests whether you understand EA as a risk management input.

Operations management, spanning change management, asset management, DevOps, problem management, and incident management, is tested through the lens of risk. Change management is the most frequently examined: unauthorized or poorly controlled change is one of the most common sources of operational risk. The exam will present a change scenario and ask you to identify the risk control point.

SDLC is tested as a risk integration question: where in the development lifecycle should risk assessment occur, and what happens to residual risk when a system moves from development to production? Data lifecycle management extends the same logic to data: classification, retention, and disposal all carry risk implications that the exam will surface in scenario form.

– Portfolio management, resilience, and emerging technology risk

Portfolio and project management, including Agile approaches, is tested because project risk is a distinct category with its own vocabulary. The exam asks about risk identification in project contexts and about how Agile's iterative delivery model changes the risk profile of a development program. Candidates unfamiliar with Agile risk dynamics will find these items harder than expected.

Technology resilience and disaster response and recovery connects back to the BCP and DRP material from the governance domain, but here the focus is on the technology layer: recovery time objectives, recovery point objectives, and the controls that make recovery possible. The exam tests whether you can match a resilience requirement to the right technical control.

Emerging technologies, including cloud, AI, and IoT, are tested as risk scenarios rather than as technical specifications. The exam asks what new risks these technologies introduce and how existing risk frameworks apply to them. You do not need deep technical knowledge of the technologies themselves; you need to recognize the risk categories they create.

– Information security principles applied to risk

Security concepts, frameworks, and standards give this domain its structure. ISACA expects familiarity with frameworks such as ISO 27001 and NIST, but the exam tests their application to risk management decisions, not their content in isolation. A question about a security framework will ask you to use it to make a risk judgment, not to recite its components.

Security and risk awareness training is tested as a control. The exam asks about the design of awareness programs, the populations they target, and how their effectiveness is measured. Awareness training is a soft control, and the exam will present scenarios where it is the appropriate response and scenarios where it is insufficient on its own.

Data privacy and data protection principles close the domain. Privacy risk is a distinct category with legal and regulatory dimensions. The exam tests whether you understand how privacy obligations affect risk assessment and response decisions, particularly in scenarios involving personal data breaches or cross-border data transfers. Candidates who treat privacy as purely a compliance matter rather than a risk category will lose marks in this sub-topic.

How TECHNOLOGY AND SECURITY is tested

Technology and security items test the application of risk principles to a technical or operational context. The scenarios describe a technology environment, a decision point, or an incident, and ask you to make a risk-informed judgment. Technical knowledge alone does not win marks here; the item rewards the candidate who filters the technical detail through a risk lens.

SDLC and change management items reward candidates who can identify the correct point in a process where a risk control should be applied. Getting the timing right matters: a control applied after a risk has materialized is not a preventive control.

Emerging technology items reward risk categorization. The exam does not require you to know how a blockchain works; it requires you to recognize which risk categories a blockchain deployment introduces and how to address them within an existing framework.

Security awareness items reward candidates who treat training as a control with measurable effectiveness, not as a box to check. Data privacy items reward candidates who connect a privacy principle to a specific risk response, particularly in breach scenarios.

The most common failure mode in this domain is over-indexing on technical detail. ISACA rewards the risk management frame consistently, and the strongest answer in a technology scenario is almost always the one that prioritizes risk ownership and control alignment over technical precision.