Recommendations

Recommendations are the “what should I do” layer. Alerts tell you something is wrong, risk tells you how badly, and a recommendation tells you the specific action that would improve it, with the projected effect of taking it.

The page is organised around one idea that makes it far more useful than a flat list:

Recommendations are grouped by fix, not by resource

One row is one kind of fix, with a count of how many resources it applies to. So instead of forty rows saying “enable encryption on this bucket”, you get one row saying “enable encryption” with 40 affected subjects.

This matters because it changes what you plan. Forty findings look like forty tickets; one recommendation across forty buckets is a single afternoon with a single workflow. The grouping is the difference between a backlog and a plan.

The stat strip

Open Recommendations, Affected Resources, and Projected Risk Reduction, the last as a negative number since it is the amount your score would drop if you did the work.

Projected risk reduction is the number to prioritise on. Severity tells you how bad something is; projected reduction tells you how much your posture actually improves for the effort, and the two do not always agree.

The table

Column	Notes
Recommendation	The fix, with its description
Severity	Critical, High, Medium, Low
Risk Reduction	Projected score improvement if applied
Effort	Low, Medium, or High
Category	Access Control, Security, Encryption, Compliance, General
Applies To	Identity, Datastore, or both
Affected	How many resources this fix would touch

Read Risk Reduction against Effort. A low-effort fix with a large reduction across many subjects is the best work available to you, and it is often not the highest-severity row on the page.

Filters cover severity, subject type, and category, with a search across titles.

Statuses, and why you cannot close one yourself

Recommendation status is system-controlled. There is no button to mark one done, for the same reason there is no button to resolve an alert: a recommendation is closed when the underlying condition changes and a scan confirms it, not when someone says so.

Status	Meaning
Open	Live, unaddressed
Reopened	Was closed, and the condition came back
Pending	A remediation run is waiting on human approval. The only status asking you to act
Remediating	A remediation run is in flight. In hand, wait
Mitigated	Contained by a compensating control, but the underlying finding is still there
Resolved	Genuinely fixed and verified
Dismissed	The subject no longer exists, so the recommendation is moot

Two of these are worth dwelling on.

Pending and Remediating are derived, not stored. They are computed at read time from the linked remediation execution, which is why they can change without anything happening to the recommendation itself. Underneath, the recommendation still holds its real persisted status. Practically: if a run is waiting for approval, every surface showing that recommendation says Pending, and approving the run changes all of them at once.

Mitigated is not Resolved, and is deliberately not green

A mitigated recommendation means a compensating control is limiting the damage while the root cause remains. Enforcing MFA on an account that still has no MFA is the canonical example: the risk is contained, the finding is not gone.

Argus treats Mitigated as still live work, keeps its fix runnable, and gives it a distinct colour from a real fix precisely so a mitigation cannot quietly pass for a resolution on a dashboard. If you only ever mitigate, your posture looks handled while the underlying problems accumulate.

Related: Resolved and Dismissed are the only genuinely closed states. Mitigated ranks as “handled” for triage ordering, so it sorts down and greys out, but it never counts as closed.

The recommendation detail drawer

Overview carries category, severity, effort, projected risk reduction, the count of affected subjects, related alert count, what it applies to, and the recommendation ID (for example REC-IAM-002). Quote that ID in tickets and support conversations; it is stable, whereas titles are display text.

Suggested Actions is the concrete steps the fix involves. Read this before running anything, especially for identity fixes, since detaching a policy or disabling a key has immediate consequences for whatever was using it.

Affected Subjects lists every datastore or identity the fix applies to, each linking to its own drawer, with handled ones sorted to the bottom so live work stays at the top.

Related Alerts shows the alerts arising from the same conditions, so you can see what closing this recommendation would quiet.

Running the fix

Where a remediation workflow exists for a recommendation, you get a run affordance directly on the recommendation, without going to the Remediation page. It appears only if you hold remediation:execute and the tenant has remediation execution enabled. Consistent with the rest of the product, an action you cannot take is hidden rather than shown disabled, so its absence may mean permissions rather than “no fix exists”.

One rule governs which workflow runs:

A workflow attached to a recommendation is the only one that can run for it

If a workflow is explicitly linked to a recommendation, it wins outright, even when its trigger is Manual. That combination is a deliberate setup, not a misconfiguration: “this is the approved fix, but only ever run it by hand.”

Without an explicit link, Argus falls back to matching by template: an enabled workflow whose target type matches the subject and whose recommendation-template list includes this one. So an attached workflow is how you pin a specific fix to a specific recommendation and stop the generic one from being offered.

The run itself, including dry-run and approval behaviour, is covered in Remediation. Nothing about running a fix from here skips those gates.

Where recommendations surface

Recommendations are not confined to this page, which is intentional: the fix should appear where you notice the problem.

• The identity drawer shows them against a risk factor, badged Fix available, so a factor and its remedy sit together. See Identity & Access.
• The datastore drawer and the alert drawer both carry a Recommendations section.
• The compliance control drawer shows the recommendations that would close that control. See Compliance.

They are all the same objects. ?template_id= deep-links a specific recommendation group, which is what those cross-links use, and ?subject_type= pre-filters to identities or datastores.

How they are generated

Recommendations come from the same signals that drive risk, classification, and identity analysis: an over-privileged identity, an unencrypted store holding financial data, a stale access key. The engine’s inputs and how a fix is chosen are covered in Recommendations & remediation. What matters operationally is that they are derived, not authored: you do not create recommendations, and they disappear on their own when the condition that produced them goes away.