From backlog to burndown: running a remediation project in Azure

Most Azure security reviews end the same way. Someone runs a scan, exports the results, and sends a spreadsheet to the people who own the resources. A few things get fixed. Most don’t. Three months later the next review produces a new spreadsheet. Nobody can say which rows are new, which ones were fixed and came back, and which ones were never looked at.

The scanning worked fine. The follow-through failed. And follow-through fails because a list of findings isn’t the kind of thing people can work on.

Why backlogs don’t burn down

A findings backlog has three properties that make it resist progress:

• It has no edges. Four hundred findings across every subscription and severity doesn’t tell anyone where to start, or when they’re done.

• It has no owners. A finding on a shared resource belongs to everyone, which in practice means no one.

• It can’t tell a claim from a fact. “I fixed that last week” and “the setting is actually changed” are different statements. A spreadsheet records only the first.

Projects work because they fix all three: a defined scope, named owners and a finish line someone can check. Remediation needs the same structure.

Step 1: Cut a scope you can finish

Don’t start with “fix everything”. Start with a slice that has a reason to exist:

• “Close internet-exposed management ports”: every finding about open SSH or RDP.

• “Audit prep: production subscription”: everything High and Critical in one subscription.

• “Q4 storage hardening”: public access, shared keys and missing soft-delete on storage accounts.

A good scope fits in one sentence and finishes in weeks. It’s fine for a finding to sit in two projects. The open SSH port on a production VM belongs to both the network cleanup and the audit prep.

Step 2: Give every finding an owner

Assign findings to the people or teams who can actually change the resource. Assigning to a group usually works better than assigning to a person, because “the platform team” outlasts holidays and job changes. Where a resource has an owner tag, use it. The estate often already tells you who owns what.

Discussion belongs on the finding itself, not in an email thread. “Can’t change this until the vendor upgrades — @Maria, can we accept the risk until March?” is far more useful attached to the finding it’s about.

Step 3: Separate what people claim from what the scan sees

This is the step most processes skip, and it’s the one that matters most.

Owners should move their work through a simple status: Planned, In progress, Fix applied. Some findings legitimately end as Risk accepted, with a reason and an expiry date. But Fix applied is a claim. The finding is only resolved when the next scan confirms the setting really changed.

Keeping those two apart solves a familiar argument. If someone says they fixed it and the scan still sees it, there are only a few explanations:

• the fix went to the wrong resource,

• it hasn’t been deployed yet,

• or something put the old setting back.

All of them are worth knowing about, and none of them is visible when “fixed” is just a box someone ticked.

Step 4: Measure progress with a burndown that tells the truth

A remediation project needs one chart: open findings over time, heading toward zero.

The honest version of that chart includes the findings that came back. A storage account fixed on Monday and reopened on Thursday by a deployment pipeline is not progress. Counting it as progress is how teams end a quarter believing the number is low when the real problem is untouched. If something keeps coming back, the useful question isn’t “who forgot to fix it?” but “what keeps putting it back?” Usually the answer is a template or script, and it needs fixing once, at the source.

Step 5: Hand off work to people who aren’t in the tool

Much of the work isn’t done by the team running the governance tool. It’s done by a hosting partner, an application vendor or a product team in another department. They need a document they can read and act on without a login.

A useful hand-off groups findings by issue, not by resource. “These 31 storage accounts allow shared-key access” is one task with one explanation and one fix, even if it touches 31 resources. Include why it matters, how to fix it, a command they can run, and the control it maps to (such as CIS or the Microsoft cloud security benchmark), so the recipient can check the reasoning.

How Praefic does it

In Praefic, this process is built in as Initiatives.

• Create an Initiative and scope it. Filter the findings list by area, severity, subscription or resource group, select what belongs, and add it in one action.

• Assign and discuss. Assign findings to people or groups, and use comment threads with @-mentions on each finding.

• Track two statuses side by side. Owners record Planned, In progress, Fix applied or Risk accepted. Praefic’s rescans decide whether a finding is actually resolved.

• Watch the burndown. Each Initiative shows a status breakdown and a burndown built from finding history, including findings that came back after being fixed. For those, Praefic’s activity data shows who or what reintroduced them.

• Hand off and export. Generate a hand-off document in Markdown or self-contained HTML, grouped by issue, with fix guidance, az commands and CIS/MCSB references. Use the CSV or JSON export for ticket systems.

You can’t fix four hundred findings in one go. But you can run a project with a clear scope, named owners and a finish line the scanner confirms, and then run the next one.

Praefic is built by Just Software. Learn more →