Risk engine

Not every datastore that holds sensitive data is equally dangerous. A public, unencrypted bucket full of card numbers is a fire; the same data, private and encrypted, reachable only by two service roles, is a managed risk. The risk engine turns that judgment into a number so your worst exposures rise to the top of the list on their own.

Every scanned datastore gets a risk score from 0 to 100 and a band:

Band	Meaning
Critical	Sensitive data with a live path to loss - fix now.
High	A serious gap; schedule remediation this cycle.
Medium	Real but contained; work it after the highs.
Low	Minor exposure worth tracking.
Minimal	Sensitive data present but well-contained.

What the score is built from

The base score combines four signals. In rough order of how much they move the number:

• Exposure - is the data reachable? A confirmed-public store scores at the top of this signal; a private one starts low. This is weighted the heaviest, because exposure is what turns sensitive data into an incident.
• Content sensitivity - what was found. Credentials, financial data, and health data weigh far more than a name or an email address, and a datastore holding several distinct sensitive types is treated as worse than one holding a single type.
• Volume - how much, measured as the share of the datastore estimated to be sensitive, not a raw count, so a small store that is almost entirely sensitive ranks appropriately.
• Detection confidence - how sure the classifier is about those findings, so a pile of low-confidence guesses does not inflate the score the way confirmed matches do.

Unverifiable exposure is treated as exposed

If the agent cannot confirm whether a store is private (for example AWS returns Access Denied on the public-access check), Argus assumes the worse case and scores it as exposed, then flags the score as unverified. A blind spot is never scored as safe. The fix is to grant the agent the missing read permission, not to change the data - see IAM permissions.

What amplifies it

The base score is then adjusted by factors that change the real-world blast radius:

• Reachability (IAM). Who and what can actually get to the data. Public access, stale grants that should have been revoked, external or cross-account access, and identities with far more reach than they use all push the score up. A store only two tight roles can read is treated very differently from one a hundred stale principals can.
• Compliance pressure. A datastore that fails a high-severity compliance control is riskier than the raw data alone suggests, and the score reflects that.
• Datastore type. Warehouse and database engines carry a slightly higher baseline than object storage, reflecting how much sensitive data they typically concentrate.
• Recent trend. Risk that is climbing is weighted more heavily than risk that is falling - a store getting worse gets your attention faster than one slowly improving earns relief.

The exact weights and thresholds behind these are tuned internally, but the direction is always the one you would expect: more exposure, more sensitive content, more reach, and active compliance gaps all raise the score.

From datastores to tenant posture

Per-datastore scores roll up into the tenant view on the Risk dashboard:

• An overall posture score and band across all scanned datastores. The overall band is not a simple average - a single Critical store pulls the whole tenant toward Critical, because one serious exposure is a tenant-level problem.
• A severity distribution - how many datastores sit in each band.
• Top risk drivers - the specific factors contributing most of your total risk right now (for example “public sensitive data” or “critical PII”), so you can see why the number is what it is, not just what it is.
• The top datastores by score, each with its open alerts and policy violations, as your triage worklist.

Hidden and stale/not-found datastores are excluded from the rollup, so posture reflects what is actually live in your environment.

Identity risk is scored separately

The reachability factor above lets IAM exposure influence a datastore’s risk. Scoring the identities themselves - which principals are over-privileged, stale, or missing MFA - is a separate engine with its own score and bands, covered in Identity & access risk. The two work together: identity risk explains the reach, datastore risk explains what is at the end of it.