You've written up a finding and given it a risk rating. Now comes the part most tools fumble: what happens next. This is the workflow that carries a finding from “we found it” to “we've dealt with it”, whether dealing with it means fixing the problem or making a clear-eyed decision to live with it. Let's walk the common path on a real finding first, then unpack the pieces.
Choose how to treat the finding
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 and needs a treatment decision. You can work to remove it, or accept it with a recorded reason. Here are the two paths.
The finding is rated and needs a treatment decision.
Choose a treatment
Mitigate
Work through the recommendations. The finding stays Mitigating while any remain open.
Mitigated when every recommendation is resolved.
Accept
Record why you can live with the risk and choose when to review the decision.
The status changes after you confirm the decision.
You choose how to treat the risk. The status then follows that decision and your progress. A finding with open recommendations stays Mitigating until the work is resolved.
Accepting a risk, on the record
If you decide to live with the risk, choose Accept, record the reason and set a review date. The observation becomes Risk Accepted after you confirm. The decision records who accepted it and when.
A useful justification explains why the remaining exposure is tolerable and which assumptions the decision depends on. See reviewing accepted risk for scheduling and recording the next review.
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.
No existing controls documented.
Flip the Conditional Access toggle to block legacy authentication protocols (IMAP, POP3, SMTP AUTH, older ActiveSync) across the entire tenant. Microsoft provides a built-in policy template for this, so use it.
Enable logging for legacy auth attempts in Entra ID and feed those logs into your SIEM. Set up alerts for repeated failed attempts or successful logins from unexpected locations.
Run an audit to identify which accounts or applications are still using legacy auth. Record each dependency and migrate it to modern authentication before enforcing the block.
Mitigated does not mean risk-free
Mitigated describes completion of the treatment workflow. Completed and Won't Do both count as resolved recommendations. The badge does not certify that every proposed control was deployed or that the remaining risk is acceptable.
An observation can be Mitigated and still sit outside risk appetite. Review the residual risk after the work: add further treatment if needed, or make an explicit acceptance decision with the appropriate authority. See risk rating and appetite.
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 legacy integration is excluded 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.
- Legacy authentication protocols (IMAP, POP3, SMTP AUTH, older ActiveSync) are blocked tenant-wide via the Block-legacy-auth Conditional Access policy, enforced since 18 Jun after a week in report-only.
Enable logging for legacy auth attempts in Entra ID and feed those logs into your SIEM. Set up alerts for repeated failed attempts or successful logins from unexpected locations.
Run an audit to identify which accounts or applications are still using legacy auth. Record each dependency and migrate it to modern authentication before enforcing the block.
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.