Finding Severity & Risk Terminology

Securitain uses several related but distinct security-risk concepts. Using the wrong term for the wrong question leads to bad prioritization and misleading reporting.

SEVERITY         How bad is this technical condition?
SCORE            How risky does this identity appear overall?
STATUS           What is the team doing about it?
BLAST RADIUS     What can this identity potentially affect?
COMPLIANCE       Which controls are relevant to this finding?

Finding Severity

Every Securitain finding uses one of the current supported severity labels. Severity communicates the security significance of the specific detected condition. It is not a lifecycle state.

Severity meanings

Critical

A condition with the potential for severe or broad security consequence, particularly where supported evidence indicates capabilities such as administrative/account-level control, powerful privilege escalation, severe external/public exposure, high-consequence access to protected data, or disabling security boundaries.

High

A significant security condition that can materially increase the ability to obtain unauthorized access, expand privileges, expose sensitive data or weaken important security controls. Impact may be more constrained than Critical due to resource scope, required additional steps, conditions or target privilege level.

Medium

A meaningful security weakness with more limited or conditional consequence. Examples include security control gaps, overly broad permissions with constrained scope, weaknesses requiring additional preconditions, and material hygiene or resilience issues.

Low

A lower-consequence security hygiene or resilience condition. Low findings can still matter, especially when accumulated, repeated across accounts or combined with other permissions.

Info

An informational security observation or context signal. Info is used for context, inventory-related conditions and low-risk posture information. Info does not automatically mean no action is ever required — it means the condition is primarily informational in the current security classification.

Severity does not define remediation SLA

Securitain does not publish universal remediation windows such as “High must be fixed within 24–48 hours.” Security response time depends on business criticality, account context, exploitability, compensating controls and regulatory policy. Organizations with explicit SLA policies should use their own configured standards.

Severity vs Finding Status

A Critical finding with status Exception Approved means: a critical technical condition is being formally accepted under governance. The accepted workflow does not downgrade severity.

Severity vs Finding Category

Severity is not always a score conversion

Findings are produced by different security analyzers and can be assigned severity based on analyzer-specific evidence and rule context. Do not assume every Critical finding is simply a risk score above a fixed threshold — that would be inaccurate across the range of supported detectors.

Entity Risk Score

Some IAM entities and policies receive a Securitain numeric risk score on a 0–100 scale where higher is worse.

Entity Risk Score is not probability

A score of 80 does not mean “80% chance the identity will be compromised.” It is a Securitain prioritization score based on supported security characteristics.

Gross Risk Score

The IAM Overview displays a Gross Risk Score on a 0–100 scale where higher is worse. It summarizes multiple current IAM risk signals. Qualitative factors that can contribute to the score include:

• Critical findings whose technical condition still exists
• High findings whose technical condition still exists
• MFA coverage
• old access keys
• privilege-escalation context

Gross technical risk

Active risk

Active findings are current workflow items in statuses such as Open, In Progress, Pending Approval and Pending Verification. Active describes the workflow group — it does not describe severity.

Accepted risk

Accepted technical risk includes Suppressed and Exception Approved findings. The finding leaves the immediate active work queue but remains part of gross technical risk. Accepted risk is a governance decision — it is not a security improvement by itself.

Blast Radius Score

Blast radius evaluates the potential consequence/reach associated with an identity. It is designed to answer: If this identity were controlled, what could it potentially affect?

Blast Radius Score is not:

• probability of compromise
• finding severity
• percentage of AWS resources compromised
• a compliance percentage

Least-Privilege Risk Score

The Least Privilege Advisor can use a risk score to prioritize permission right-sizing opportunities. Interpret it as: Which over-permissioning opportunity deserves review first? It is not a percentage of permissions safe to remove or certainty that unused access is unnecessary.

Remediation risk reduction

A remediation can have a risk-reduction indicator. This is a prioritization concept. It does not mean the exact business risk will decrease by a specific percentage. Actual change depends on customer execution, target scope, other remaining permissions and verification.

Compliance posture is not risk score

Compliance Mapping is finding-to-control mapping. A compliance posture indicator must not be presented as a finding severity, a Gross Risk Score or a certification percentage. Keep the concepts separate.

AI confidence is not severity

Why Securitain uses multiple risk concepts

One number cannot answer every security question.

Finding Severity    How bad is this condition?
Entity Risk Score   How risky does this identity appear overall?
Attack Path         How can privilege increase?
Blast Radius        What can this identity potentially affect?
Finding Status      What are we doing about the risk?
Gross Technical     What technical conditions still remain?

Example

Role: DeploymentRole

Finding:          Cross-account trust
Severity:         High
Status:           Exception Approved
Entity Risk:      78
Blast Radius:     High

Interpretation:

• the specific trust condition is High severity
• the organization has formally accepted it through governance
• the condition still contributes to gross technical risk
• the role itself has an elevated entity risk score
• the role can potentially affect a broad set of resources and capabilities

Severity and evidence

Severity should always be interpreted with:

• affected entity
• policy/resource scope
• conditions
• evidence
• target consequence
• account context
• scan freshness

Related guides