A polished walkthrough of how a hyperscaler manages cybersecurity risk is easy to admire and hard to use. Here is the translation back to a scale that fits the rest of us.
| TL;DR Microsoft published a calm, confident video on how it runs cybersecurity risk at enormous scale. Most of the machinery in it assumes resources you do not have. Strip it back and three principles survive at any size: risk lives in one place, every risk has a name attached, and you treat it as a lifecycle rather than a one-time cleanup. Below the translation you will find five questions to test your own setup. The honest finding is that the framework was never the hard part. Keeping it alive is. |
Why I keep thinking about a Microsoft video
I watched a video recently that I keep returning to, partly for the wrong reasons. In it, Stephanie Peterson, who runs governance, risk and compliance inside Microsoft’s Office of the CISO, walks calmly through how one of the largest companies on the planet manages cybersecurity risk. It is genuinely good work, clearly explained.
It is also, if you run security anywhere other than a hyperscaler, quietly intimidating. There is a council of Deputy CISOs. There is a curator for every risk domain. There is an enterprise report twice a year that rolls everything up to the board. My first honest reaction was: lovely, and I have a team of four.
So I did the thing the video does not do for you. I translated it.
The principles survive, the machinery does not
Here is the distinction worth holding onto. Almost everything that makes the Microsoft programme look unreachable is tied to its size, not to good practice. The councils, the dedicated curators, the formal reporting cadence all exist because the organisation is enormous, not because risk management requires them.
Strip that away and three principles are left standing. They do not care how big you are. First, risk lives in one place. Second, every risk has a name attached to it. Third, you treat risk as a lifecycle, not a cleanup exercise. Everything below hangs on those three.
The translation, principle by principle
One place where risk lives. Microsoft calls it the Risk Register. Anyone with access can submit a risk, curators triage it, owners track it, reviewers read it through reports. It is a managed product with defined roles and service levels. At your scale that is a shared list, in whatever tool you already pay for, that everyone treats as the truth. The format matters far less than the discipline. The moment risk lives in three inboxes and one person’s head, you do not have a register, you have a rumour. The value Microsoft draws from its tooling is not the tooling. It is that there is exactly one place to look. For organisations touched by NIS2, this also matters because leadership cannot govern risks that remain scattered across inboxes, tools and assumptions.
Clear ownership. Microsoft assigns an accountable owner to every prioritised risk, and that person stays accountable until the risk is resolved or retired, separate from whoever first spotted it and separate from whoever fixes the technical part. You can copy that assignment on day one for nothing. But ownership is not only a name in a column. It also requires mandate. If someone is accountable for a risk yet cannot influence priority, budget, policy or acceptance, you have created accountability without authority, which can be more dangerous than having no owner at all. The failure mode at smaller organisations is rarely the absence of a name. It is the quiet assumption that IT owns all of it, which means no one does, and that no one carries the authority to act.
I have watched this play out more than once. Someone is handed a supplier risk to own. They chase it for a year and a half, dutifully updating the entry, while the two things that would actually move it, the contract terms and the budget to replace the supplier, sit with people who never open the register. The risk is not neglected. It belongs to someone who was never given the levers to close it, and no amount of diligence makes up for that.
There is a quieter version of the same problem, and it is the one most registers never solve: who is allowed to accept a risk. Ownership decides who drives a risk down. Acceptance decides who may say, on the record, that the organisation will live with it. Most registers hold plenty of the first and almost none of the second, so risks rarely close. They accumulate, half-mitigated, because closing one means someone senior enough has to put their name against a sentence like: we looked at this and chose to carry it. If nobody in your setup can write that sentence, your register will only ever grow. A risk you consciously accept is being managed. A risk that stays open because no one dares accept it is just anxiety with a tracking number.
A lifecycle, not a cleanup. Microsoft runs a loop of four stages: identify, assess, mitigate, then prevent and monitor, with the last stage feeding back into the first. The point of the loop is that risk is never finished. This is the principle most worth stealing and the one most often skipped. Smaller teams tend to treat risk as a project with an end date. You run an assessment, you fix what it found, you file the report, and then nothing watches whether the fix held or whether the world moved. The loop is what turns a one-time audit into actual risk management. You do not need their tooling to run it. You need the habit of coming back.
| DIMENSION | At Microsoft’s scale | At your scale |
|---|---|---|
| WHERE RISK LIVES | A managed register with roles and SLAs | One shared list everyone trusts |
| WHO OWNS IT | A named accountable owner per domain | A named owner who can act |
| HOW IT IS REVIEWED | Councils and a board report twice a year | A standing date in the diary |
| WHAT POWERS IT | Dedicated tooling and curators | Discipline, not software |
Five questions the video should make you ask
If you take nothing else from the video, take these. They follow the same lifecycle logic, turned around to point at you instead of at Microsoft. Answer them honestly and you will know within five minutes whether you have a risk programme or a filing cabinet.
| 1 | IDENTIFY If I asked your team to list your top five risks right now, would you get one list, or five different ones? |
| 2 | OWN Who loses sleep over your single biggest risk? Name them. If you cannot, that is the finding. |
| 3 | CONTINUITY What happens to that knowledge the week after that person hands in their notice? |
| 4 | ASSESS When did you last change a risk rating because the world changed, rather than because someone asked for the report? |
| 5 | MONITOR Of the risks you closed last year, how would you know today if any of them quietly reopened? |
The part the slides leave out
A polished deck makes all of this look like a structure you adopt. It is not. Underneath that calm walkthrough sit years of work, a culture that had to be built, and the unglamorous fact that a register nobody updates is worse than no register at all, because it lets you believe you are covered.
The gap is never knowing that risk matters. Everyone reading this already knows. The gap is the organisational work of keeping the thing alive when no incident is forcing the issue: the owner who actually updates their entry, the quarterly look that happens even in a quiet quarter, the awkward conversation about who is accountable. That work is mostly human, not technical, which is exactly why tooling does not solve it.
If one of these questions stung, the answer is probably not another tool. It is a governance conversation: where does risk live, who has the authority to act on it or accept it, and how do you know the risk stayed closed? That conversation is uncomfortable, but it is also where real risk management starts. It is also the kind of conversation I increasingly find myself helping organisations structure in the day job. The framework was never the secret.
Further reading
- Microsoft moves tenant governance into continuous control
- Strengthening cloud governance and resilience with Microsoft
- Mastering NIS2 compliance with Microsoft Purview Compliance Manager
- Office of the CISO Insights, Microsoft Security Blog
- ENISA: NIS2 Technical Implementation Guidance on cybersecurity risk management measures
