Security finding data quality and completeness workflow
one defensible record per finding across every required field
Vulnerability programmes accumulate dirty finding data faster than they remediate. Severities arrive blank, categories drift to free text, affected asset fields point at deleted hostnames, owners no longer work at the company, CVSS vectors are missing on findings that have a score, control references are inconsistent across engagements, and duplicate identities sit in the queue under different titles. The audit lookback reads from the same record set, the leadership posture read reads from the same record set, and the SLA calculation reads from the same record set. Run finding-record hygiene as a recurring workflow on the workspace findings view so the data quality of the inventory is a deliberate operating discipline rather than the residue of every ingestion cycle.
No credit card required. Free plan available forever.
Run finding-record hygiene as a recurring workflow rather than a pre-audit scramble
Vulnerability programmes accumulate dirty finding data faster than they remediate. Severities arrive blank from imports, categories drift to free text across engagements, affected asset references point at deleted hostnames, owners no longer work at the company, CVSS vectors are missing on findings that have a score, control references are inconsistent across framework crosswalks, and duplicate identities sit in the queue under different titles. Every downstream view reads against the same record set: the SLA breach calculation, the leadership posture brief, the audit evidence binder, and the executive risk read.
SecPortal models finding-record hygiene as a recurring workflow on the workspace. The engagement record carries the required-field schema. The findings view filters surface cohort detection queries. The activity log captures every field rewrite with previous value, new value, timestamp, user, and cited rationale. Severity and CVSS calibration land as structured state events. Category and control reference normalisation run against the controlled vocabulary. Asset reference repair runs against the live inventory through the verified domain list and the repository connections. Owner refresh runs against active workspace membership through team management. Duplicate collapse runs through the merge and supersede workflow. Closure verification runs through retesting. The hygiene cycle is the operating discipline that keeps the inventory defensible between cycles, not the scramble that runs the week before an audit.
Eleven required fields every defensible finding record carries
Before the hygiene workflow can run, the programme has to declare which fields are required for a finding to count as defensible. The table below names the field, the healthy operating pattern, and the failure mode the schema prevents. The required-field schema lives as a written record on the engagement type so every intake path lands on the same expectation.
| Field | Healthy pattern | Failure mode |
|---|---|---|
| Title | A concise, programme-vocabulary title that names the underlying issue, the affected component, and the consequence rather than copy-pasting the scanner rule label. The title is stable across cycles so the same issue does not appear under three different titles after three ingestion rounds. | The title is whatever the scanner rule emits, mutates between minor scanner updates, and reads as opaque rule identifiers in leadership briefings. The audit lookback shows three different titles for the same issue and the dedup pass cannot match them. |
| Severity | A normalised severity (Critical, High, Medium, Low, Info) populated against the calibration rule that reads the source severity, the asset criticality, and the deployed exposure. The CVSS score and the CVSS vector accompany the severity so the calibration is reproducible from the record. | Severity is blank, set to the scanner default with no calibration, set to an inconsistent label across engagements (P1 here, Critical there, sev1 elsewhere), or carries a score without a vector so nobody can reconstruct how the score was derived. |
| Status | A state from the documented lifecycle: open, in progress, resolved, verified, closed, accepted, false positive, superseded. The state advances through explicit transitions that the activity log captures with timestamp and user attribution. | Status sits at the intake default for months, advances through informal updates in chat that never reach the record, or carries a state the engagement type does not recognise. The audit lookback cannot reconstruct the sequence of operational decisions. |
| Affected asset | A live reference that resolves against the verified domain list, the engagement scope, or the repository connection list. The reference is structured (hostname, URL, repository path, container image, package coordinate) rather than free text so the cross-engagement view can group findings by asset. | The asset field is blank, points at a hostname that no longer exists, refers to a service that has moved to a different host, or carries a free-text description the reporting view cannot group on. The asset-owner routing breaks because the routing key is unreliable. |
| Description | A description that explains the underlying issue in programme vocabulary, names the impact, and references the reproduction or detection evidence. The description is the answer the engineering team reads when the finding lands on their queue. | The description is missing, copies the scanner rule text without context, or includes details that contradict the title and the severity. The engineering team rejects the finding and the security team rewrites the description after the rejection. |
| Remediation | Specific remediation guidance the named owner can act on: configuration change, code change, dependency upgrade, policy refinement, or compensating control. The guidance references the engagement frameworks where applicable so the closure narrative ties back to the audit ask. | Remediation reads as a generic OWASP cheat sheet entry, is missing entirely, or contradicts the affected asset and the description. The named owner asks for clarification and the cycle stalls until the security team responds. |
| Category | A controlled-vocabulary value the programme has agreed on (mapped to CWE or to an internal taxonomy). Category drives the reporting view, the recurring-pattern detection, and the cross-engagement grouping. The vocabulary is documented and the intake validates against it. | Category is free text, drifts across engagements (SSRF, server-side request forgery, SSRF (CWE-918) on the same workspace), or is left blank on findings the scanner did not categorise. The reporting view counts the same category three different ways. |
| Control reference | A canonical control identifier from the framework the engagement maps to (NIST 800-53 SI-2, ISO 27001 Annex A 8.8, SOC 2 CC7.1, PCI DSS 6.2, OWASP ASVS V5). The reference is consistent across crosswalks so the GRC team can assemble evidence without re-mapping. | The control reference is missing on findings that map to a framework, drifts between abbreviated and full notation, or references controls that the engagement framework does not cover. The audit evidence assembly takes longer than the audit window. |
| CVSS score and vector | The numerical score and the full CVSS 3.1 (or 4.0) vector string. The vector carries the base metrics and, where calibrated, the temporal and environmental metrics. The pair is reproducible: anyone reading the record can derive the score from the vector. | The score is present but the vector is missing so the calibration is not reproducible. The vector is present but the score does not match the vector. The CVSS pair is blank on findings the scanner emitted with a score, breaking the prioritisation view. |
| Assigned owner | A named owner from active workspace membership who holds the engagement access required to act on the finding. The owner field is the routing anchor the queue view, the notification schedule, and the SLA breach calculation read against. | The owner field is blank, holds a name that no longer works at the company, or points at a generic mailbox nobody reads. The SLA breach calculation reports against a name that cannot act and the leadership view shows unowned findings as on-track. |
| Resolved and verified timestamps | resolved_at captures the moment the engineering fix lands. verified_at captures the moment the verification source confirms the fix holds. The pair separates the engineering claim from the security verification, and the activity log carries the user and timestamp for each transition. | resolved_at is set while verified_at is null on engagements that require verification. The closed queue contains assertions the audit lookback cannot defend. The retest workflow has nothing to retest because the verification timestamp was never expected. |
Eight cohort detection queries the hygiene queue runs against
The recurring hygiene cycle reads the workspace findings view as a set of cohorts. Each cohort is a filter against the symptoms the required-field schema makes visible. The cohort is the inventory of records the hygiene cycle works against; the open queue is what remains once every cohort resolves.
Blank required field cohort
Open findings where any required field is blank. Severity blank, status blank, affected asset blank, category blank, description blank, remediation blank, assigned owner blank, CVSS score blank. The cohort is the inventory of records the schema rejects. The hygiene cycle starts here because every other repair needs a defensible base.
Score without vector cohort
Findings with a non-null CVSS score and a null CVSS vector. The calibration is not reproducible from the record so the audit lookback cannot verify the prioritisation read. The vector reconstructs from the source documentation or the calibration rule and the activity log carries the reconstruction event.
Free-text category drift cohort
Open findings whose category does not match the controlled vocabulary. The reporting view counts the same category multiple ways and the recurring-pattern detection misses systemic issues because the join key drifts. The cleanup maps each drift value onto the canonical category and the activity log carries the rewrite.
Stale assignment cohort
Open findings assigned to owners who are no longer in the workspace, no longer on the engagement, or no longer in the role required to act. The cohort surfaces against the team management active-membership list. Reassignment runs against the routing rule and the previous owner stays in the activity log for accountability.
Orphan asset cohort
Open findings against assets that do not resolve on the verified domain list, the engagement scope, or the repository connection list. The cohort surfaces against the live asset inventory join. Each finding either gets the live asset reference or gets closed against the asset decommissioning workflow with a cited closure narrative.
Resolved-without-verified cohort
Findings where resolved_at is set, verified_at is null, and the engagement type requires verification. The cohort is the boundary between an engineering assertion and a security confirmation. Each finding either gets a verification source attached through retesting or gets recorded as a closure-without-verification with cited rationale.
Duplicate identity cohort
Open findings whose title, category, control reference, and affected asset match another open finding closely enough that they probably describe the same underlying issue. The cohort feeds the merge and supersede workflow rather than getting closed silently. The merged primary keeps the closure narrative and the duplicates attach as evidence.
Control reference drift cohort
Open findings whose control_ref does not match the canonical framework crosswalk for the engagement. NIST SI-2 versus NIST 800-53 SI-2, SOC 2 CC7.1 versus CC7-1, ISO A.8.8 versus A 8.8. The cleanup collapses each drift onto the canonical reference so the GRC view stops double-counting and the audit evidence assembles without manual reconciliation.
Where finding-record hygiene usually fails
Seven drift patterns account for most vulnerability programmes whose finding inventory looks healthy at the cycle boundary and dirty under audit inspection. Each pattern is silent during the cycle and loud at the next assessment because the data quality erosion only shows up when somebody else has to read the records.
Required fields stay optional in practice
Healthy posture
The intake workflow enforces required fields at create time so nothing reaches the open queue with a blank essential field. Bulk imports map every column and reject the upload when required fields are missing in the source CSV. Manual finding creation surfaces the missing field at the validation step so the security analyst lands it complete rather than promising to come back.
Failure mode
The team treats required fields as a guideline rather than as a schema. Bulk imports leave severity blank because the source export did not include it. Manual creations land with a placeholder description that nobody updates. The hygiene queue grows linearly with the ingestion volume and the leadership view reports a number that overstates the working inventory.
Category vocabulary is implicit and unenforced
Healthy posture
The category vocabulary is a documented list mapped to CWE identifiers, the engagement type lists the active categories, and the intake validates against the list. The reporting view groups against the canonical list so the recurring-pattern detection reads accurate counts.
Failure mode
The category vocabulary lives in a security engineer's memory. Findings arrive with whatever label the source emitted. The reporting view shows SSRF, server-side request forgery, SSRF (CWE-918), and CWE-918 as four separate categories. The leadership read undercounts the systemic risk because the join key drifts.
Asset references are free text instead of structured pointers
Healthy posture
The affected asset references resolve against the verified domain list, the engagement scope, the repository connection list, or a canonical asset identifier (container image digest, package coordinate). The cross-engagement view groups findings by asset because the reference is reliable.
Failure mode
Affected asset values are free text. "api.example.com", "API endpoint at example dot com", and "Production API server" describe the same asset across three findings and the cross-engagement view treats them as three different assets. The asset-owner routing reads from a field the routing key cannot rely on.
Owner staleness is invisible until escalation
Healthy posture
Assigned owners get validated against active workspace membership and against the engagement access list on a recurring cadence. Owners who lose access get flagged for reassignment before the next SLA breach calculation runs. The named owner field is current at every cycle.
Failure mode
Findings stay assigned to whoever picked them up first. The owner leaves the company; the finding stays assigned. The owner moves teams; the finding stays assigned. The SLA breach escalation lands in a mailbox nobody reads. The next leadership read shows the SLA hit rate against names that cannot act.
CVSS pairs are inconsistent and unreconcilable
Healthy posture
Every finding with a CVSS score carries the full vector. The vector includes the base metrics and, where calibrated, the temporal and environmental metrics. The score derives from the vector so anyone reading the record can reproduce it.
Failure mode
CVSS scores live without vectors. The calibration is not reproducible. The audit lookback reads scores without provenance. The leadership briefing cites the score as if it were canonical when the calibration that produced it was a single security engineer's judgment that nobody captured.
Closure narratives substitute for verification
Healthy posture
The closure record carries the verification source (follow-up scan, retest evidence, code change link, configuration audit), the verified_at timestamp, and the named verifier. The audit reads the closure as a defensible record rather than as an assertion.
Failure mode
Findings get marked resolved on the strength of an engineering claim. The closed queue grows without verification evidence. The next assessment asks for proof and the security team reconstructs the evidence after the fact from chat logs, scanner exports, and whatever the engineering team remembers.
Activity log entries are missing the why
Healthy posture
Every field change lands as a structured event on the activity log with the previous value, the new value, the timestamp, the user, and the cited rationale where the change is a calibration, an override, or an exception. The audit lookback reads the rewrite history with attribution.
Failure mode
Field changes happen through bulk edits without recorded rationale. The audit lookback can see that severity changed from High to Medium but cannot reconstruct why. The reviewer treats the record as untrustworthy because the rewrite history is opaque, and the assessor extends the audit to compensate.
Six repair patterns the hygiene cycle runs
Each cohort feeds a repair pattern with a documented operating discipline. The repair lands as a structured field update with the previous value preserved on the activity log so the audit lookback can reconstruct the cleanup history.
Severity and CVSS repair
Findings with blank severity get severity from the calibration rule: source severity recalibrated against asset criticality and deployed exposure. Findings with a score and no vector get the vector reconstructed from the calibration rule and the source documentation. Findings where the score and the vector disagree get the vector preserved (it carries the metric set) and the score recomputed. Each repair lands as a structured state event with cited rationale so the activity log captures the calibration provenance.
Category and control reference normalisation
Free-text category values map onto the controlled vocabulary through a documented rewrite list. Control references drift values map onto the canonical reference. The rewrite runs as a structured field update with the previous value preserved on the activity log so the audit lookback can reconstruct the cleanup history. The reporting view stops double-counting because the join keys are stable.
Asset reference repair against the live inventory
Affected asset references resolve against the verified domain list, the engagement scope, and the repository connection list. References that point at retired assets get closed against the asset decommissioning workflow with cited closure narrative. References that drift on a still-live asset get rewritten to the canonical reference. The hygiene rule is no open finding survives a cycle with an asset reference the live inventory does not recognise.
Owner assignment refresh against active membership
The assigned_to field cross-joins with the active workspace membership and the engagement access list. Findings assigned to inactive owners route to the new named owner through the security finding ownership and routing workflow. The previous owner stays in the activity log for accountability and the routing decision lands as a structured event. The named owner field is current at every cycle so downstream views read against a defensible routing key.
Duplicate collapse and orphan closure
Duplicate identities feed the merge and supersede workflow rather than getting silently closed. The merged primary carries the closure narrative and the duplicates attach as evidence. Orphan findings against deleted assets get closed against the asset decommissioning workflow with a cited closure narrative. The hygiene cycle ends with the open queue containing only findings the audit lookback can defend.
Resolved-without-verified resolution
Findings with resolved_at set and verified_at null on engagements that require verification either route to retesting (preferred path) or get recorded as a closure-without-verification with cited rationale. The closed queue distinguishes verified closures from asserted closures so the audit lookback can read the verification posture against the right denominator.
Recurring cadence for finding-record hygiene
The hygiene workflow runs on a documented cadence rather than as an ad-hoc cleanup. Each cadence row names the cohort the cycle works against and the operating outcome the cycle produces. Skipping a cadence does not break the next cycle; it just lets the drift compound into the next leadership view.
- Weekly: detect cohorts on the workspace findings view and add new entries to the hygiene queue. Sample inspect a randomised set of recent intakes to surface schema drift in the source pipelines.
- Biweekly: run the severity and CVSS repair cohort against the calibration rule, attach activity log entries, and refresh the prioritisation view.
- Monthly: run the category and control reference normalisation against the documented rewrite list, validate the reporting view counts against the canonical taxonomy, and surface taxonomy drift to the programme owner.
- Monthly: refresh assigned owners against active workspace membership, run the SLA breach calculation against the refreshed routing, and surface unowned findings to the programme owner for explicit reassignment.
- Quarterly: scan for orphan asset references against the live verified domain list and the engagement scope, route retired assets through the decommissioning workflow, and refresh the asset inventory ground truth.
- Quarterly: review the duplicate cohort, run the merge and supersede workflow against the highest-confidence matches, and confirm the closure narrative carries cited evidence.
- Per audit cycle: run a full hygiene pass against every required field, attach the activity log export to the audit evidence binder, and document the residual drift the audit reviewer should know about.
How the hygiene workflow looks in SecPortal
The workflow runs on the same feature surfaces the rest of the security programme already uses: the engagement record, the findings view, the activity log, finding overrides, team management, bulk finding import, global search, the verified domain list, and the repository connections. The discipline is binding the recurring hygiene cycle to the same primitives the daily operating view already reads against.
Findings as the structured record
Findings management carries title, severity, status, affected asset, description, remediation, category, control reference, CVSS score, CVSS vector, assigned owner, and timestamps. The required-field schema is a property of the engagement so every intake path lands on the same shape and the hygiene cohorts read against the same fields.
Cohort filters on the findings view
The workspace findings view filters by status group, severity, and substring so each hygiene cohort surfaces as a live working list rather than as a screenshot. Bulk operations apply repair against the filtered cohort, and global search surfaces orphan references and drifted categories across engagements.
Activity log as the audit trail
Activity log captures every field rewrite with the previous value, the new value, the timestamp, the user, and the cited rationale where applicable. The plan-defined retention window and the CSV export carry the cleanup history into the audit evidence binder.
Overrides for calibrations and exceptions
Finding overrides hold severity recalibrations, false-positive suppressions, and risk acceptances with cited reason, named approver, scope, and hard expiry. Calibration rewrites that change severity feed the override surface so the calibration provenance is reproducible.
Owner refresh through team management
Team management with role-based access carries the active workspace membership and the engagement access list. The stale assignment cohort cross-joins findings against active membership so reassignment runs against current ground truth.
Asset reference repair
Domain verification and the repository connections surface the live inventory the orphan asset cohort resolves against. Findings against retired assets route through the asset decommissioning workflow rather than living as orphans.
Bulk import that validates required fields
Bulk finding import maps source columns onto the engagement fields and missing required values surface as import-time validation. Imports with missing required fields land in the hygiene queue rather than corrupting the open queue.
Closure verification through retesting
Retesting workflows close the resolved-without-verified cohort by attaching a verification source. The verified_at timestamp and the named verifier preserve the boundary between an engineering assertion and a security confirmation.
Cadence notifications
Notifications and alerts surface stuck cohorts, approaching SLA breaches on stale assignments, and approaching override expirations so the hygiene cycle runs on a recurring rhythm rather than against the audit calendar.
Six signals the hygiene workflow surfaces by default
When finding-record hygiene runs as a structured workflow on the engagement record, six signals come straight off the record without a manual reporting pass. They drive the daily operating view, the leadership brief, and the audit lookback.
Required-field completeness rate
The proportion of open findings where every required field is non-null. The single most predictive signal of audit defensibility. A working programme stays above the documented threshold (typically 95 percent or higher) on a recurring cadence rather than only before an assessment.
CVSS pair reproducibility rate
The proportion of findings with a non-null score where the vector is also present and the score derives from the vector. The signal that distinguishes a calibrated severity programme from one that reads scores without provenance.
Controlled-vocabulary adherence rate
The proportion of open findings whose category and control reference match the canonical vocabulary and crosswalk. The signal that distinguishes a programme whose reporting reads accurate counts from one whose join keys silently drift.
Assigned-owner currency rate
The proportion of open findings whose assigned_to value resolves against active workspace membership and active engagement access. The signal that distinguishes a programme whose routing is defensible from one whose SLA calculations report against names that cannot act.
Asset reference resolution rate
The proportion of open findings whose affected_asset value resolves against the live inventory (verified domain list, engagement scope, repository connection list). The signal that distinguishes a programme whose cross-engagement view reads against a stable asset ground truth from one whose asset references drift silently.
Closure verification rate
The proportion of closures with both resolved_at and verified_at populated. The signal that distinguishes a programme whose closed queue holds defensible records from one whose closures are engineering assertions the audit cannot verify.
Reviewer checklist before a hygiene cycle closes
Before the programme owner marks a hygiene cycle complete, the checklist below runs in seconds. Each line names a record-level posture the audit reviewer reads against. Missing any one of them is the source of one of the drift patterns above.
- Every open finding has a non-null title, severity, status, affected asset, description, remediation, category, assigned owner, and (where applicable) control reference and CVSS pair.
- Severity is calibrated against the calibration rule and the calibration event lives on the activity log.
- CVSS scores and vectors agree: the score derives from the vector and the vector includes the metrics the calibration uses.
- Categories match the controlled vocabulary and control references match the canonical framework crosswalk.
- Affected asset references resolve against the verified domain list, the engagement scope, or the repository connection list.
- Assigned owners are active in the workspace and hold the engagement access required to act.
- Findings with resolved_at set carry a verified_at value or a cited closure-without-verification rationale.
- Duplicate identities have been routed through the merge and supersede workflow and orphan assets have been closed through the decommissioning workflow.
- The activity log export captures every field rewrite with previous value, new value, timestamp, user, and cited rationale where applicable.
What auditors expect from a defensible finding inventory
Finding-record data quality surfaces in every audit read of vulnerability management. The frameworks below all expect the inventory to show structured records, calibrated severities, named owners, controlled-vocabulary taxonomy, and traceable closure evidence. A documented vulnerability management policy without record-level data quality evidence reads as a process gap.
| Framework | What the audit expects |
|---|---|
| ISO 27001 Annex A 8.8 | Vulnerability management runs against a defined process with structured records, calibrated severities, named owners, and closure evidence. A vulnerability inventory with missing required fields, drifted severities, and stale owners reads as a process gap and the assessor extends the sample size to compensate. |
| SOC 2 CC7.1 and CC7.2 | Vulnerability detection and response evidence shows that findings are detected, named, owned, prioritised, and remediated with documented evidence. Data quality of the finding record is the first thing the assessor inspects because every downstream assertion (SLA hit rate, severity mix, remediation velocity) reads against the record. |
| PCI DSS Requirement 6.3 and 11.3 | Vulnerability management records assets, severities, remediation timelines, and verification evidence for in-scope systems. Findings with blank affected asset references or unverified closures reduce the defensible sample of evidence the assessor accepts. |
| NIST 800-53 RA-5 and SI-2 | Vulnerability scanning and flaw remediation evidence reads as a closed loop: detection, calibration, remediation, verification, and exception handling. The audit reviewer treats finding records with missing fields and drifted categories as evidence of an unsystematic process. |
| NIS2 Article 21 and DORA Article 6 | Technical and organisational measures and ICT risk management framework expect structured vulnerability records with calibrated severities and traceable remediation. Data quality drift in the finding inventory reads as a governance gap at supervisory review. |
| GDPR Article 32 and HIPAA Security Rule | Both regimes expect a documented vulnerability management process supporting the technical safeguards. Finding records with missing or stale fields reduce the defensibility of the safeguards narrative when a breach review or regulator inquiry runs. |
Where the hygiene workflow sits in the wider security programme
Finding-record hygiene composes with the rest of the security programme on the same engagement primitives so the data quality discipline stays connected to the per-finding, per-control, and per-cycle work that runs alongside it.
Upstream and adjacent workflows
The hygiene workflow depends on vulnerability finding intake for the front-door discipline, vulnerability finding state lifecycle for the documented status transitions, security finding ownership and routing for the named-owner refresh, asset ownership mapping for the asset reference resolution, and CVE and EPSS enrichment for the upstream advisory metadata layer.
Downstream programme discipline
Hygiene-disciplined records feed merge and supersede for duplicate collapse, asset decommissioning and finding retirement for orphan closure, vulnerability backlog management for the working queue read, security debt portfolio management for the portfolio view, audit fieldwork evidence request fulfillment for the assessor binder, and security leadership reporting for the recurring leadership read.
Pair the workflow with the supporting research and guides
Finding-record hygiene lives alongside the rest of the vulnerability management programme and leans on the same prioritisation, SLA, and evidence vocabulary. Pair this workflow with the vulnerability management programme guide for the operating-model framing, the security findings deduplication guide for the dedup discipline framing, the vulnerability programme data model research for the record-design framing, the security finding ownership decay research for the assignment drift framing, the open-finding state staleness research for the cost-of-drift framing, and the scanner tag and label taxonomy for the controlled-vocabulary framing on the scanner side.
Buyer and operator pairing
A structured finding-record hygiene workflow is the operating model vulnerability management teams, AppSec teams, GRC and compliance teams, internal security teams, security engineering teams, security program managers, and CISOs rely on when the finding inventory needs to read defensibly to assessors, leadership, and downstream platforms. The framework references that shape the cadence include ISO 27001, SOC 2, PCI DSS, NIST 800-53, and DORA. The supporting tools include the vulnerability remediation worksheet, the vulnerability management programme scorecard, the vulnerability management RACI template, and the vulnerability prioritisation matrix template.
Frequently asked questions
How is this different from the vulnerability finding intake workflow?
Vulnerability finding intake describes how new findings reach the workspace from the various sources: external scanning, authenticated scanning, code scanning, bulk import from third-party scanners, manual creation, and third-party pentest report intake. Intake is the front door. Data quality and completeness is the recurring cycle that runs after intake to repair the records the front door let through. A programme can have an excellent intake discipline and still accumulate stale assignments, drifted categories, orphan asset references, and unverified closures over time because the underlying environment changes faster than the records do. The two workflows compose: intake controls what reaches the queue and the hygiene workflow controls how clean the queue stays once it grows.
How is this different from the merge and supersede workflow?
Merge and supersede is the specific workflow that collapses duplicate identities onto one primary record while preserving the closure narrative and the audit trail. The hygiene workflow uses merge and supersede as one of its cohorts: the duplicate identity cohort feeds the merge workflow rather than getting silently closed. But the hygiene workflow covers much more: required-field completeness, severity normalisation, CVSS pair reconciliation, controlled-vocabulary adherence, asset reference repair, owner refresh, and closure verification posture. Think of merge and supersede as one tool the hygiene cycle uses for the duplicate cohort, and the hygiene workflow as the operating discipline that runs across every required field.
How does SecPortal support the recurring detection of dirty finding records?
The workspace findings view filters by status group, severity, and substring so the hygiene queue cohorts surface as live working lists rather than as screenshots. Bulk operations apply repair against the filtered cohort. The activity log captures every field rewrite with previous value, new value, timestamp, user, and rationale so the cleanup history is reconstructible. Global search across the workspace surfaces orphan references, drifted categories, and recurring duplicates. The recurring cadence (weekly cohort detection, biweekly severity repair, monthly category and owner refresh, quarterly orphan and duplicate review, per-audit-cycle full pass) lives as a documented operating procedure the named programme owner runs against.
Does the platform automatically validate required fields at intake?
Manual finding creation surfaces validation errors when required fields are blank so the security analyst lands the record complete. Bulk finding import maps source CSV columns onto the engagement fields, and missing required values surface as import-time validation rather than as silent gaps. Where the source export does not carry a required field the import discipline is to either add the field to the source export before re-running the import or to land the import into the hygiene queue rather than the open queue. The validation primitive is the engagement type and the required-field schema; the operating discipline is whether the programme accepts unvalidated imports onto the open queue or holds them in the hygiene queue.
How does the workflow handle findings from third-party pentest report intake?
Third-party pentest report findings often arrive with less structured metadata than scanner findings: title strings vary by author, severity labels drift between firms (Critical here, Crit there, Sev 1 elsewhere), category vocabulary mismatches the workspace canonical taxonomy, and control references read against whichever framework the pentest scope used rather than the workspace canonical crosswalk. The hygiene workflow runs against these imports the same way it runs against scanner imports: the cohort detection surfaces the drift, the normalisation step collapses drifted values onto the canonical taxonomy, and the activity log captures the rewrite. The third-party pentest report intake workflow describes the intake side and the hygiene workflow describes the recurring cleanup that runs after intake.
How does the activity log support the audit trail for hygiene actions?
Every field rewrite the hygiene workflow runs lands as a structured event on the activity log with the previous value, the new value, the timestamp, the user, and the cited rationale where applicable. The export covers the plan-defined retention window. Auditors and assessors read the activity log when they inspect the rewrite history behind a calibrated severity, a normalised category, a reassigned owner, or a closure-without-verification rationale. The export is the evidence behind the hygiene cycle and the absence of an entry is the evidence of an unrecorded rewrite the audit treats as a process gap.
How does the workflow connect to compliance evidence assembly?
Compliance evidence assembly reads finding records as the primary input. The audit-fieldwork evidence request fulfillment workflow draws the engagement findings, the named owners, the timestamps, and the closure narrative into the assessor binder. A hygiene-poor inventory makes this assembly slow: the GRC team has to reconcile drifted categories against the framework crosswalk, hunt down owners who no longer hold the role, and reconstruct closure rationale from chat logs. A hygiene-disciplined inventory makes the assembly mechanical: the activity-log export, the cohort filter against the canonical category, and the controlled-vocabulary join produce the binder without re-mapping per audit cycle.
Does SecPortal integrate with external ticketing or GRC platforms to repair finding data?
SecPortal models the finding lifecycle on its own engagement and findings records with the activity log carrying the rewrite history. The platform does not run a built-in connector to Jira, ServiceNow, Slack, Microsoft Teams, SIEM, SOAR, GRC platforms, or other external ticketing systems. The branded client portal, the role-based access on team management, and the engagement-level discussions cover the in-platform communication. Where the engineering team or the GRC team works in an external system, the engagement record remains the durable artefact the hygiene cycle runs against, and the activity log export is the evidence the assessor or the leadership review reads. The scanner-to-ticket handoff governance workflow describes the boundary discipline if findings need to surface to an external system after the hygiene cycle has cleaned them.
How it works in SecPortal
A streamlined workflow from start to finish.
Define the required-field schema every finding record must carry
Before the hygiene workflow can run, the programme has to declare which fields are required for a finding to count as defensible. The minimum set on a typical engagement is title, severity, status, affected asset, description, remediation, category, control reference (where the engagement maps to a framework), CVSS score, CVSS vector, assigned owner, and timestamps for resolved and verified states. The schema lives as a written record on the engagement type so every intake path, every bulk import, and every manual creation lands on the same expectation. Findings that arrive without a required field enter the hygiene queue rather than the open queue.
Detect missing or malformed values across the workspace findings view
The recurring hygiene cycle scans the workspace findings view for the symptoms the schema makes visible. Open findings with blank severity, blank status, blank affected asset, blank category, blank assigned owner, blank CVSS vector when the score is non-null, free-text category values that do not match the controlled vocabulary, control references that do not match any active framework crosswalk, and findings where resolved_at is set but verified_at is null where the engagement requires verification. The status group filter, the severity filter, and the substring filter on the findings view surface each cohort so the hygiene queue is a working list rather than a screenshot.
Repair missing severity and CVSS metadata against the calibration rule
Open findings with missing severity get the severity from the calibration rule: the source severity from the scanner or pentest, recalibrated against the asset criticality and the deployed exposure where the underlying issue applies. Where the score is present but the vector is missing the vector gets reconstructed from the score band against the calibration rule and the source documentation. Where the score and the vector disagree the vector wins because it carries the metric set and the score gets recomputed. Each repair lands as a structured state event on the finding so the audit lookback reads the calibrated severity with provenance rather than as an opaque rewrite.
Normalise category and control reference against the controlled vocabulary
Free-text category values that drift across engagements (SSRF appears as SSRF, server-side request forgery, server side request forgery, and SSRF (CWE-918) on the same workspace) collapse onto the controlled-vocabulary value. Control references that drift across framework crosswalks (NIST 800-53 SI-2, NIST SI-2, SI-2) collapse onto the canonical reference. The cleanup lands on the finding record as an explicit field update with the previous value captured in the activity log so the audit trail preserves the rewrite history and the reporting view stops counting the same category three times.
Repair affected asset references against the live asset inventory
Open findings with affected_asset values that point at deleted hostnames, decommissioned subdomains, hostnames not on the verified domain list, or services that have moved to a different host get repaired against the live inventory. Where the asset has been retired the finding gets a closure narrative tied to the asset decommissioning workflow rather than left as an orphan. Where the asset still exists under a different reference the finding gets the live reference and the activity log carries the rewrite. The hygiene rule is that no open finding survives a cycle with an asset reference the verified domain list does not recognise.
Refresh owner assignment against active workspace membership
Open findings assigned to owners who no longer hold the role (left the company, moved to a different team, lost the engagement access) get reassigned against the team management surface. The hygiene query runs the assigned_to field against the active workspace membership and the engagement access list. Stale assignments collapse onto the new named owner with the previous owner captured in the activity log. Findings without an owner enter the unassigned queue with a hard escalation cadence rather than aging silently. The named owner field is the routing anchor every other workflow reads against so owner staleness corrupts every downstream view until the refresh runs.
Collapse duplicate identities and orphan records into a defensible closure narrative
Findings that match the same underlying issue across sources get collapsed through the merge and supersede workflow rather than left as silent duplicates. Findings against assets that no longer exist get closed against the asset decommissioning workflow with a cited closure narrative rather than left as orphans. Findings that were superseded by a corrected re-ingestion get marked superseded with the new identity referenced. The hygiene cycle ends with the open queue containing only findings the audit lookback can defend, and the closed queue carrying the cited narrative for every closure.
Features that power this workflow
Vulnerability management software that tracks every finding
Orchestrate every security engagement from start to finish
Every action recorded across the workspace
Collaborate across your entire team
Finding overrides that survive every scan cycle
Bulk finding import bring your scanner data with you
Global search across every engagement, finding, and client
Compliance tracking without a full GRC platform
Verify ownership before any scan runs
Verify fixes and track reopens on the same finding record
Notifications and alerts for the people who carry the work
Finding comments and collaboration on the same record as the work
AI-powered reports in seconds, not days
Run finding-record hygiene on one engagement record
Required-field schema, missing-value detection, severity and CVSS repair, controlled-vocabulary normalisation, asset and owner refresh, duplicate collapse, and audit-trail evidence. Start free.
No credit card required. Free plan available forever.