Cloud Security Assessment: Types, Process, Benefits, Risks, Controls, and Fixes

Q1. What exactly is a cloud security assessment (and what is it not)?

A cloud security assessment is a structured evaluation of how well your cloud configurations, identities, data, and workloads resist a real attack, not whether a checkbox is ticked. It examines posture, identity and access management (IAM, the rules controlling who can do what), network, storage, and your ability to detect intrusions. Measured against frameworks like the CSA Cloud Controls Matrix and NIST CSF 2.0, a strong assessment proves your defenses hold under pressure, not just on paper.

The scene most teams know too well

Picture a CISO three days after a clean penetration test. The dashboard is quiet. Leadership reads “no critical findings” and exhales. Two weeks later, an attacker walks through a misconfigured storage bucket nobody flagged.

That quiet dashboard was not safety. It was a detection failure dressed up as a win. A real assessment asks a harder question: when someone attacks, will you actually see it?

Assessment is not the same as an audit or a pen testThese three terms get used interchangeably, and that confusion costs money. They answer different questions.

• Audit: Did you meet a standard on a specific date? A point-in-time compliance check (for example, SOC 2 evidence collection).
• Penetration test: Can a tester break in through a defined target right now? A focused offensive exercise.
• Cloud security assessment: How healthy is your whole cloud posture, and can you detect and respond when controls fail?

A 2026 HALOCK analysis put it plainly: clients constantly confuse which evaluation they actually need for their AWS, Azure, or Google deployments, because each platform ships different default controls. An audit tells you that you locked the door. An assessment tells you whether the lock works when someone picks it.

Why the “annual checkbox” model quietly fails

An annual assessment leaves 364 days of blind spots. Cloud changes daily. A developer spins up a new workload Monday, and your January report is already stale.

The goal is continuous confidence that assets are properly configured, secured, and not subject to an attack, which is a posture, not a one-time event. The word that matters is continuous, and it underpins effective continuous security monitoring.

From snapshot to functional assurance

Here is the shift I push every security leader toward. Stop treating the assessment as a snapshot. Treat it as functional assurance, ongoing proof that your cloud business value chain withstands offensive pressure.

The CSA Cloud Controls Matrix v4.1 supports this with 207 control objectives across 17 domains covering the full cloud stack. Used well, those domains become a living scorecard, not a binder that gets dusty.

I might be overstating the urgency for very small cloud footprints. If you run three static workloads and nothing changes for months, an annual review may genuinely be enough. But from what surfaces when you actually run these engagements, most teams underestimate how fast their attack surface drifts. The standard read gets this backwards: silence is treated as strength, when silence is usually just missing telemetry.

Q2. What are the main types of cloud security assessment and which domains do they cover?

The main types are configuration and posture reviews, IAM and privilege assessments, vulnerability assessments, cloud penetration testing, compliance-mapped audits, and continuous posture validation. Together they cover the core domains: posture, identity, network, storage, workload, and detection. Most teams run one or two. Mature programs layer all six, because each answers a different question, from “is this misconfigured?” to “can an attacker chain these into a breach?”

Six lenses on the same cloud

Think of these types as six different lenses. Each shows you something the others miss. A configuration scan finds the open door. A penetration test proves someone can walk through it.

A 2025 SentinelOne breakdown stresses the practical split: vulnerability assessment finds and measures weaknesses at breadth, while penetration testing proves real exploitability at depth. You need both. One counts the cracks; the other shows which crack actually lets water in. This is why mature teams pair scanning with hands-on web app penetration testing.

How to read this table

Match the type to the question you are actually trying to answer this quarter, then to a realistic cadence. Do not buy a penetration test when you have never run a basic posture scan.

The domain most assessments skip

Notice the last row. Detection is a domain, and it is the one most reviews ignore. A cloud security assessment evaluates the security posture of a cloud environment, and posture includes whether you can actually see an attack through proper cloud security services.

Wiz structures its self-assessment across nine security domains so teams can benchmark gaps rather than eyeball them. That benchmarking matters. A gut feeling is not a posture score.

Where most vendors quietly stop

Here is my contrarian take. Most providers stop at configuration scanning, ship you a PDF of red findings, and call it an assessment. That is the easy 80 percent.

The hard, valuable work is attack-path testing, chaining a misconfigured bucket, an over-permissioned role, and an exposed workload into one realistic breach story. I might be wrong for highly regulated shops that need the audit artifact above all else. But from running these, the chained narrative is what actually moves a board, not a list of 400 isolated reds.

Q3. What does the cloud security assessment process look like step by step?

The process runs in seven steps: (1) define scope and shared-responsibility boundaries, (2) inventory assets and identities, (3) evaluate risk against a framework, (4) test controls and simulate attacks, (5) prioritize by exploitable attack path, (6) remediate with concrete fixes, and (7) move to continuous reassessment. The shift that matters most: stop ranking findings by raw severity score alone, and start ranking by reachable attack path.

Seven steps, one goal: proof under pressure

A good process is not bureaucracy. It is a route from “we think we are secure” to “we have evidence we are.” Here is the sequence I run.

Step 1: Define scope and shared responsibility. List every account, region, and service in play. Write down where the cloud provider’s job ends and yours begins. Done right, nobody can later say “I thought AWS handled that.”

Step 2: Inventory assets and identities. You cannot protect what you cannot see. Pull a full list of workloads, storage, and every human and machine identity. The Monday action: audit OAuth consent logs in Google or Microsoft 365 to surface shadow apps for free.

Step 3: Evaluate risk against a framework. Map findings to the CSA Cloud Controls Matrix or NIST CSF 2.0 so risk is structured, not anecdotal. Done means every gap sits inside a named control domain, the kind of structure our compliance services are built around.

Step 4: Test controls and simulate attacks. Do not assume a control works. Prove it. The goal is confirming assets are configured, secured, and not subject to attack, which requires active testing, not document review.

Step 5: Prioritize by exploitable attack path. This is the step that separates mature teams. Rank findings by whether an attacker can chain them, not by isolated severity. Upwind’s 2025 guidance argues assessments should benchmark real-world attack paths, from privilege escalation to overly permissive IAM and lateral movement.

Step 6: Remediate with concrete fixes. Every finding needs an owner, a fix, and a deadline. Build playbooks for IAM key rotation and resource isolation that run in minutes, not hours, the same way a strong incident response function operates.

Step 7: Move to continuous reassessment. A one-time pass expires fast. Automate posture checks so the assessment never fully ends, ideally backed by a 24/7 SOC service.

The pilot project trap

Here is where I see teams get burned. Pilot projects go live to hit a deadline, and logging is still “pending.” Attackers love a 2 AM window with no telemetry.

So my hard rule: no cloud workload goes to production without logging switched on first. I might sound rigid, but I have watched the alternative play out badly too many times.

Prove the pipeline actually alerts

Steps four and seven need a heartbeat check. Implement synthetic transactions, small scripted test events (for example, a Windows eventcreate entry), for each data source. Run them daily. If your pipeline does not alert in under two minutes, you have a detection gap, not a quiet network. Time is the currency of the cloud, and your alert-to-triage should be measured in minutes.

Q4. Which frameworks and compliance standards should anchor your assessment?

Anchor your assessment to the CSA Cloud Controls Matrix (17 domains, 207 control objectives) because it cross-maps to NIST CSF 2.0, ISO/IEC 27001, SOC 2, and PCI DSS 4.0, so one assessment can feed many audits. Then layer NIST CSF 2.0’s six functions (Govern, Identify, Protect, Detect, Respond, and Recover) as a budget map to expose gaps, like heavy spend on “Protect” while “Detect” sits at zero.

Pick one backbone, then map everything to it

The mistake I see most is running a separate assessment for every regulation. SOC 2 in March, ISO 27001 in June, PCI DSS in September. Same evidence, gathered three times, paid for three times.

A single control backbone fixes this. The CSA Cloud Controls Matrix v4.1 contains 207 controls across 17 domains and is built to cross-walk to other accepted standards, which simplifies audits. Gather evidence once. Satisfy many. A virtual CISO can own this backbone end to end.

The framework cross-walk

The NIST CSF budget map

Here is a use for NIST CSF 2.0 that the standard write-ups miss. Treat its six functions as spending buckets. The framework was published February 26, 2024, and added Govern as a sixth function precisely to tie security to enterprise risk decisions, including budget. It pairs well with a structured 2026 cybersecurity budget playbook.

Map your cloud security spend across Govern, Identify, Protect, Detect, Respond, and Recover. Most teams find a lopsided picture: piles of money in Protect (firewalls, endpoint tools) and almost nothing in Detect. That imbalance is your real risk, visible in one chart your CFO understands, and it is where MDR service usually closes the gap.

Where your logs live is now a control

One more thing the frameworks force into the open: data residency. Under GDPR and the EU NIS2 directive, where your cloud logs sit is a compliance decision, not just an engineering one.

I lean toward keeping logs in your own data lake or sovereign region when regulation demands it, which is far easier with a managed SIEM you control. Some vendors force telemetry into their proprietary cloud, which can quietly create a residency problem you inherit. I might be slightly conservative here, but from working with EU-facing clients, “we’ll sort residency later” tends to become an audit finding.

Q5. What are the biggest cloud security risks an assessment uncovers?

Assessments most often surface misconfigured storage, over-permissioned IAM (identity and access management, the rules for who can do what), static long-lived credentials, missing multi-factor authentication, and inadequate logging. These are the gaps behind the costliest breaches. In 2024, the global average breach cost hit $4.88 million, breaches that spanned multiple environments made up 40 percent of cases, and they took 283 days to contain. The newest blind spot is shadow AI: autonomous developer agents acting in production with nobody watching.

The risks that show up again and again

I have sat in a lot of readouts. The same handful of findings dominate almost every cloud assessment we run. They are not exotic. They are boring, and that is exactly why they keep working for attackers.

• ⚠️ Misconfigured storage: A public bucket or open blob nobody meant to expose. Still the number one finding.
• ⚠️ Over-permissioned IAM: Roles with far more access than the job needs, so one stolen identity owns everything.
• ⚠️ Static long-lived credentials: API keys that never rotate, sitting in code and config for years.
• ⚠️ Missing MFA: A single password between an attacker and your crown jewels.
• ⚠️ Inadequate logging: No telemetry, so a breach runs silent for months.

Why the cost numbers should change your priorities

That 283-day containment figure is the one I quote to boards. Nearly ten months. An attacker living in your cloud that long is not a detection problem, but a detection absence.

IBM also found that breaches involving data stored across public cloud carried some of the highest costs in the study. The lesson is simple. Cloud sprawl is not just an architecture headache. It is a direct line on your breach bill, which is why cloud security services focus on shrinking that surface.

The new risk nobody has fully priced in

Here is where I think the standard read gets it backwards. Most risk registers still treat “shadow IT” as rogue SaaS apps. The real 2026 problem is shadow AI.

Developers now run autonomous agents (tools like Copilot, Cursor, and Claude) that act inside production cloud. They create resources, touch data, and make changes, often with no monitoring at all. I could be early on this, but from what surfaces when you actually audit these environments, agentic activity is the fastest-growing ungoverned surface I see, and it is exactly what MDR for AI is built to watch.

A free move you can run on Monday

You do not need to buy a tool to start. Audit your OAuth consent logs in Google Workspace or Microsoft 365. Every entry shows where an employee authenticated with corporate credentials.

That single export gives you a free shadow-app inventory. The 2025 Salesforce attacks proved the stakes: attackers tricked staff into authorizing a rogue OAuth app that bypassed MFA and pulled bulk data. If you cannot see your consents, you cannot see that attack coming. Which brings up the harder question I will tackle next: once you have a pile of findings, how do you know which one actually matters?

Q6. How do you prioritize findings by attack path instead of raw severity?

Attack-path prioritization ranks findings by whether an attacker can actually chain them into a breach. A public bucket, plus an over-permissioned role, plus an exposed workload, equals real data exfiltration. This beats CVSS-only triage (CVSS is the 0 to 10 severity score for a vulnerability), which buries the one reachable path under hundreds of isolated “critical” alerts. The rule I live by: fix the single misconfiguration that breaks the chain, not the highest-scored CVE.

The concept: think in chains, not lists

A vulnerability scanner hands you a list. Four hundred reds, sorted by score. That list is almost useless on its own, because a “critical” finding an attacker cannot reach is not your real risk.

An attack path is a chain of small weaknesses that link into one breach. Real-world attack-path benchmarking spans privilege escalation, overly permissive IAM, and lateral movement. That word, path, is the whole game, and it is central to effective attack surface management.

A three-hop example you will recognize

Let me walk one I see constantly. None of these three findings is scary alone.

1. A storage bucket is public (medium severity).
2. That bucket holds a config file with a long-lived access key (low, “informational”).
3. That key maps to a role that can read your production database (a permissions issue, easy to miss).

Chain them, and an attacker goes from a public URL to your customer data in three hops. CVSS scores each step low to medium. The path itself is a full breach, the kind a real penetration testing engagement exposes.

Assume the perimeter is already gone

Here is the mindset shift. Old networks were like an M&M, a hard candy shell around a soft, tasty center. Get through the shell, and you owned everything inside.

Cloud killed that model, but a lot of assessments still defend the shell. I run them the opposite way. Assume the perimeter is already breached, then ask what an attacker can reach from inside. That is Zero Trust in practice, not on a slide.

Fix the choke point, not the count

Once you see the chain, remediation gets cheaper, not harder. You do not need to fix all 400 reds this week. You need to break the chain at its narrowest point.

In the example above, rotating one key or tightening one role kills the whole path. The smart approach prioritizes remediations and builds a roadmap, rather than dumping a flat finding list, the same philosophy behind our incident response playbooks. I might be too blunt here, but a “critical” with no reachable path can usually wait. The medium that completes a chain to your database cannot.

Q7. Which controls and fixes actually close cloud security gaps?

Every risk maps to a control and a concrete fix. Misconfiguration gets CSPM (cloud security posture management, automated config scanning) plus infrastructure-as-code guardrails. Over-permissioned IAM gets least privilege and just-in-time access. Static keys get automated rotation and a secrets manager. Missing logging gets mandatory log shipping to your SIEM (your central log and alerting platform). Agentic AI gets activity monitoring. The fastest-payback fix is autonomous containment that rotates keys and isolates resources in minutes.

Match each gap to a real fix

Findings without fixes are just anxiety. The value of an assessment is the remediation map. Here is the one I hand teams, mapped loosely to the CSA Cloud Controls Matrix domains.

The logging fix most teams forget: your suppliers

Continuous monitoring and centralized logging are baseline controls. Agreed. But here is the gap I see: teams log their own cloud and ignore their vendors.

Make log shipping a contract term. Require every cloud supplier to send logs to your named SIEM endpoint as a condition of onboarding, something a managed SIEM makes straightforward to enforce. ✅ If they cannot, that is a finding before you even sign.

Make the fixes pay for themselves

High-fidelity cloud logging causes sticker shock. CISOs see the SIEM ingestion bill and freeze. I get it, that money is real.

This is where we apply ingestion tuning at UnderDefense, cutting SIEM data volume by 50 to 90 percent by filtering noise before it hits the bill. The savings often fund the rest of the assessment program, which is the kind of trade-off a MDR service should surface. That is the kind of hard-dollar trade I would rather show than claim.

Containment in minutes, not a ticket queue

The last row is the one that saves you at 2 AM. An assessment should produce ready-to-run playbooks, not just findings.

Build automation for IAM key rotation, user password resets, and resource isolation that executes in minutes. ⏰ Automation handles the routine containment fast. Humans handle the edge cases that need judgment. That split is the only model I have seen scale without burning out a team, which is why we run it on the UnderDefense Agentic AI SOC platform.

Q8. Why does continuous validation beat the annual assessment?

An annual assessment leaves 364 days of blind spots, and attackers know your audit calendar better than you do. Continuous validation runs synthetic transactions (small scripted test events) and automated posture checks daily, proving every data source still alerts in under two minutes. Real incidents prove the gap. Attackers use off-hours windows specifically to evade business-hours review. A once-a-year snapshot means defending the cloud at human speed against machine-speed adversaries.

The claim: cadence is the control

My governing thought is simple. The frequency of your validation is itself a security control. A perfect assessment in January is worthless against an attack in March if nothing has checked since.

Time is the currency of the cloud. Your alert-to-triage should be measured in minutes, not the months it took to find the average 2024 breach, which is exactly what continuous security monitoring delivers.

The proof: attackers exploit your clock

Look at how real campaigns work. In the 2026 APT28 operation against a Ukrainian government agency, the Zimbra exploit ran silently inside an authenticated session, harvesting credentials, 2FA backup codes, and up to 90 days of email, all without raising a single alert.

The 2025 Salesforce campaign was the same lesson in SaaS. Attackers used voice phishing to get an employee to authorize a rogue connected app, then exfiltrated bulk data over normal-looking API calls. ❌ A January controls review would have caught neither. Both needed someone, or something, watching at the moment of attack, which is the core promise of a 24/7 SOC service.

Why business-hours monitoring is a trap

Here is the contrarian bit. A lot of teams run “9 to 5” review and call the cloud covered. Attackers love that schedule.

The FBI’s 2025 FLASH alert on the Salesforce attacks recommended monitoring API usage and OAuth integrations for anomalous behavior continuously, not periodically. Off-hours is not a quiet time to defer. It is the preferred time to attack.

What continuous validation looks like in practice

So what do you actually do differently? You stop treating validation as an event and wire it into daily operations.

• ✅ Run synthetic transactions for every data source, daily, to prove the pipeline alerts in under two minutes.
• ✅ Automate posture checks, so drift is caught the day it happens, not next January.
• ✅ Keep eyes on the stream 24/7, because silence on the dashboard is not proof of safety. It is usually proof of missing telemetry.

I could be slightly dogmatic on the “minutes” target. For a tiny, static environment, daily may be plenty. But from what surfaces when you actually run this across busy enterprise clouds, the gap between annual and continuous is where the expensive breaches live, the same gap a mature set of SOC metrics is designed to close.

Q9. Should you run the assessment in-house or use a provider, and how do you evaluate one?

Run it in-house only if you have Tier 3 to 4 analysts (your most senior threat hunters and responders) and deep tooling expertise. Otherwise, use a provider. Evaluate them on four things: vendor-agnostic integration (do they sit on your existing SIEM and XDR, or force rip-and-replace?), real response capability (alerts versus actual containment), transparent pricing, and CAIQ-based assurance (a standard cloud security questionnaire). The trap to avoid is buying a fleet of Ferraris with rookie drivers, expensive tools nobody can operate.

The in-house reality most teams underestimate

I love a strong in-house team. But running your own continuous cloud assessment is a 24/7 commitment, not a project. You need senior analysts, detection engineering, and someone awake at 2 AM, which is exactly the math behind the outsourced vs in-house SOC decision.

Here is the part nobody markets. AI tooling alone does not close that gap. In our own testing, raw AI triage lands the high-stakes verdict right only around a third of the time. ⚠️ AI is a brilliant assistant. It is a terrible final decision-maker on whether you are breached.

The four-criteria rubric I use

When teams ask me how to score a provider, I give them this. Map every vendor against four questions, in order.

1. ✅ Integration: Do they run on your stack (Sentinel, Splunk, Chronicle), or force their proprietary tools?
2. ✅ Response: Do they contain the threat, or just escalate an alert to your queue?
3. 💰 Pricing: Is it transparent per-endpoint, or a black-box quote that balloons at renewal?
4. ✅ Assurance: Will they complete a CAIQ and show their methodology?

This rubric is the backbone of any serious MDR buyers guide exercise.

Where the category quietly breaks

Here is my honest read, and I will be fair to good companies. The biggest gap in this market is not detection. It is response and context.

A lot of MDR is “monitoring without action.” Reviewers say it plainly. Arctic Wolf customers describe being left to do the actual fixing themselves.

“Lack of true remediation in the response, costing us significantly in resources and introducing risks in security.” VP of Technology Arctic Wolf Gartner Verified Review

The other recurring complaint is the black box, where you cannot change anything without going through their engineering team.

“Anything you want to look at or changes you need to make in the product must go through their engineering team. As an MSP, this is a horrible way to do business for us.” Matt C., Manager, Cybersecurity Services Arctic Wolf G2 Verified Review

I see the same pattern in tooling-heavy providers, where support follow-through fades after the sale.

“The pre-sales crew is great. Really make you think you’ll get high tier support… The scan engine doesn’t function… they’ve ignored requests to get this resolved.” Verified User, Farming Rapid7 G2 Verified Review

If these patterns sound familiar, it is worth reviewing the Rapid7 alternatives before you renew.

What we actually do differently

This is the one place I will talk about us, because it is the whole point. ✅ We built our MDR service to be vendor-agnostic, sitting on top of your existing SIEM and XDR, no rip-and-replace, so you keep data ownership. ✅ Our analysts own the outcome, validating suspicious activity directly with the affected user and containing it, not just forwarding an alert. ❌ The drawback of forced-tool MDR is lock-in plus opaque pricing. We pair AI-speed detection with Tier 3 to 4 humans on the high-stakes calls, because a model that is right a third of the time should never be your last line.

Q10. What are the benefits and realistic ROI of a cloud security assessment?

The benefits go far beyond “fewer alerts.” You get measurable breach-cost avoidance (public-cloud breaches averaged $5.17M in 2024), faster containment, one assessment that satisfies multiple audits, and hard-dollar savings from ingestion tuning that cuts SIEM volume 50 to 90 percent. One customer’s behavioral assessment paid for itself in 90 days by catching a $300K payroll-fraud scheme that rule-based detection missed. Frame ROI in dollars and days, not dashboards.

Put the value in numbers a board will fund

CISOs do not get budget for “better security.” They get budget for avoided cost and faster recovery. So I frame every assessment in board language, the same way I would in a 2026 cybersecurity budget playbook.

• 💰 Breach-cost avoidance: IBM put the 2024 global average breach at $4.88 million, with public-cloud-stored data breaches near $5.17 million.
• ⏰ Faster containment: Cutting even part of the 283-day average containment window is real money saved.
• ✅ Audit efficiency: One solid assessment maps to SOC 2, ISO 27001, and PCI evidence at once.
• 💸 Ingestion savings: Tuning what you ship to your SIEM cuts log volume, and the bill, by 50 to 90 percent.

That audit efficiency is where strong compliance services turn one project into many passed audits.

The $300K nobody was looking for

Here is a story that changed how I pitch this. We ran a behavioral assessment for a client, the kind that watches how people and accounts normally act, then flags the weird stuff.

It surfaced a payroll workflow that looked off. Turned out to be a roughly $300K fraud scheme in motion, the kind a static rule never catches because no single rule was broken. The assessment paid for itself in 90 days, on a finding nobody was hunting for, which is the sort of outcome our MDR for Financial Services is built to catch.

Why “biased” beats “black box”

Here is my contrarian take. Teams fear a model with known bias. I would take a measurable, biased model over a black box every single time, a stance I unpack in our take on AI in cybersecurity.

If I can see the model’s bias, I can correct for it. With a black box, I am trusting a vendor’s marketing. For a board update, I would rather say “here is what our model misses, and here is the human check that covers it,” than “the AI handles it, trust us.”

Q11. What does a continuous cloud security assessment checklist look like?

A practical checklist covers six blocks: scope and shared-responsibility boundaries; identity and access (least privilege, MFA, key rotation); configuration and posture (CSPM, IaC guardrails); logging and detection (synthetic transactions, sub-two-minute alerting); attack-path testing; and continuous reassessment cadence. Run it quarterly at a minimum, validate detection daily, and tie every item to an owner and a fix. A checklist no one owns is just a document.

The six blocks, ready to run Monday

I keep this short on purpose. You should be able to copy it into a ticket and assign each line today, then layer it into your broader security stack guide.

1. Scope and shared responsibility

• Map every cloud account, subscription, and project.
• Confirm what your provider secures versus what you secure (the “shared responsibility model”).

2. Identity and access (IAM)

• Enforce least privilege, so each role gets only what the job needs.
• Require phishing-resistant MFA everywhere, and auto-rotate all static keys.

3. Configuration and posture

• Run CSPM (automated config scanning) against every account.
• Add IaC guardrails, so bad templates fail before they deploy.

4. Logging and detection

• Ship all logs to one SIEM endpoint, suppliers included.
• Run synthetic transactions per data source daily, and prove alerts fire in under two minutes.

5. Attack-path testing

• Test whether findings chain into a reachable breach.
• Fix the choke point, not the raw severity count.

6. Reassessment cadence

• Reassess posture quarterly at minimum.
• Validate detection daily, and assign every item an owner.

For the logging block, our managed SIEM handles the heavy lifting of central ingestion and tuning.

Two free wins before you buy anything

I always tell teams to harvest the free stuff first. You almost certainly own more than you use, a theme I return to often when discussing cybersecurity technical debt.

• ✅ OAuth consent audit: Export consent logs from Microsoft 365 or Google Workspace for a free shadow-app inventory.
• ✅ E5 entitlement audit: If you pay for Microsoft 365 E5, audit it. Most teams already own a dozen-plus security features they never turned on, before buying another point tool.

That E5 audit pairs naturally with dedicated MDR for Microsoft 365.

The question I’m sitting with

Here is what I keep chewing on. As autonomous developer agents start writing and deploying cloud changes on their own, who validates their access, the way we validate a human’s? It is the question driving our work on MDR for AI.

I do not have a clean answer yet. My current read is that agent activity needs its own block on this checklist within a year. If you are already running agents in production, I would genuinely like to compare notes on what is working for you.