Risk Owners, Stakeholder Analysis, and Communication. This concept solves the problem of “who is responsible when something goes wrong” and “who needs to know about it”. In a real organisation, dozens or hundreds of people touch a system or process, and without clear ownership, risks fall through the cracks.
Jump to a section
A simple way to picture Risk Owners, Stakeholder Analysis, and Communication
3 distinct groups are needed to finish a two-storey house renovation: the homeowner, the architect, and the construction crew. The homeowner decides which rooms to renovate, sets the budget, and accepts the risk of a £10,000 cost overrun if the kitchen floor is rotten underneath. The architect draws the plans, checks building regulations, and advises on which walls are load-bearing. The construction crew does the actual hammering, wiring, and plastering.
In this scenario, the homeowner is the risk owner — the person who pays for losses and decides whether to proceed despite the risk of rotten joists. The architect is the risk management function: they identify risks (termites, asbestos), assess how bad each risk would be, and recommend treatments (hire a structural engineer). The crew are the control owners: they install the damp-proof course, fit the fire doors, and test the smoke alarms. Without clear assignment of who owns each risk and each control, the project would fall apart. The homeowner might expect the architect to pay for unexpected damage, or the crew might stop working if someone else’s delay blocks their task.
Communication channels matter too. The homeowner only talks to the architect, who coordinates the crew. If the crew chief emailed the homeowner directly every time a nail gun jammed, the homeowner would be overwhelmed. Instead, the architect summarises weekly progress, flags issues (e.g., “the steel beam delivery is delayed by 2 weeks”), and the homeowner decides whether to pay for expedited shipping. This layered communication is exactly how an organisation manages risk: risk owners get escalated information about the worst threats, not every operational hiccup.
Let’s break down the three pieces: risk owners, stakeholder analysis, and communication.
First, what is a risk owner? A risk owner is a specific person (not a team, not a department) who is accountable for managing a particular risk. They are the person who says, “I own this risk — I will make sure it is identified, assessed, responded to, and monitored.” The risk owner does not necessarily fix the problem themselves; they might assign someone else to install a control. But they are the single point of accountability. For example, if the risk is “customer data could be leaked by a disgruntled employee,” the risk owner might be the Head of Human Resources, because they control hiring, firing, and access policies.
Crucially, risk owners are different from control owners. A control owner is the person who operates a specific safeguard. The fire alarm is a control; the building manager is the control owner who tests it monthly. The risk owner for “building burns down” might be the Chief Security Officer (CSO). The CSO does not test the alarm themselves, but they decide how many alarms are needed, where they are placed, and what happens when one fails. If the building burns down, the CSO is the person who answers to the board.
Now, stakeholder analysis. This is the process of identifying every person or group that has an interest in a risk, or that can affect or be affected by it. Think of a project to move customer data from a physical server to the cloud. Who cares? The IT team (must do the migration), the security team (must ensure data stays encrypted), the legal team (must ensure compliance with data protection laws such as GDPR), the finance team (must approve the cloud subscription cost), and the board of directors (must approve the budget and accept the residual risk). Stakeholder analysis uses a simple matrix: map each stakeholder’s power (how much they can influence the outcome) and interest (how much they care about the risk). High-power, high-interest stakeholders (e.g., the CEO) need full communication and frequent updates. Low-power, low-interest stakeholders (e.g., a temp worker on a 2-week contract) need only a basic awareness email.
Finally, communication. In risk management, formal communication channels are defined so that the right people get the right information at the right time. Communication has four primary purposes:
Escalation: When a risk exceeds a threshold (e.g., potential loss exceeds £50,000), the risk owner must immediately tell senior management.
Reporting: Regular status reports go to stakeholders — monthly risk dashboards, quarterly risk committee meetings.
Awareness: Everyone in the organisation gets basic training on how to spot and report new risks.
Decision support: When the risk owner needs to choose between treating the risk (buying insurance, adding a firewall) or accepting it, they communicate the options to the decision-maker (often a risk committee or the board).
A common beginner mistake is to assume that every risk is owned by the IT department. In reality, risk owners come from all parts of the business. For example, a risk related to a supplier going bankrupt would be owned by the Procurement Director, not the IT Manager. Another mistake is to confuse communication with just sending emails. Professional risk communication uses structured reports with standardised formats — for instance, a heat map that shows risks on a grid of likelihood vs. impact, with owners’ names listed next to each risk.
In summary, risk ownership, stakeholder analysis, and communication are the scaffolding that holds a risk management programme together. Without them, risks are ignored until they become disasters, and nobody knows who should have acted.
Identify the risk and its owner
A risk is identified (e.g., via a security incident or proactive assessment). Someone with appropriate authority is assigned as the risk owner. This person has the power to accept or reject treatment options and is named in the risk register.
Conduct stakeholder analysis
Map every person or group connected to the risk. Use a power/interest grid to categorise stakeholders. Document their influence, needs, and preferred communication format (e.g., email, meeting, dashboard).
Define roles using a RACI chart
For each control or action, assign who is Responsible (does the work), Accountable (answers for success/failure), Consulted (gives input before decision), and Informed (told after decision). This prevents confusion and gaps.
Establish communication channels and thresholds
Define how and when each stakeholder will receive information. Set thresholds (e.g., risk impact over £10,000 triggers escalation to the board). Create templates for risk reports, escalation memos, and awareness bulletins.
Monitor and update
Track the risk over time. When the risk changes (new control, new threat, new stakeholder), revisit the owner assignment, the stakeholder analysis, and the communication plan. Update the risk register accordingly.
Imagine a mid-sized company, “BrightFinance Ltd,” that offers online loans. BrightFinance uses a mobile app where customers upload their ID and a selfie. One day, a security analyst notices unusual login patterns: someone from a foreign IP tried to access the customer-data database 50 times in 10 minutes. Here is what happens step by step.
The analyst reports the suspicious activity as a potential risk. The risk is assigned to a risk owner: the Head of Information Security, Maria. Maria is accountable for the risk of “unauthorised access to customer data.” She convenes a stakeholder analysis meeting. The stakeholders are:
The Chief Technology Officer (CTO) — high power, high interest (the breach could shut down the app)
The Data Protection Officer (DPO) — high power, high interest (regulatory fines)
The Customer Service Director — medium power, high interest (inbound calls from worried customers)
The external cloud provider’s account manager — low power, medium interest (they need to know in case their platform detected the attack)
The IT helpdesk manager — low power, low interest (only needs to know if users need password resets)
Maria uses a simple RACI chart (Responsible, Accountable, Consulted, Informed). For the specific control “enable multi-factor authentication (MFA) on admin accounts”:
The IT engineer is Responsible (does the work)
Maria is Accountable (signs off on the change)
The CTO and DPO are Consulted (they must agree to the downtime)
The customer service director is Informed (so they can prepare a script for calls)
Maria then decides the communication channel. To escalate the risk, she sends a summary to the weekly risk committee meeting via a standardised form: risk name, current likelihood (Medium), current impact (High), owner (Maria), treatment plan (enable MFA within 48 hours). The CTO receives a private message because the risk could affect uptime; the DPO gets a formal email because of regulatory record-keeping rules.
Within 24 hours, MFA is enabled. Maria logs the closure of the risk, but reclassifies it as a “residual risk” — because MFA reduces the chance of attack but does not eliminate it entirely. She updates the risk register (a central database of all risks) with the new status. At the next monthly board meeting, the risk dashboard shows this risk as “treated” with a green icon next to Maria’s name.
Data from real CRISC exam scenarios shows that practical steps like these — assigning a named owner, mapping all stakeholders, and using formal reporting — are the difference between a mature risk programme and chaos. Without them, the analyst’s report might have sat in an inbox for a week while the attacker succeeded.
CRISC tests you specifically on three things about risk owners, stakeholders, and communication: knowing the definitions, recognising correct roles, and identifying the right communication format for a given scenario.
First, definition-based questions. You will see a sentence like “Who is ultimately accountable for the management of a specific risk?” The correct answer is “risk owner.” A distractor will say “risk analyst” or “risk manager.” CRISC is precise: the risk owner is a named individual with authority to accept or reject treatment options. The risk manager (or risk officer) is a different role — they facilitate the process but do not own the risk.
Second, scenario questions. The exam loves to give you a situation like “A company is implementing a new cloud-based customer relationship management (CRM) system. The project manager has identified a risk that the vendor may go out of business. Who should be the risk owner?” The trap answer is “the project manager.” The correct answer is “the vendor management director” or “the procurement director” — whoever has authority over vendor relationships. The project manager only runs the implementation project; they do not own ongoing vendor risk.
Third, communication channel questions. CRISC distinguishes between “escalation” (urgent, to senior management), “reporting” (periodic, formal, to governance bodies), and “awareness” (broad, to all employees). They might ask: “A risk has exceeded its defined threshold for impact. Which communication channel should be used first?” The answer is “Escalation to the risk committee or senior management within the defined timeframe.” A trap is “email to all staff” — that is awareness, not escalation.
Key definitions to memorise:
Risk owner: Person accountable for managing a specific risk and authorised to make decisions about it.
Control owner: Person accountable for the correct operation of a specific control.
Stakeholder: Any individual or group that can affect, be affected by, or perceive itself to be affected by a risk.
RACI chart: A tool to define roles — Responsible, Accountable, Consulted, Informed.
Risk register: A document that lists all identified risks, their owners, likelihood, impact, and treatment plans.
Escalation: Communicating a risk upward to a person with more authority when it exceeds a threshold.
Trap patterns the exam uses:
Confusing risk owner with risk manager. Risk owner has accountability; risk manager has facilitation responsibility.
Giving the risk owner to the wrong functional area (e.g., making the IT Director the risk owner for a data privacy risk when the DPO or legal counsel should be).
Assuming that communication means “tell everyone everything.” CRISC expects you to know that communication must be targeted, not broadcast.
Testing that you understand the difference between “responsible” (does the work) and “accountable” (answers for the outcome). They love giving you a RACI-like scenario where you must pick which person is accountable.
Setting up a scenario where a risk has many stakeholders, and the question asks “who should be informed?” versus “who should be consulted?” Informed stakeholders receive one-way communication; consulted stakeholders provide feedback before a decision.
Finally, CRISC expects you to know that stakeholder analysis is not a one-time activity. It must be revisited when the risk changes or when the project moves to a new phase. The exam will present a scenario where a risk has been present for 6 months and the stakeholder set has changed (e.g., a new compliance regulation passed) — the correct answer is to redo the stakeholder analysis.
A risk owner is a single named person who is accountable for managing a specific risk, not a team or department.
Stakeholder analysis identifies every person or group that can affect or be affected by a risk, then maps them by power and interest.
Communication channels in risk management are formalised: escalation for urgent threshold breaches, reporting for periodic updates, and awareness for general education.
Risk owners and control owners are different roles: the risk owner decides what to do, the control owner operates the safeguard.
RACI charts are the standard tool to clarify who is Responsible, Accountable, Consulted, and Informed for each risk and control.
Stakeholder analysis must be repeated whenever the risk or its context changes, not just at the start.
These come up on the exam all the time. Here's how to tell them apart.
Risk Owner
Accountable for the overall risk outcome
Has authority to accept or reject treatment options
Answers to the board or risk committee
Control Owner
Accountable for a specific control's daily operation
Implements and maintains the safeguard
Reports to the risk owner on control effectiveness
Responsible
Does the actual work (e.g., configures firewall)
May be multiple people per task
Reports to the accountable person
Accountable
Ultimately answers for success or failure
Single person per task
Has final sign-off authority
Escalation
Triggered by a defined threshold breach (e.g., impact > £50k)
Urgent, out-of-cycle communication
Goes to senior management immediately
Reporting
Regularly scheduled (e.g., monthly, quarterly)
Standardised format (dashboard, heat map)
Goes to governance bodies (board, risk committee)
Stakeholder (Consulted)
Provides input before a decision is made
Has power or interest that shapes the outcome
Their feedback is documented and considered
Stakeholder (Informed)
Receives information after a decision is made
Needs to know for awareness or action
No expectation of influencing the decision
Mistake
The risk owner is always the person who discovered the risk.
Correct
The risk owner is assigned based on who has authority and accountability for managing that risk, not who found it. The person who finds a risk (e.g., a security analyst) usually reports it but does not own it.
Beginners conflate discovery with ownership because many everyday scenarios involve the finder taking responsibility (e.g., if you find a lost wallet, you might return it). In a professional context, ownership is a formal delegation from management.
Mistake
Communicating about a risk means sending an email to everyone involved.
Correct
Communication must be targeted by stakeholder type and urgency. Escalation goes to senior management; reporting goes to governance bodies; awareness goes to broader staff. Mass emails dilute attention and miss the right recipients.
People assume that more communication is always better. In risk management, over-communication can desensitise readers and create noise. CRISC tests the principle of “right information to the right people at the right time.”
Mistake
The IT department owns all technology-related risks.
Correct
Risk owners are assigned based on business function, not technology. For example, a risk involving a software vendor's financial stability is owned by the procurement or vendor management team, not IT.
IT professionals often feel they “own” everything with a plug. But CRISC is about enterprise risk management, where business process owners have authority over outcomes, not just the technical implementation.
Mistake
Stakeholder analysis is only done at the start of a project or risk assessment.
Correct
Stakeholder analysis is a continuous activity. New stakeholders emerge when the risk changes (e.g., new regulation, new team member). The analysis must be revisited at each significant change.
Beginners think of it as a checklist item they can tick once. In reality, risk management is cyclical, and the stakeholder map is dynamic.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
The risk owner is accountable for managing the risk overall, including deciding whether to treat it. The control owner is accountable for ensuring a specific control (like a firewall or a backup process) operates correctly.
Yes, if the same person has the authority to decide on the risk and also operates the control. However, this is often discouraged because it reduces segregation of duties. CRISC expects you to know they can be the same but ideally should be separate.
Look at who has the authority and budget to make decisions about the risk. For example, a risk about a supplier going bankrupt is owned by the procurement director, not the IT support technician.
It is a grid with two axes: power (ability to influence the outcome) and interest (degree of concern). Stakeholders are plotted into four quadrants: high-power/high-interest (manage closely), high-power/low-interest (keep satisfied), low-power/high-interest (keep informed), low-power/low-interest (monitor).
No. CRISC requires a single named risk owner per risk. Multiple owners create confusion over accountability. If a risk spans multiple areas, assign one primary owner and define others as stakeholders.
It should define who gets what information, how often, via what channel (email, meeting, dashboard), and under what conditions escalation happens. It also specifies the format (e.g., a one-page risk heat map for the board).
You've finished Risk Owners, Stakeholder Analysis, and Communication. Continue through the CRISC study guide to build a complete picture of the exam.
Done with this chapter?