CRISC: the full course

Most CRISC questions have two or three plausible options. A security engineer, an auditor and a risk practitioner would each pick differently. The exam wants the risk practitioner's answer: understand and assess the risk, then help the owner choose a response.

1. 1Learn the risk life cycle; most questions sit at one stage of it.
2. 2For wrong answers, ask: which stage did that option skip?
3. 3Study by weight: Domain 3 alone is 32% of the exam.
4. 4Time: about 1.5 minutes per question; flag and return.
5. 5Answer every question; there's no penalty for guessing.

IT risk is the risk that technology stops the business reaching its goals. A risk practitioner who doesn't know the goals can't tell which IT risks matter. That's why understanding strategy and objectives is the first step in every IT risk activity.

1. 1Revisit the risk profile and top risks.
2. 2Check whether risk appetite still fits.
3. 3Reprioritise risk responses and resources.
4. 4Update risk scenarios for new products, markets or technology.

1. 1Unclear reporting lines: risks escalate to nobody.
2. 2Overlapping roles: everyone assumes someone else owns it.
3. 3Conflicts of interest: risk reports filtered by those affected.
4. 4Fix with a RACI, named owners and an independent risk function.

The risk owner is the person accountable for managing a risk, with the authority and budget to act on it. It's usually the business manager whose process or objectives the risk threatens, not the person who runs the technology.

1. 1Understand the risk and its impact on their objectives.
2. 2Choose a response from the options offered.
3. 3Accept residual risk within their authority.
4. 4Fund and track treatment plans.
5. 5Report status and escalate when needed.

Segregation of duties splits a task so that no single person can both carry it out and hide a mistake or fraud. It's one of the oldest and most effective controls against insider risk.

Risk culture is how people actually treat risk when no rule tells them what to do: whether they raise problems, take shortcuts or ask before acting. It decides whether policies work in practice.

1. 1Explain what IT risk means in each role.
2. 2Show how to report risks and incidents, simply.
3. 3Use real examples from the organisation and its sector.
4. 4Repeat regularly; measure behaviour, not attendance.

Risk reports guide decisions worth millions. If ratings are softened to please someone, or risks quietly dropped, the board decides on false information. The value of the risk function depends on its honesty.

1. 1 Ask for new evidence
2. 2 Re-assess objectively
3. 3 Document both views
4. 4 Escalate if unresolved

1. 1Protect confidential information; don't use it for gain.
2. 2Declare conflicts of interest; step back if needed.
3. 3Take on only work you're competent to do.
4. 4Decline gifts that could affect objectivity.

When the board says it has a low appetite for data loss, the policy framework is how that becomes real: a data protection policy, encryption standards and handling procedures. Without it, appetite stays a statement on paper.

1. 1Approved by senior management.
2. 2Short, clear and technology-neutral.
3. 3A named owner and a review date.
4. 4Realistic: people can actually follow it.
5. 5Supported by standards, procedures and an exception process.

Sometimes a system or process can't meet a policy, for a good reason. An exception lets that happen safely: the risk is assessed, compensating controls are added, the owner accepts what's left, and it expires on a set date.

A server failing only matters because of what stops when it fails. Business process review links IT assets to the work they support, so the risk practitioner can judge impact in business terms rather than technical ones.

1. 1End-user spreadsheets in critical calculations.
2. 2A single expert who knows how a system works.
3. 3Suppliers and cloud services in the chain.
4. 4Shared infrastructure such as identity and DNS.

1. 1Automated discovery on networks and cloud accounts.
2. 2Business process reviews and interviews.
3. 3Procurement and contract records.
4. 4Data discovery for sensitive information.

1. 1Link the inventory to change management and procurement.
2. 2Reconcile automated discovery regularly.
3. 3Require owners to confirm their assets periodically.
4. 4Track disposals with certificates of destruction.

Enterprise risk management looks at all the organisation's risks together, strategic, financial, operational, compliance and technology, and manages them in line with strategy and the board's appetite. Its aim is to help the organisation achieve its objectives, not just avoid losses.

1. 1One risk language and common scales.
2. 2IT risks compete fairly for attention and funding.
3. 3Concentrations across categories become visible.
4. 4Decisions weigh technology risk alongside other risks.

IT talks about vulnerabilities and outages; the board talks about revenue, customers and regulators. The practitioner translates technical findings into business impact, and business priorities into risk criteria IT can work with.

1. 1Question ratings that don't match evidence.
2. 2Ask what assumptions sit behind an estimate.
3. 3Compare with incidents, industry data and peer experience.
4. 4Escalate material disagreements; don't silently accept them.

1. 1First line owns risk and runs controls.
2. 2Second line sets method, monitors and challenges, but doesn't own.
3. 3Third line stays independent; it doesn't design or run controls.
4. 4All coordinate so effort isn't duplicated and gaps don't appear.

A framework gives everyone the same method, the same words and the same scales. That's what lets risks from different parts of the organisation be compared, and lets results be repeated next year.

1. 1Fit with regulation and customer expectations.
2. 2Size and maturity of the organisation.
3. 3Alignment with existing ERM and IT governance.
4. 4Ability to apply it consistently.

Most CRISC 'FIRST' and 'NEXT' questions are about this sequence. You can't evaluate a risk you haven't analysed, or choose a response before you know whether the risk exceeds appetite.

1. 1Reassess on significant change: new systems, suppliers, regulations.
2. 2Feed incidents and audit findings back into identification.
3. 3Monitor KRIs between formal assessments.
4. 4Communicate results to owners and stakeholders throughout.

1. 1Evaluate each risk: within, near or beyond appetite?
2. 2Choose responses that bring risk within appetite.
3. 3Escalate risks beyond appetite to the right level.
4. 4Report the risk profile against appetite to the board.

1. 1 Collect risks from the register
2. 2 Group by category and business area
3. 3 Aggregate and look for concentrations
4. 4 Compare with appetite
5. 5 Show trends and top risks

Ten 'low' risks on the same customer platform may add up to one significant exposure. Looking at the profile by system, process or supplier shows concentrations that a list of individual risks hides.

Every opportunity carries risk. Refusing all risk means missing opportunities; taking risk blindly means unexpected losses. Risk-based decisions sit in between: deliberate risk-taking, within the appetite the board set.

1. 1The options, including doing nothing.
2. 2Benefits and costs of each.
3. 3Residual risk of each, compared with appetite.
4. 4Who has authority to decide.

Non-compliance has a likelihood and an impact: fines, lost licences, lost contracts and reputational damage. It goes in the register and is assessed, prioritised and treated like any other risk, compared with the organisation's appetite.

1. 1Identify which laws apply where data and customers are.
2. 2Build a common control baseline that meets shared requirements.
3. 3Add local controls where laws are stricter.
4. 4Get legal advice where rules conflict.

1. 1Appetite too vague to guide decisions.
2. 2Risks without named owners.
3. 3Policies not enforced or monitored.
4. 4Controls designed but never tested.

1. 1Benefit risk: IT investments that don't deliver value.
2. 2Delivery risk: projects late, over budget or failing.
3. 3Operations risk: outages, errors, performance.
4. 4Security and compliance risk: breaches, fines.

A threat is more likely when an actor has both the motive and the capability. A hospital is attractive to ransomware gangs because it can't tolerate downtime; a defence contractor attracts nation-states because of its secrets.

1. 1Already has access and knowledge.
2. 2Bypasses perimeter controls.
3. 3Can be malicious or simply careless.
4. 4Controls: least privilege, SoD, monitoring, leaver process.

1. 1Vulnerability scans and penetration tests.
2. 2Audit findings and control testing.
3. 3Incident and near-miss reviews.
4. 4Control self-assessments and process walkthroughs.
5. 5Supplier assurance reports.

Risk factors are conditions that make an event more likely or more damaging. They aren't events themselves. High staff turnover in IT doesn't cause an outage, but it makes one more likely and slower to fix.

1. 1Adjust likelihood and impact estimates.
2. 2Spot when ratings need review.
3. 3Choose leading key risk indicators.
4. 4Explain why a risk is rising or falling.

'Cyber risk' can't be rated or owned. 'A criminal group phishes finance staff and diverts a 500,000 payment' can. Scenarios make risk concrete enough for the business to judge likelihood and impact and decide what to do.

1. 1Involve business owners and technical experts together.
2. 2Use generic scenario libraries only as a starting point.
3. 3Keep the number manageable: focus on what matters.
4. 4Link each scenario to an objective and an owner.

A scenario is ready when its owner reads it and says 'yes, that could happen to us, and here's what it would cost'. If the owner doesn't recognise it, it will be mis-rated or ignored.

If every scenario is 'total loss of all systems', everything rates critical and nothing can be prioritised. Assess the realistic severe case alongside the extreme, so ratings reflect what's actually likely.

A vulnerability scan lists technical weaknesses. A risk assessment asks which threats could use them, against which assets, how likely that is and what it would cost the business. Scans are one input, not the assessment.

1. 1What decision will the result support?
2. 2Is reliable loss and frequency data available?
3. 3How much time and expertise do we have?
4. 4Does it fit the enterprise risk method?

Instead of single guesses, estimators give ranges: 'between two and six events a year, each costing 50,000 to 400,000'. Monte Carlo runs thousands of random combinations to show the range of likely annual losses and their probabilities.

1. 1Delphi: anonymous rounds until experts converge.
2. 2Structured interviews and workshops with clear scales.
3. 3Calibrate estimates against incident and industry data.

If the finance team's 'high' means a 1 million loss and IT's 'high' means a server outage, nobody can compare risks or add them up. A common methodology makes results comparable across teams and across years.

1. 1Document the methodology and examples.
2. 2Train everyone who assesses risk.
3. 3Calibrate ratings in review sessions.
4. 4Change the method only deliberately, and restate past results.

Most impacts grow with duration. A one-hour outage of online sales may cost little; a three-day outage may lose customers for good. Ask owners how impact changes over an hour, a day and a week.

A business impact analysis asks one question: if this process stops, how much harm does that cause, and how fast? It sets recovery priorities and objectives. It doesn't ask how likely disruption is; that's the risk assessment's job.

1. 1Rate impact for scenarios affecting critical processes.
2. 2Prioritise risks on assets critical processes depend on.
3. 3Set recovery objectives that responses must meet.
4. 4Spot dependencies missed by technical inventories.

1. 1Base it on how controls actually operate, using test results.
2. 2Discount controls that are untested or have failed.
3. 3Consider how controls could be bypassed.
4. 4Re-estimate after control changes or failures.

Analysis gives each risk a rating. Evaluation asks what that rating means for the business: is it acceptable, does it need a response, and who must decide? The yardstick is the appetite and tolerance the board has set.

1. 1Impact on business objectives first.
2. 2Distance from appetite or tolerance.
3. 3Speed of onset: how quickly harm arrives.
4. 4Trends: is the risk rising?

1. 1Every entry has a named owner and review date.
2. 2Scenarios are specific, not one-word labels.
3. 3Ratings use the common scales.
4. 4Accepted risks show who accepted and until when.

1. 1Budget planning: fund responses to top risks.
2. 2Audit planning: focus assurance on high risks.
3. 3Project approval: check new risks against the profile.
4. 4Strategy: show risks to new objectives.

1. 1The practitioner sets out options, costs and residual risk.
2. 2The risk owner chooses within their authority.
3. 3Higher risks escalate to more senior owners.
4. 4The decision is recorded in the register.

The goal of a response is residual risk within appetite. Spending more than that buys little extra value; spending less leaves the business carrying more risk than the board agreed to.

1. 1Purchase and licences.
2. 2Implementation and integration.
3. 3Staff time to operate and maintain.
4. 4Training and support.
5. 5Business friction and lost productivity.

1. 1Collect independent estimates before discussion.
2. 2Use incident and industry data as a check.
3. 3Ask what evidence would change the conclusion.
4. 4Invite challenge from people outside the team.
5. 5Show the same scales and periods in every report.

1. 1 Control owner detects failure
2. 2 Reports to risk owner
3. 3 Practitioner reassesses risk
4. 4 Risk owner decides response

Without a right to audit, or at least to receive independent assurance reports such as SOC 2 Type II, the organisation can't verify that the supplier's controls work. Large providers often offer reports instead of on-site audits; check that their scope covers the services used.

1. 1Repeated SLA breaches.
2. 2Late or qualified assurance reports.
3. 3New subcontractors or data locations without notice.
4. 4Financial distress or change of ownership.
5. 5Security incidents or poor incident communication.

1. 1Which risks does the issue affect?
2. 2Does it change residual risk ratings?
3. 3Does it reveal a missing scenario?
4. 4Update the register when issues open and close.

Frameworks save the organisation from inventing controls from scratch, give auditors and regulators a familiar structure, and make gaps easier to spot. They're a starting point; risk assessment decides what's actually needed.

1. 1Start from the risk scenarios and appetite.
2. 2Select controls that address those risks.
3. 3Justify exclusions (e.g. a Statement of Applicability).
4. 4Map selected controls to every relevant framework.

1. 1Is there a named operational owner?
2. 2Does it cover the full scope intended?
3. 3Has it been tested in production conditions?
4. 4Is evidence produced and retained?
5. 5Has residual risk been re-assessed?

If an access review excludes administrator accounts, it can't control privileged access however diligently it's performed. Finding that design gap first saves time and points straight to the fix.

1. 1What caused it: one-off or systemic?
2. 2Does it change residual risk?
3. 3Is a compensating control in place?
4. 4Who must be told, and what's the fix?

1. 1 Plan approved by risk owner
2. 2 Owner updates status regularly
3. 3 Practitioner monitors and reports
4. 4 Overdue items escalated
5. 5 Residual risk verified

A plan can complete every task and still miss its purpose. Success means the residual risk has reached the target agreed with the risk owner, confirmed by testing the new or improved controls.

1. 1Several medium risks on one critical supplier.
2. 2The same control weakness across many systems.
3. 3A business unit with many overdue actions.
4. 4Risk rising in one category over several quarters.

Sometimes the data isn't perfect and a decision can't wait. That's fine, as long as the report says so: which data is missing, how estimates were made and how confident the practitioner is.

1. 1Start from the tolerance agreed with the owner.
2. 2Use history to see normal variation.
3. 3Allow lead time to act before the limit.
4. 4Name the response and recipient for each level.

When a KRI turns red, the right reaction is to respond, not to raise the threshold. Thresholds change only when appetite, the business or the risk itself changes, and that change is approved and recorded.

When a number becomes a target, people find ways to hit it. Closing tickets without fixing problems, or reclassifying incidents to a lower severity, makes metrics look good while risk stays the same.

1. 1Pair each metric with a quality check or sample.
2. 2Watch for sudden improvements.
3. 3Keep a small set of meaningful indicators.
4. 4Retire metrics that don't drive decisions.

1. 1Privileged access and configuration changes.
2. 2Patch and vulnerability status.
3. 3Backup success and recovery tests.
4. 4Payment and transaction anomalies.
5. 5Cloud configuration drift.

1. 1What's changed since last time, and why.
2. 2Risks against appetite, with trends.
3. 3Progress on treatment and overdue actions.
4. 4Decisions or support needed.
5. 5Data date and known limitations.

1. 1Show the appetite line or tolerance on the chart.
2. 2Add trend arrows or previous positions.
3. 3Keep scales the same every period.
4. 4Add two or three sentences on what it means.

Emerging risks are new, or changing quickly, and hard to size because there's little history. Generative AI, quantum computing, new regulation and new attack methods have all been emerging risks. The challenge is acting early without overreacting.

1. 1Scenario analysis with best, likely and worst cases.
2. 2Expert judgement using Delphi.
3. 3Ranges instead of single numbers.
4. 4Watch lists reviewed regularly.

Emerging risks rarely fit a heat map neatly. Report them with ranges and a confidence level, explain what would change the assessment, and set out the options. Leaders can decide well with uncertain information if it's presented honestly.

A technology roadmap moves the organisation from its current architecture to a target state. The destination may be lower risk, but the journey isn't: migrations, parallel systems and skills gaps all create risk along the way.

1. 1Architecture standards approved and maintained.
2. 2Projects reviewed against standards at design.
3. 3Exceptions risk-assessed and time-limited.
4. 4Unsupported systems tracked in the risk register.

1. 1Changes causing incidents (change failure rate).
2. 2Share of emergency changes.
3. 3Unauthorised changes detected.
4. 4Changes without rollback plans.

1. 1Baselines define approved, hardened settings.
2. 2Automated tools compare systems with baselines.
3. 3Drift is investigated: authorised change or problem?
4. 4Baselines are updated through change management.

1. 1Are incidents prioritised by business impact?
2. 2Do major incidents get a root cause analysis?
3. 3Are known errors tracked to permanent fixes?
4. 4Does incident data feed the risk register?

1. 1Secure development standards approved and trained.
2. 2Security requirements in every specification.
3. 3Gates with defined security evidence.
4. 4Independent review before release.
5. 5Software bill of materials for components.

1. 1Restrict who can change pipeline configuration.
2. 2Log and review pipeline changes.
3. 3Protect secrets and signing keys used by the pipeline.
4. 4Scan code, dependencies and containers automatically.

1. 1Use masked or synthetic data where possible.
2. 2Protect test environments if real data is unavoidable.
3. 3Remove test accounts before go-live.