The foundation can now enforce, but it still cannot answer the two questions every operator eventually has to answer. Is this estate configured well right now, measured against something better than an opinion? And when something goes wrong, what actually happened, who did it, when, and from where? Those are different questions with different answers, posture and the record, and neither of them arrives for free just because you built the platform well. This article is about standing both up as platform services the foundation owns, so that the estate can see itself on an ordinary day and so that on the worst day you are reading logs instead of wishing you had kept them.
Two questions the foundation now has to answer
Keep the two apart, because they get solved by different services and conflating them is how people end up with neither. Posture is the continuous question: given everything deployed, how far is the estate from a known-good standard, and what are the highest-value things to fix? The record is the forensic question: something occurred, and the evidence of it either exists or it does not. Posture is a dashboard you glance at on a Tuesday. The record is the timeline you reconstruct at two in the morning. Both belong to the platform, not to the workloads, and both live in the management corner of the tree you already built, because they serve the whole estate and outlive any single thing running in it.
One boundary before we go further, because it is the boundary this whole design depends on. This article is about posture and about keeping records. It is not about threat detection. Watching endpoints and identities for active attack, correlating signals into incidents, running a security operations capability, that is Microsoft Defender XDR and eventually Microsoft Sentinel, and it is a discipline and a series of its own. A small organization that lets a posture conversation sprawl into standing up a security operations centre it has nobody to staff has lost the plot. Build the posture and build the record now, because they are cheap and they are foundational. Add detection when there is someone to act on it.
Posture is already on, and mostly free
Microsoft Defender for Cloud is enabled on every Azure subscription by default in its foundational posture tier, at no cost, and the first thing to do with it is nothing, because it is already doing the right thing. It gives you a Secure Score, a prioritized list of recommendations, an asset inventory, and continuous assessment against the Microsoft Cloud Security Benchmark, which is the same standard the policy baseline two articles from now will lean on. Turn none of it off. Document the Secure Score on the day you hand the foundation over, set a target, and treat the trend as one of the few numbers that actually says something about whether the estate is drifting toward or away from good.
Above the free tier sit paid plans, and they are decisions rather than defaults. The paid posture plan, Defender CSPM, deepens the picture with attack-path analysis and agentless scanning, and it is worth knowing about but rarely the first spend for an organization this size. The plan that actually earns its place on a hybrid estate is Defender for Servers, because it is the one that reaches inside the machines you are still running, and it is the one worth deciding deliberately.
Defender for Servers, and the plan you actually pick
There are two plans and the difference between them is the difference between watching a server and understanding it. Plan 1, in the region of five dollars per machine each month, is essentially the Microsoft Defender for Endpoint integration extended to servers: the endpoint detection and response agent, provisioned and reporting. If the goal is simply that your servers carry the same endpoint protection your laptops already do through Business Premium or E3 or E5, Plan 1 is the floor and it is enough. Plan 2, in the region of fifteen, adds the machine-level posture that a small team genuinely benefits from: agentless vulnerability scanning, file integrity monitoring, just-in-time access that keeps management ports closed until someone asks, regulatory and baseline assessment, and a data ingestion allowance of five hundred megabytes per machine per day toward the security tables, which quietly offsets a real part of the logging cost we are about to discuss.
Plan 1 makes a server something you protect. Plan 2 makes it something you understand. On a hybrid estate with a handful of virtual machines and no jump box, the just-in-time access alone is often worth the difference.
I will not pick it for you, because it is a real cost against a real budget, but I will tell you how I decide. If the estate is a few servers and the priority is endpoint protection parity, Plan 1. If the estate has virtual machines you administer directly and you would otherwise be reaching for a bastion host or leaving management ports open, Plan 2, because just-in-time access replaces that expense and closes that exposure at once. The plan is enabled at the subscription scope and covers every machine of that type in the subscription, so it is a conversation to have before you flip it on a subscription full of virtual machines, not after the first bill.
The record is one workspace, and everything reports to it
The record is a single central Log Analytics workspace, living in the management area of the platform, and the discipline is that everything reports to it and nothing keeps its own private log. Azure activity logs from every subscription, resource diagnostic logs from the services that matter, Defender for Cloud alerts, the Entra identity signals, Intune device logs, guest logs from inside the virtual machines, and the network flow logs all land in the same place. The reason is simple and it is the reason people learn the hard way: an incident is a timeline, and a timeline scattered across ten workspaces is not a timeline, it is ten fragments nobody can align while the clock is running. One workspace is a decision you make now because it is nearly impossible to make retroactively.
Two of those feeds deserve a specific note because they do not arrive the way the others do. The Entra identity signals, the sign-in logs and the audit logs, are exported through Entra’s own diagnostic settings, a separate path from Azure resource diagnostics, and the Conditional Access outcomes ride inside those sign-in records rather than in a stream of their own. That matters here because it closes a loop the identity article opened. The break-glass accounts you hardened are supposed to be silent until the day they are used, and the exclusion groups your Conditional Access framework depends on are supposed to be watched, and this workspace is where those promises are kept: the break-glass sign-in alert and the exclusion-group change alert that the Conditional Access framework mandates fire from the signals landing here. Identity produces the events. The record is where they raise an alarm.
Cost is a design input, not a surprise on the bill
A central workspace has a cost shape, and you either design it in or it designs itself into your invoice. Three levers keep it honest. Retention is the first: roughly a month of interactive retention is included in what you already pay to ingest, and I extend the operational floor to ninety days deliberately, as a per-gigabyte charge I accept, because the incident you investigate is frequently weeks old and a record that has already aged out is not a record. The second lever is the table plan. High-volume data that you keep for evidence but almost never query interactively, network flow logs being the obvious case, belongs on the cheaper Basic or Auxiliary table plans rather than the Analytics plan you reserve for the data you actually search. Paying Analytics rates to store flow logs you look at once a year is the most common way these workspaces get expensive for no benefit.
The third lever is the daily cap, and it is worth being precise about what it is, because it is easy to misuse. The cap stops billable collection once a day’s threshold is hit, which makes it a genuine protection against a runaway ingestion spike and a genuine liability if you treat it as a budget, because a workspace that has stopped collecting is a workspace that is blind for the rest of the day. Set it as a safety net well above normal volume, alert yourself before it trips rather than after, and never rely on it to manage cost the way you would a smaller retention window or a cheaper tier. One dated note that belongs in the design: the old network security group flow logs are being retired, new ones can no longer be created and the feature is fully gone in 2027, so the network feed here is VNet flow logs from the start, and it is exactly the feed that belongs on a cheap tier.
What the record is for, and what it is not
The record is the evidence base for the day something goes wrong, and increasingly it is the thing a cyber-insurer expects you to be able to demonstrate rather than assert. It is not, by itself, detection, and it is important not to pretend otherwise. Nobody sits and reads these logs all day, and a design that assumes they will is a design that fails quietly. What watches the record is a small set of Azure Monitor alerts on the signals that must never pass unseen: the break-glass sign-in, a new Owner appearing anywhere in the estate, a high-severity Defender finding, a budget crossing its threshold. Everything else sits queryable, waiting for the investigation you hope never to run, which is precisely when you will be grateful it is all in one place and still within retention.
The last thing worth saying is what this workspace becomes later. It is built so that Microsoft Sentinel is a switch rather than a rebuild: the connectors activate against data already flowing, in the Microsoft Defender portal where security operations now live, on the day the organization has someone to act on what Sentinel surfaces. Until that day it is a decision correctly deferred, not a gap. What you cannot defer, and cannot reconstruct after the fact, is the record itself. That is why it goes in now, ordinary and unglamorous, so that the estate is keeping evidence long before anyone has a reason to read it.
Building it is a short, specific sequence: the workspace, the Defender plans turned on with the cost understood, the diagnostic settings pushed across the tree by policy so that a resource created next year reports to the record without anyone remembering to wire it, the handful of alerts that matter, and a test that proves a resource’s logs actually arrive. The build sheet does exactly that, and then the series turns to the enforcement layer that has been deferred since the beginning, which is policy.
Azure Landing Zones
‹ Previous: [LZ 5.1] Standing Up Identity and Access
Next: [LZ 6.1] Standing Up Posture and the Central Record ›
