security
Apr 29, 2026
By Teun
Microsoft Deputy CISO lays out eight risk review checks
Microsoft Deputy CISO Rico Mariani outlined eight areas to cover in security risk reviews: assets, applications, authentication, authorization, network isolation, detections, auditing and overlooked systems. He said the goal is to turn security data into proactive planning as threats grow and AI helps criminals scale attacks.
Microsoft Deputy CISO Rico Mariani has outlined eight practical areas CISOs should cover when conducting risk reviews, arguing that security teams need a more structured way to turn data into proactive defense. In a blog post in Microsoft’s Deputy CISO series, Mariani said the approach is meant to help teams ask the right questions and surface vulnerabilities before attackers exploit them.
Mariani said the need for stronger review processes has grown as cyberthreats have become more frequent and more automated. According to Microsoft, it stopped $4 billion in fraud attempts between April 2024 and April 2025, and the company said it is tracking 100 trillion security signals each day, a 40% increase since 2023.
⚡ New to this?
This is a Microsoft security leader’s checklist for reviewing risk across a company’s systems. For non-specialists, a risk review is a structured way to ask what could go wrong, where sensitive data lives, and how an attacker might move through the environment.
Some of the terms matter because they map to common security controls: authentication is proving who you are, authorization is deciding what you can do, and auditing is keeping records so teams can investigate after an incident. The article shows how large security teams try to turn those ideas into a repeatable process.
🦞 OpenClaw angle
If you run self-hosted AI agents, use this checklist against your own stack: model files, vector databases, secrets stores, inference APIs, and admin consoles. Tighten token scope so one agent or service account cannot access everything, and treat dev, test, backup, and support systems as separate targets, not lower-priority copies of production.
Add explicit logging for agent actions, tool calls, and data access so you can reconstruct what happened after a mistake or compromise. Also set detections for unusual prompt patterns, request bursts, and calls from unexpected network paths, because AI automations often fail open when internal services are too broadly connected.
He wrote that risk reviews can move security data away from purely reactive incident response and toward planning that helps shape a defensive posture. Mariani also said his perspective on the topic has been shaped by his first six months as Deputy CISO for Microsoft Security Products, Research Infrastructure, and Engineering Systems.
The first area is assets. Mariani said a review should begin by identifying the systems and data that need protection, using architecture diagrams and threat models to define scope. Those assets may include storage holding sensitive data or highly privileged applications such as command-and-control systems.
The second area is applications. Mariani described these as the active part of a system, including customer-facing services and the microservices behind them. Because applications often need access to important assets, he said they can also become targets, and he pointed readers to Zero Trust principles for source code access.
Authentication is the third area. Mariani said the best systems use tokens from standard issuers such as Microsoft Entra, rather than custom token-generation systems that may contain bugs or other weaknesses. He said token-based systems should be scoped tightly, short-lived where possible, and specific to the intended user, data and action.
Authorization is the fourth area. Mariani said good authentication is not enough if enforcement is weak, and warned that ad hoc authorization code can undo earlier protections. He recommended declarative patterns that consistently check tokens against APIs and the data being requested.
The fifth area is network isolation. Mariani said teams should limit how far an intruder can move if they get a foothold in part of the environment. He recommended using service tags and network controls so that only the systems that need access can reach sensitive assets, including controls at the perimeter and deeper in the network stack, such as virtual LANs and network security groups in Microsoft Azure.
Detections are the sixth area. Mariani said teams should look not only at reliability monitoring but also at whether their threat model can be observed in practice. That could mean alerting on incoming HTTP traffic, badly formatted requests, fuzzing or evidence of distributed denial-of-service attacks.
Auditing is the seventh area. Mariani distinguished auditing from detection, saying auditing data is what teams use after a breach to understand scope, determine which customers were affected and confirm whether a vulnerability was exploited. He said endpoint detection and response data and application logs can both support that work.
The final category is “things not to miss.” Mariani said teams often overlook backup data, support systems and development or test environments, even though those can contain exposed data or weaker code paths. He said development systems deserve extra scrutiny because they are more likely to contain bugs, including authorization bugs.
Mariani concluded that teams that identify assets, applications and the controls between them - including authentication, authorization, network isolation and logging - are in a strong position to build a risk summary that can guide action for months. He said the checklist should sit alongside basic security work such as vulnerability management, bug handling and software lifecycle controls.
