Findings

The Findings module is your organization’s gap register. Every observation, gap, deficiency, or remediation item raised by an assessment, an audit, a monitor, an evidence review, or any other source lives here as one finding. Each finding has an owner, a severity, a due date, and a status that walks through triage, remediation, and verification.

This is the operational center of remediation. When something is not as it should be, a finding gets opened. When the underlying gap is fixed, the finding gets closed with verification. Between those two states, Findings is where the work is tracked.

When you would reach for this

You set up findings when:

• An assessment produces a result that needs remediation.
• An auditor (internal or external) records an observation.
• A monitor detects drift or failure and the team decides the failure needs tracking.
• An evidence review identifies that required evidence is missing or stale.
• A control walkthrough finds the control isn’t operating as designed.
• A manual review uncovers a gap that doesn’t fit any other source.
• An external scanner (a vulnerability scanner, a configuration scanner, a code-quality tool) raises something worth tracking in the governance program.

You don’t reach for this when capturing a risk (risks is for strategic risk decisions; findings are for concrete gaps) or recording a waiver from a control’s normal operation (that’s Exceptions).

What lives in a finding

A single record type:

Finding carries:

• A title and a stable key you pick, plus a description.
• A source kind (assessment, audit, evidence_gap, control_gap, obligation_gap, risk_review, manual, module_signal) and an optional source reference identifying where the finding came from.
• A subject reference identifying what the finding is about (the control with the gap, the obligation that’s missed, the asset that’s vulnerable).
• A severity (free text — your organization picks the vocabulary; common values are critical, high, medium, low, informational).
• A status: open, triaged, remediation_planned, remediating, verified, closed, accepted, archived.
• An owner (a responsibility assignment or a specific member user).
• A due date for remediation.
• A closed date once closure happens.
• An optional lifecycle instance linking to the remediation lifecycle workflow.

Source kinds

Where a finding originated. The source kind matters because audit reviewers want to know whether a gap was self-identified, externally identified, or surfaced by automated tooling:

Status lifecycle

Findings walk through a standard set of statuses, but your organization picks how strict the walk is:

Verification matters: verified is distinct from closed. A team can self-claim remediation, but the finding doesn’t close until someone other than the doer confirms it.

A worked example: a software product company manages findings from scanners and audits

A software product company runs multiple automated security and quality scanners across its codebase, build pipeline, and infrastructure: a static-analysis tool, a dependency-vulnerability scanner, a configuration scanner for its cloud accounts, and a periodic external penetration test. The security engineering lead, Tomek, also runs internal control assessments quarterly.

All of these produce gaps. Without a central place, they live in tickets, scanner dashboards, and spreadsheets. With Findings, they live in one register.

Step 1: automated ingestion from scanners. Tomek’s team builds small integrations from each scanner into the Findings API. Each scanner finding becomes one finding record:

• Source kind: module_signal for automated tools, audit for the external pen test.
• Source reference: the scanner’s own finding ID.
• Subject reference: the affected control or asset.
• Severity: mapped from the scanner’s severity vocabulary into the organization’s standard.
• Status: open by default; the integration uses an idempotency key so re-runs don’t create duplicates.

Step 2: assessment-driven findings. When Tomek’s quarterly self-assessments complete, any failed test step or failed sample produces a finding automatically. Source kind is assessment, source reference is the assessment.

Step 3: triage cadence. Every morning the security engineering lead reviews new open findings and either:

• Triages: assigns owner, due date, and severity (might adjust the scanner’s severity based on organizational context).
• Dismisses: moves to archived with rationale (false positive, duplicate of an existing finding, out of scope).
• Accepts: moves to accepted with rationale and a link to a risk acceptance.

Step 4: remediation. Triaged findings get a remediation_planned status when the team decides what to do, then remediating while work happens. Findings link to issues in the engineering team’s task tracker through the description and the lifecycle instance.

Step 5: verification. When the engineer reports remediation complete, the security engineering lead (someone other than the engineer) verifies through a follow-up assessment or evidence claim. The finding moves to verified, then closed.

After a year:

• The finding register has thousands of records, mostly closed.
• Open findings are filterable by severity, owner, source, and due date.
• Overdue findings are surfaced separately.
• An auditor can see “every gap we found and what we did about it” without leaving Novantra.

What you’ll see in the product

Findings lives under Governance → Findings in the workspace.

The Findings list is your gap register: every finding with status, severity, owner, due date, and source. Filter by status, severity, source, owner, subject, or date range. Sort by severity and due date to see what needs attention first.

Inside a finding, you see:

• The full title, description, source reference, subject reference.
• The owner, due date, current status.
• Linked evidence (any evidence claims that informed the finding, or that demonstrate remediation).
• Linked exceptions (if a waiver was attached).
• Linked risks (if the finding was promoted to a risk).
• The lifecycle instance, if remediation is tracked through a governed lifecycle.
• Status history and audit trail.

Every change is captured in the workspace Audit Log.

Findings and risks

A finding is a concrete gap that needs to be remediated. A risk is a strategic posture decision. These are related but different:

• A vulnerability scanner finding is typically a finding: fix the vulnerability, close the finding.
• A discovery that “the vendor we depend on has a 2-day SLA but we need a 4-hour SLA” might become a risk (strategic, requires treatment decision) more than a finding (concrete, fixable gap).

Findings can be promoted to risks when the gap is too systemic to fix with one remediation. The promotion preserves both records and links them. Findings can also link to existing risks for context.

Common workflows

Ingesting from a scanner

1. Scanner runs, produces a list of findings on its side.
2. Integration calls POST /api/v1/governance/findings for each scanner finding, using a stable idempotency key derived from the scanner’s finding ID.
3. New findings arrive as open in Novantra.
4. Daily triage assigns owners and due dates.

Triaging the morning queue

1. Filter Findings by status: open.
2. Sort by severity, then by created date.
3. For each: assign owner, adjust severity if needed, set due date, transition to triaged. Or dismiss / accept as appropriate.

Verifying remediation

1. Owner reports remediation complete.
2. A different reviewer reviews the evidence of remediation (often through a new evidence claim or a follow-up assessment).
3. Reviewer transitions the finding to verified.
4. Subsequent state to closed after final review.

Accepting a gap

1. The team decides not to remediate.
2. Create a corresponding entry in Exceptions or Risks with formal approval.
3. Transition the finding to accepted, linking to the acceptance record.

Looking for the API?

See Findings API reference for the v1 REST endpoints to list, inspect, and create findings from an external system.

Related

• Assessments - the most common source of findings.
• Evidence - evidence demonstrates a finding’s remediation.
• Risks - findings can promote to risks.
• Exceptions - acceptances reference findings.
• Monitoring - monitor failures can create findings automatically.
• Controls - findings are typically about a control gap.