Findings & Finding Lifecycle

A Securitain finding is more than an alert — it is a governed security condition with the context required to understand, investigate, decide and track risk over time.

Securitain separates technical risk from workflow status so that accepting or suppressing a finding does not make the underlying AWS condition disappear from risk reporting.

Where to find Findings

The Findings view lets you investigate detected IAM and security conditions and filter by severity, category, account, affected entity and status. Selecting a finding opens the detailed finding view.

What a finding can contain

• Severity — how important the condition is for prioritization
• Title and category — what class of security issue was detected
• AWS account — where the condition was observed
• Affected entity — the user, role, policy or other supported object involved
• Evidence — the information supporting the finding
• Remediation — guidance for addressing the condition where available
• Compliance mappings — relevant technical control mappings where supported
• Lifecycle status — where the finding currently sits
• History — recorded lifecycle changes, actor and reason
• Timestamps — first seen, last seen, status-change times

The key principle: workflow does not rewrite technical truth

Suppose an AWS condition is real. The organization may decide to work on it later, suppress it temporarily or accept it through an approved exception. Those are governance decisions.

Active work queue

The active work queue answers: which findings currently need operational attention?

This can include findings in these lifecycle states:

• Open
• In Progress
• Pending Approval
• Pending Verification

A suppressed or exception-approved finding can leave the immediate active work queue, but it does not leave gross technical risk.

Gross technical risk

Gross technical risk answers: which real technical conditions still exist, regardless of whether the organization has accepted or temporarily suppressed them?

GROSS TECHNICAL RISK
=
Active findings
+
Accepted / suppressed risk

This distinction is one of the most important governance concepts in Securitain. It lets leadership understand what is technically present, what the team is actively working and what has been consciously accepted.

Lifecycle overview

The current finding lifecycle uses three groups. Every status belongs to exactly one group.

Open

Open means the finding is currently active and not yet resolved or accepted. Typical next actions include beginning work, investigating, requesting verification after a change, temporarily suppressing, requesting an exception or classifying as false positive where appropriate.

In Progress

In Progress indicates that the organization is actively working the finding. The underlying risk condition still exists until a later capable scan verifies otherwise. In Progress is therefore part of both the active work queue and gross technical risk.

Pending Approval

Pending Approval represents an active workflow state where a decision requires approval. It remains part of gross technical risk because the technical condition still exists.

Pending Verification

Pending Verification means remediation has been requested or applied, but Securitain has not yet confirmed through a successful capable scan that the underlying condition is gone.

Finding exists
     ↓
Change applied
     ↓
Request Verification
     ↓
Pending Verification
     ↓
Next successful capable scan
     ├── condition absent → Remediated
     └── condition still present → Open

Remediated

Remediated means a successful capable assessment verified that the finding condition is no longer present. A user should not directly mark a finding Remediated merely because a change was attempted.

Suppressed

Suppressed means the finding is temporarily removed from the active work queue. The underlying technical condition still exists. Therefore a suppressed finding remains part of gross technical risk.

Open
 ↓
Suppress temporarily (with reason + expiry)
 ↓
Suppressed
 ↓ expiry
Open

Exception Approved

Exception Approved means the organization has formally accepted the risk through the exception workflow. The finding is no longer part of the immediate active work queue, but it still represents gross technical risk because the AWS condition remains.

False Positive

False Positive means the organization concluded that the detection itself is incorrect — for example, an entity was misclassified, the evidence does not represent the condition claimed, or a detector does not apply to the actual object.

Finding recurrence

Cloud environments change continuously. A condition that was previously remediated can reappear. If a later assessment detects the same underlying security condition again, Securitain can reopen it as a recurrence.

Open
 ↓
Pending Verification
 ↓
Remediated
 ↓
Later configuration drift
 ↓
Condition detected again
 ↓
Open

Verification

Verification is central to the Securitain finding model. The correct workflow is:

Finding
   ↓
Fix applied externally
   ↓
Request Verification
   ↓
Pending Verification
   ↓
Capable scan
   ↓
Condition absent
   ↓
Remediated

Finding history

Securitain records lifecycle history so teams can understand how the risk was handled. A history record can include previous status, new status, actor, source, timestamp and reason. History is important for incident review, security governance, audit evidence and understanding repeated risk decisions.

Active vs Accepted vs Closed

Only Remediated (scan-verified condition absent) and False Positive (detection judged incorrect) are removed from gross technical risk. Suppressed and Exception Approved remain because the technical condition is still present.

When to suppress

Use temporary suppression when:

• the finding is real
• immediate action is intentionally deferred
• there is a documented reason
• the risk needs to re-enter review later

When to request an exception

Use the exception workflow when:

• the finding is real
• the business intends to accept it under governance
• justification is required
• compensating controls may exist
• approval is required

Exception approval is a governance decision, not a technical fix.

When to mark False Positive

Investigation workflow

1. 1

   Read the title and severity

   Understand the initial category and prioritization context.

2. 2

   Identify the affected entity

   Determine what user, role, policy or resource is involved.

3. 3

   Review evidence

   Understand why the finding exists before deciding any action.

4. 4

   Review related context

   Use other Securitain views such as Effective Permissions, Relationship Graph, Privilege Escalation, Blast Radius, Cross-Account, Federation and Sensitive Access.

5. 5

   Decide the action

   Possible outcomes include starting remediation, suppressing temporarily, requesting an exception or classifying as false positive.

6. 6

   Apply changes outside Securitain where required

   Use the recommended remediation guidance. Securitain is read-only by design.

7. 7

   Request Verification

   Do not manually claim remediation. Request verification after the change is applied.

8. 8

   Let a capable scan confirm the outcome

   The result becomes Remediated only when the condition is verified absent by a capable assessment.

Evidence and limitations

Finding quality depends on:

• scan capability
• source evidence
• supported detector coverage
• scan freshness
• account scope

Related guides