Operations
Remediation
Remediation is the corrective action taken once a finding has been identified, whether that finding is a security misconfiguration, a compliance gap, tenant configuration drift away from an approved baseline, licence waste, or an oversized Azure resource.
Why Remediation matters in a Microsoft estate
Remediation matters when teams need repeatable day-two work rather than one-off fixes. Definitions in this area should help readers connect reporting, review, remediation, backup, drift, and evidence capture to a controlled operating model.
How Remediation shows up in practice
It is the step that turns visibility into an actual outcome rather than a report that gets read once and filed away. Finding a problem and fixing it are genuinely separate disciplines with different skill and risk profiles: identifying that a privileged role assignment violates least-privilege, that a Conditional Access policy has drifted from its baseline, or that a VM is running at a fraction of its provisioned capacity requires analysis and correct interpretation of data, while remediating each of those requires writing and safely executing the specific PowerShell, Graph API call, or portal change that fixes it without breaking something else in the process.
That is why many tools stop at reporting and leave remediation as a manual follow-up task for an already-stretched admin. AI-assisted remediation is increasingly used to close that specific gap, generating the PowerShell or configuration change needed for a given finding inline, next to the finding itself, so an admin reviews and runs a concrete fix rather than researching the correct command from documentation or a forum post. The discipline that keeps this safe is treating AI-generated remediation code as a draft for human review rather than something that executes automatically, since a generated script that is subtly wrong for a specific tenant's configuration can cause more damage than the finding it was meant to fix.
Remediation also spans a spectrum of risk and reversibility that governs how much automation and how much human approval is appropriate at each point: read-only findings and reporting carry no risk and can run continuously and automatically, low-risk remediation such as flagging an inactive licence for review is safe to surface without confirmation, and high-impact, hard-to-reverse actions, most obviously full user offboarding that revokes sessions, blocks sign-in, resets passwords and MFA, cancels meetings, sets a mailbox auto-reply, and removes licence, group, and admin role assignments, should require an explicit human confirmation before running and should be logged step by step, since some of those actions cannot be quietly undone if they were triggered against the wrong account.
Evidence is what separates defensible remediation from remediation nobody can later prove happened: a per-action log showing which specific fix was applied, when, by whom or by which automated run, and whether it succeeded or was skipped, is what an auditor or a Quarterly Business Review needs to see. It is also what protects the organisation if a remediation action is later questioned, since finding a problem, fixing it, and being able to prove both steps happened correctly are three distinct requirements that credible tooling and process both need to satisfy.