After the finding: how risk treatment actually works.

From found to mitigated

Say you've logged a finding: legacy authentication is still switched on in your Entra ID tenant, the old protocols that skip MFA. It's rated, it's real, and you want it gone. The whole lifecycle, from a new finding to a closed one, fits in one picture.

The thing to notice: you choose the path, but you never set the status. It's computed from your decision and your progress, so the badge can't drift from reality. A finding with open work can't show as Mitigated, because nobody types the badge in the first place.

Accepting a risk, on the record

Mitigating isn't the only honest answer. Sometimes the fix costs more than the risk is worth, or it depends on a system you don't control this quarter, and the right call is to accept the risk and move on. That's a legitimate treatment, not a cop-out. The whole weight sits on one word, informed: accepting a risk is fine as long as someone made a deliberate decision and can say why. Recording exactly that is what the app is for.

So accepting is a deliberate step, not a stray click. Clicking Accept doesn't flip the status. It opens a justification box, and the confirm button stays disabled until you've written your reasoning. The decision and the justification are saved together, and only then does the badge read Risk Accepted.

That order is the point. A risk accepted with no recorded reason is just a risk ignored, so the status won't move until the justification is there to stand behind it. It's written to the audit log too, so there's a record of who accepted what, and when.

How recommendations are tracked

Back to the mitigate path, because the recommendation tracker is where the work actually lives. Each recommendation carries its own status, so a finding is never vaguely “in progress”; you can see which specific pieces are done and which aren't. There are four states.

• Open. Not started.
• In Progress. Someone's on it.
• Completed. Done, with notes on what was actually deployed.
• Won't Do. A deliberate decline, with notes on why. A real outcome, not a gap.

Two of those are terminal: Completed and Won't Do. The finding only reaches Mitigated when every recommendation has landed on one of them, so you have to consciously close each item instead of letting three of five quietly lapse. “Won't Do” earns its place: declining a recommendation on purpose, with a note on why, is a real decision, not an oversight.

Here's the tracker on that Entra ID finding, partway through: three recommendations, each with its own status and notes. One's completed, one's in progress, and one's a deliberate Won't Do, so two of the three count as resolved.

From recommendation to deployed control

When a recommendation is done, one button promotes it into the finding's list of existing controls, turning a plan into a fact. The rewrite is done by AI, and here's the part to know: it reads your completion notes, not just the original recommendation text. So if the recommendation said “block all legacy auth” but your notes record that one service account still needs an app password for now, the control describes what actually shipped rather than what was hoped for. Where the recommendation and your notes disagree, your notes win.

Promote the completed recommendation and it moves into Existing Controls, rewritten as a statement of fact, and drops off the active list. The same finding now looks like this.

The work changes the risk, so re-score it

One piece from the walkthrough deserves its own note: re-scoring. A risk you've half-fixed isn't the risk you first rated, so once there's real progress the “Re-assess risk with AI” button hands the model the current state (the summary, the controls now in place, every recommendation with its status and notes) and proposes an updated likelihood, impact, and rating.

Nothing applies on its own. You get a side-by-side of current versus proposed with the reasoning for each change, and you decide. Same rule that runs through the whole workflow: the system computes and proposes, a person commits.

One finding, one owner

A finding is assigned to a single person, not split across its recommendations. That assignee owns the whole thing, and it shows up on their dashboard under My Tasks. Splitting ownership per action sounds tidy, but it just diffuses responsibility. One name on the finding is the worklist that actually gets worked.

The shape of it

• ✓A finding moves from Awaiting Triage to Mitigated as you complete its recommendations.
• ✓Mitigate to reduce the risk, accept to live with it. Both are valid treatments; accept just has to be a recorded, deliberate decision.
• ✓Recommendations are tracked one by one through Open, In Progress, Completed, or Won't Do. The finding closes only when each is resolved.
• ✓A completed recommendation can become a deployed control, with the AI reading your notes so it reflects what actually shipped.
• ✓Re-score the residual risk with AI as you go, but nothing applies until you approve it.
• ✓Accept justifications are encrypted at rest and audit-logged: who accepted what, and why.