Appearance
Findings
Where to find it: Risk Management, then Findings (/findings).
A Finding (FND-YYYY-NNNN) is an identified deficiency: something that is not as it should be, recorded so it can be tracked to resolution.
Findings come from several places
The register unifies findings from across the platform, and keeps their source visible because the source determines the lifecycle.
| Source | Where it originates |
|---|---|
| RCSA / Control Assessment | Control self-assessment and testing |
| Regulatory / Requirement Assessment | Compliance assessment against obligations |
| Third-Party Risk | Due diligence and engagement assessment |
| Security Scanner Ingestion | Promoted from automated vulnerability or configuration scanner telemetry (SFN-) |
Audit engagements, regulatory inspections, incidents and resilience exercises also create canonical findings, which ride the same record and lifecycle as compliance findings. Technical scanner observations (SFN-YYYY-NNNN) operate in a machine lifecycle until human triage promotes them into this register.
Per-source status vocabularies
Statuses are not shared across sources
RCSA "Remediating" and the governed compliance "In remediation" are different states in different engines. They are kept distinct deliberately so a merged filter never implies a state a source does not have.
RCSA / Control Assessment
| Status | Label |
|---|---|
open | Open |
remediating | Remediating |
closed | Closed |
Terminal: closed.
Regulatory / Requirement Assessment, and Third-Party Risk
| Status | Label |
|---|---|
open | Open |
assigned | Assigned |
in_remediation | In remediation |
under_review | Under review |
accepted | Accepted |
closed | Closed |
dismissed | Dismissed |
escalated | Escalated |
candidate | Risk candidate |
Terminal: closed, accepted, dismissed.
A finding is open when it is not in its own source's terminal set. Overdue means past its due date and still open.
The Three Lines model
Findings enforce a Three Lines of Defence separation with hard segregation of duties.
| Line | Permission | Can do | Cannot do |
|---|---|---|---|
| Line 1 | finding.remediate | Comment, attach evidence, remediate, request reassessment | Accept, dismiss or close |
| Line 2 | finding.review | Assign, accept, dismiss, send back, close | Act on a finding they own |
| Line 2 | finding.escalate | Escalate for risk review | Escalate a finding they own |
| Independent | finding.close | Independent closure | — |
The rule "never own finding" appears throughout: a reviewer cannot review a finding assigned to them.
The closure rule
Completing an action does not close a finding
Completing a remediation action plan does not close the finding it serves.
Closure requires independent verification. For findings raised in an audit engagement, closure additionally requires auditor retest validation — the auditor who raised it confirms the remediation actually worked.
This is the single most important behaviour in remediation tracking. Without it, a programme reports closure at the moment someone marks a task done, which is precisely the moment the least independent verification has occurred.
Audit validation states
Findings raised through an audit engagement carry an additional validation state:
| State | Meaning |
|---|---|
pending_validation | Remediation reported; auditor retest outstanding |
validated_closed | Retest passed; the finding is genuinely closed |
reopened_failed_retest | Retest failed; the finding is reopened |
What a finding carries
| Field | Purpose |
|---|---|
| Business reference | FND-YYYY-NNNN |
| Title and description | What is deficient |
| Source | Where it came from |
| Severity | Critical, High, Medium, Low |
| Owner | Who is accountable for remediation |
| Due date | When remediation is expected |
| Status | Per its source vocabulary |
| Linked records | Requirement, control, risk, action plans, evidence, incident, audit engagement, inspection item |
| Timeline | Every state change, comment and attachment |
Scanner findings (SFN) and governed promotion
Enterprises often ingest thousands of vulnerability and configuration alerts from tools like Tenable, Nessus, Nipper, Qualys, and Defender. In OrviQ, these are ingested as Scanner Findings (SFN-YYYY-NNNN), keeping high-volume telemetry decoupled from the governed compliance findings register.
Machine lifecycle vs. governed lifecycle
| Dimension | Scanner Finding (SFN-) | Compliance Finding (FND-) |
|---|---|---|
| Volume | Thousands to tens of thousands | Curated tens to hundreds |
| Origin | Automated scanner API sync or report import | Human audit, RCSA, or promoted SFN |
| Lifecycle | Machine-driven: open, fixed, reopened, risk_accepted, false_positive | Governed: open, assigned, in_remediation, closed (Three Lines SoD) |
| Auto-resolution | Automatically marked fixed when a subsequent full scan verifies absence | Requires independent Line 2 or auditor retest verification to close |
| Deduplication | Natural key: sha256(tenant, connection, asset, external_ref, port, protocol) | Governed business reference FND-YYYY-NNNN |
Severity normalization
Raw scanner metrics (Nessus 0–4, CVSS base scores, VPR, Nipper text ratings) are normalized into five standard tiers:
- Critical (CVSS 9.0–10.0 / Nessus 4 / Critical)
- High (CVSS 7.0–8.9 / Nessus 3 / High)
- Medium (CVSS 4.0–6.9 / Nessus 2 / Medium)
- Low (CVSS 0.1–3.9 / Nessus 1 / Low)
- Informational (CVSS 0.0 / Nessus 0 / Informational)
Governed triage pathways
An authorized analyst can triage an open SFN- finding into formal governance structures:
- Raise as Finding (
FND-YYYY-NNNN): Elevates the technical vulnerability into a formal audit finding with assigned Line 1 remediation ownership, remediation deadlines, and required independent closure. - Promote to Risk (
RSK-YYYY-NNNN): Transfers the deficiency to the Enterprise Risk Register for scoring against risk appetite. - Accept via Exception (
EXC-YYYY-NNNN): Routes the deficiency into the Governed Exceptions register with compensating controls and expiration dates. - Remediate via Action Plan (
ACT-YYYY-NNNN): Links the vulnerability to an operational engineering task. - ITSM Write-back: Creates bi-directional tickets in ServiceNow or Jira.
Semantic Doctrine: Scanner findings and control failure
A scanner finding is a technical observation, not an automatic proof of control failure or compliance violation. Whether a vulnerability breaches a control depends on scope applicability, compensating controls, and indicator evaluation thresholds.
Escalation
A Line 2 reviewer can escalate a finding for risk review. Escalation does not automatically create a risk — the residual risk is promoted to the register by the compliance authority holding risk.promote.
This keeps the register a record of deliberate decisions rather than an automatic mirror of every finding.
Permissions
| Action | Permission |
|---|---|
| View findings and their timeline | finding.read |
| Line 1: comment, attach evidence, remediate, request reassessment | finding.remediate |
| Line 2: assign, accept, dismiss, send back, close | finding.review |
| Line 2: escalate for risk review | finding.escalate |
| Independent closure | finding.close |
| Auditor retest validation | audit.finding_validate |
All require the compliance_core entitlement; audit validation additionally requires audit_management.
Example
Finding FND-2026-0071 — Privileged accounts without MFA.
| Field | Value |
|---|---|
| Source | Regulatory / Requirement Assessment |
| Severity | High |
| Raised by | Continuous assurance indicator failure on IND-2026-0009 |
| Owner | IT Security Operations Manager |
| Due date | 30 days from raise |
| Linked | CTL-2026-0041 MFA Standard, requirement A.8.5, risk RSK-2026-0014 |
Timeline:
| Day | Event | Actor |
|---|---|---|
| 0 | Raised from indicator failure, three accounts identified | Compliance Analyst |
| 1 | Assigned | Compliance Manager (Line 2) |
| 3 | Action plan ACT-2026-0188 created | IT Security Ops (Line 1) |
| 18 | Two accounts remediated; one is a service account requiring vendor change | IT Security Ops |
| 22 | Exception EXC-2026-0031 requested for the service account | IT Security Ops |
| 29 | Exception approved, 90-day validity, compensating control recorded | CRO |
| 31 | Action plan completed | IT Security Ops |
| 34 | Independent verification: indicator confirmed passing for two accounts; third covered by approved exception | Compliance Manager |
| 34 | Closed | Compliance Manager |
Note what closed it: not the action plan completion on day 31, but the independent verification on day 34 — which included checking that the indicator actually passed rather than accepting that the work was reported done.
Troubleshooting
"I cannot close a finding I remediated." Correct. Line 1 remediates; Line 2 closes. Segregation of duties applies.
"The action plan is complete but the finding is still open." That is the closure rule. Independent verification is required.
"An audit finding says validated_closed but reopened." It failed retest. The state will read reopened_failed_retest.
"Filtering by status shows unexpected results." Status vocabularies differ by source. Use the source-aware filter rather than a merged list.
"A finding is overdue but shows as closed." Overdue only applies to open findings. Once terminal, the overdue flag clears.