Finding Status Reference

The canonical lifecycle states used by Securitain findings — what each status means, how findings move between them and which statuses remain part of gross technical risk.

Finding status describes what is happening to the finding operationally. It does not change finding severity, the underlying AWS configuration or evidence unless a new scan or governance action changes that underlying context.

Status groups

Every current finding status belongs to one of three mutually exclusive lifecycle groups.

Active group

The finding is still in the active lifecycle. The technical condition remains part of gross technical risk.

Accepted group

The finding is no longer in the immediate active work queue. The technical condition still exists and remains part of gross technical risk.

Closed group

The finding no longer contributes to gross technical risk. The two closed statuses have very different meanings:

• Remediated: a capable scan verified the technical condition is absent.
• False Positive: a human determined the detection itself is incorrect.

Gross-risk set

Gross Technical Risk
=
Active (Open / In Progress / Pending Approval / Pending Verification)
+
Accepted (Suppressed / Exception Approved)

NOT included:
Remediated — condition verified absent
False Positive — detection determined incorrect

Actionable vs Active

The backend also distinguishes findings that still need a direct human action. Current actionable statuses are Open, In Progress and Pending Approval. Pending Verification is still Active and contributes to gross risk, but it is waiting for scan verification rather than an additional human decision. This distinction is useful for work queues.

Open

The finding is active and currently available for investigation and work. Common current actions depending on workflow: Start Work, Request Verification, Suppress Temporarily, Mark False Positive, Request Exception.

In Progress

The team has started working the finding. The technical condition is still present until verified otherwise. Common actions: return to Open, Request Verification, Suppress Temporarily, Mark False Positive, Request Exception.

Pending Approval

The finding is waiting for an approval-related workflow decision. It remains active. Pending Approval is a workflow-driven state — there is not necessarily a dedicated status-change button for this state in every UI context.

Pending Verification

The customer believes a remediation change has been applied and is waiting for a successful capable scan to verify the original condition is gone.

Pending Verification
     ↓
Successful capable scan
     ├── condition absent  →  Remediated
     └── condition present →  Open

Suppressed

Suppression requires a meaningful reason and a future expiry. The backend enforces a minimum reason length and a maximum suppression duration of 365 days.

Suppression expiry

Suppressed
    ↓
Expiry
    ↓
Open

The finding returns to the active work queue when suppression expires. The technical condition never stopped being part of gross technical risk during suppression.

Exception Approved

The finding is a real technical condition that has been formally accepted through Securitain's exception workflow. This state is managed through Governance → Exceptions rather than the generic finding status action. To end the accepted-risk decision, use the exception workflow: revoke, expiry or later remediation.

Remediated

Apply change
    ↓
Request Verification
    ↓
Pending Verification
    ↓
Successful capable scan
    ↓
Remediated

Remediated recurrence

Cloud configurations can drift. If a later scan detects the same condition again:

Remediated
   ↓
Condition reappears in later scan
   ↓
Open

False Positive

The organization determined that the detection itself does not correctly represent the security condition. A normal later scan does not silently reopen a False Positive simply because the detector emits the same key again — the human classification persists. A user can intentionally reopen the finding if needed.

False Positive vs Exception Approved

Reopen

Current lifecycle allows closed or accepted findings to return to Open in supported cases. Examples:

• Remediated finding intentionally reopened
• False Positive reconsidered by the team
• Suppression ended manually before expiry

Exception Approved is managed through the exception workflow rather than generic Reopen.

Status history

Every lifecycle change should preserve history. Current history semantics include:

• from status and to status
• reason
• actor
• source (user action or system/scan)
• timestamp

This supports auditability, governance, recurrence analysis and remediation evidence.

User transition vs system transition

Status transition reference

Why status does not change severity

A Critical finding suppressed is still a Critical technical condition. Status tells the business decision and workflow. Severity tells the technical significance. They are independent dimensions.

Why status does not change evidence

Suppressing or approving an exception should not delete the evidence that created the finding. The evidence remains useful for governance, audit and future remediation.

Related guides