Vulnerability Programme Data Model: Finding Record Design

Why the data model is the leverage point

Vulnerability programme leadership reviews dashboards, but the dashboard is a derivative of the underlying record. Every number on the leadership view (open finding count, severity distribution, mean time to remediate, SLA compliance rate, audit citation density) reads against the structured record on the operating store. If the record does not carry the field, the dashboard cannot show it; if the field is mutable when it should be immutable, the historical view is unreliable; if the relationship is implicit rather than explicit, the audit citation has to make assumptions. Programmes that improve reporting without improving the record are reorganising a view of unchanged data.^1,3,23

The same logic applies to every operational discipline downstream of capture. Triage cadence reads the severity band and the CVSS vector. Ownership routing reads the asset binding. SLA cadence reads the immutable created-at timestamp and the status transition events. Audit citation reads the named accountability and the chain of activity events. Remediation throughput reads the state lifecycle and the resolved-at timestamp. Reopen rate reads the prior-state field and the verified-at timestamp. Every discipline is downstream of the record schema, which means improving any discipline requires the record to carry the field the discipline reads.

Designing the record well at the start is structurally easier than retrofitting fields after the operating model has accumulated historical data under the wrong schema. The retrofitting path requires backfilling missing fields, reconciling mutable history, and rewriting reporting; the deliberate-design path requires the programme to think through the eight design decisions covered in this research before the first finding lands on the record. The cost of deliberate design is a one-time exercise; the cost of retrofitting is a recurring tax on every change for the life of the programme.

The seven field classes a finding record carries

A defensible finding record carries seven field classes. Each class supports a downstream operational discipline; skipping a class loses the discipline that class supports. The table below names the field class, the fields that belong to it, and the downstream discipline that reads it.^1,2,3,8

The pattern across the seven classes is that each field exists to support a named operational discipline. Programmes that adopt a record with five classes (skipping accountability and provenance most commonly) end up reading those disciplines from comments, informal notes, or external systems that diverge from the workspace record. The deliberate-design exercise is to confirm each class is captured and to resist the urge to add bespoke fields the programme does not yet have a discipline for. The record carries the fields the disciplines actually read; bespoke fields without a discipline accumulate as schema debt.

Three finding identifier strategies

The finding identifier strategy is the decision the programme makes about what makes two captures the same finding versus two different findings. Three patterns recur across enterprise programmes, each with a different operational character.^2,15,25

The choice is consequential because it propagates to every downstream report. A programme that runs per-capture and a programme that runs per-instance can produce very different open-finding counts for the same underlying portfolio, and comparing the two programmes side by side requires normalising the metric to the unique-issue dimension. The deduplication economics research covers the operational cost of running the deduplication discipline downstream of a per-capture strategy; the per-instance strategy collapses much of that cost into the record schema itself.

Asset binding patterns

The asset binding is the field that ties the finding to the operational system or component the engineering team owns. The binding determines whether the ownership routing primitive resolves to a named candidate deterministically or has to fall back to a manual triage queue. Three patterns recur, each with a different operational character.^3,11,22,24

The structured foreign-key pattern is the cleanest model for an internally-operated programme. It keeps the binding inside the workspace, the resolution discipline runs deterministically, and the audit citation reads from a single record. Programmes that mix patterns (some findings on free-text, some on foreign-key) lose the structural advantage and have to write the resolution logic at every reporting query. The mixed-pattern programme usually accumulates as the programme grows from a single scanner to a multi-tool stack without revisiting the binding schema; the remediation is the discipline of resolving free-text bindings to structured asset references on cadence, and the recurring-detection logic against the same target tuple keeps the resolution stable.

For multi-scanner programmes the binding discipline interacts with the cross-scanner identifier reconciliation discipline covered in the scanner output normalised asset resolution guide; the binding pattern is the workspace-internal schema decision and the normalised-resolution discipline is the layer above that reconciles divergent scanner identifiers to the same internal binding. The two layers operate together; neither substitutes for the other.

The structured state enumeration

The state enumeration is the structured set of values the finding status field can hold and the rules that govern transitions between them. A minimal enumeration is four states. A compliance-control programme extends the set to cover control assessment outcomes alongside the vulnerability remediation chain.^1,3,4,5,6

The transition rules name which states can move to which (open to in_progress to resolved to verified is the canonical chain; reopened can move back to in_progress; resolved cannot skip directly to verified without retest evidence). The transition reason field captures why each move happened (auto-resolved by scan diff against the override record, manually advanced by named user, retest passed, retest failed, exception accepted) so the chain reads as a defensible cadence on the activity log rather than as an inferred timeline. Programmes that operate without a structured enumeration end up with strings that mean different things in different places (resolved versus closed versus fixed versus done) and the dashboard has to map across the variants at every query.

The structured state enumeration also defines the SLA boundary. The handoff segment covered in the security engineering handoff latency research sits between open and in_progress. The triage segment sits between in_progress and resolved. The verification segment sits between resolved and verified. The reopen rate measures the transition from verified back to reopened. Each segment is measurable only because the state enumeration carries the structured boundary; programmes that bundle states into an open and closed flag lose all of the per-segment signal.

Override and exception schema

Overrides and exceptions are structured decisions the programme records against the finding rather than free-text annotations on the description. The three override classes carry different audit weight and should remain distinguishable on the record.^{1,4,5,6,13,18}

The override record is keyed to the (workspace, finding, target) tuple so that recurring detection logic on the next scan can match the override and carry the disposition forward without re-triage. Programmes that collapse the three classes into a single suppression flag lose the ability to distinguish noise reduction (false positive) from accepted risk (which carries an audit citation) from severity calibration (which preserves the rationale). The three classes pair with the structured override workflow covered on the finding overrides feature page and with the programme-side workflow on the vulnerability acceptance and exception management workflow.

Activity log discipline

The activity log is the chronological record of every state transition, ownership change, severity change, override decision, comment, and document attachment that touches the finding. The log is separate from the finding entity itself because the finding holds the current state while the log holds the chain of how the state arrived. The log is append-only; once written, the entry does not change.^1,3,4,5,19

The audit query and the reporting query both read against the log rather than against the current state of the finding. The current state shows where the finding sits today; the log shows how it got there, when each transition happened, who initiated each transition, and what context was attached. Programmes that store activity in a mutable field on the finding (a notes column updated in place) lose the chronology and have to reconstruct it from version-control history of the column. Programmes that store activity in an append-only log can regenerate any historical view of the finding at any moment and the audit citation reads against the chain rather than against the current snapshot.

The log discipline also supports the latency-decomposition metrics. Handoff latency reads against the difference between finding_created and the first owner_assigned event for a named user. Triage latency reads against the difference between owner_assigned and the status_changed-to-in_progress event. Verification latency reads against the difference between status_changed-to-resolved and the retest_passed event. None of these metrics are computable without the structured log.

Multi-source ingest patterns

Enterprise programmes ingest findings from many sources: native scanners on the platform (external scans, authenticated scans, code scans), third-party scanner output (Nessus, Burp, Qualys, Acunetix, Snyk, OWASP ZAP), manual penetration test results, third-party security report intake, customer-reported issues, bug bounty disclosure, internal red team findings, supplier advisories. The data model has to absorb every source into the same record schema without losing the source-specific context.^2,7,11,12,21

The bulk import workflow that operates the column mapping is one of the highest-leverage capabilities in a multi-source programme because it determines whether a Nessus finding and a Burp finding for the same underlying vulnerability collapse to one record or sit as two unresolved duplicates. The bulk finding import feature covers the operational surface; the data-model decision is whether the workspace treats third-party output as first-class findings on the same schema or as second-class attachments on a separate import log.

CVSS vector capture and severity rationale

Severity carries three pieces of information on a defensible record: the severity band (the enumeration the programme operates against), the CVSS score (the numerical rating), and the CVSS vector (the structured rationale). The vector is the audit-grade artefact because it names the eight base metrics and supports the optional temporal and environmental modifiers. Without the vector, the score is a number with no rationale; with the vector, the score reads as the consequence of named operational assumptions that the workspace can challenge during triage.^8,9,10,13

Programmes that record only the band lose the rationale; programmes that record the band and the score lose the operational context; programmes that record band, score, and vector retain the full chain and can re-derive the band when the environmental modifier changes. The severity override discipline operates against this chain: the override preserves the original vector and the original band, names the new band, and records the rationale, so the audit citation can read both. Where the programme adopts a successor scoring system (CVSS 4.0 for new findings while retaining CVSS 3.1 for legacy findings), the vector field carries both versions through the transition and the score field reads as the appropriate version per finding.

Evidence and document relationships

Evidence on a finding is the artefact that proves the finding exists, the artefact that supports the severity rationale, the artefact that captures the reproduction steps, the artefact that documents the fix, and the artefact that supports the retest result. The data model holds evidence as a relationship to a document entity rather than as an embedded blob on the finding. Evidence accumulates over the finding lifecycle and embedding it on the finding entity makes the record unbounded in size.^1,4,5,15

The document entity carries the workspace reference, the engagement reference, the file path, the file size, the mime type, the uploaded-by reference, and the created-at timestamp; the relationship to the finding is through a finding identifier on the document or through a join table that supports many-to-many evidence sharing. The pattern keeps the finding entity light, supports the audit query that reads against named evidence by class, and preserves the chronological order of evidence accumulation. Programmes that embed evidence as free-text in the description lose the structural advantage and have to parse the description to identify evidence by class at audit time.

For multi-audit programmes, the document-evidence pattern also supports the evidence-reuse discipline covered in the vulnerability evidence reuse across audits research; a structured document store lets the same scan output, retest log, or remediation evidence cite across SOC 2, ISO 27001, PCI DSS, and NIST audits without re-collection. The data-model decision is whether the workspace treats the document store as first-class infrastructure paired to findings or as a separate artefact pool referenced loosely through descriptions.

How frameworks read the record discipline

Audit frameworks do not name the data model directly. They do read the underlying disciplines that produce a defensible record: named accountability, timestamped state transitions, ranked severity, structured evidence, defined remediation cadence, and response management with assigned roles. The citations below name the relevant control surfaces.^3,4,5,6,7,16

Across the framework set, the audit reads against a chain of timestamped events with named accountability, structured severity, and documented evidence rather than against a single cycle-time number or an unstructured note. Programmes that design the record to carry the seven field classes produce stronger audit citations because the timeline reads as a defensible cadence with structured rationale rather than as a series of inferences. The audit evidence retention and disposal workflow covers the related discipline of how the chain of events is preserved for the audit lookback.

Eight design decisions for a defensible record

The instrumentation discipline below is the minimum required for a programme to operate the vulnerability record as a defensible audit-grade artefact. Programmes that miss any decision either cannot run the discipline at all or have to reconstruct it through manual spreadsheet effort at audit week.

• Choose the identifier strategy deliberately. Per-capture, per-instance, or per-issue; the choice propagates to every downstream metric. Most enterprise programmes converge on per-instance because it preserves the operational granularity of the asset binding while collapsing cross-scan noise.
• Adopt the structured asset binding pattern. Foreign key to a versioned workspace asset record; resist the free-text pattern even when the scanner output makes it tempting at intake. The structured binding is what makes the routing primitive resolve deterministically.
• Define the state enumeration before the first finding lands. The minimal four-state chain plus reopened covers vulnerability remediation; the parallel control-state set covers compliance findings. Transition reasons are captured on the activity log.
• Capture severity as band, score, and vector. The three together preserve the rationale, support the override discipline, and let the workspace re-derive the band when the environmental modifier changes.
• Treat overrides as three distinct classes. False positive, accepted risk, and severity override carry different audit weight. The override record is keyed to the (workspace, finding, target) tuple so recurring detection carries the disposition forward without re-triage.
• Operate an append-only activity log. Every state transition, ownership change, severity change, override decision, comment, and document attachment lands on the log with the actor reference, action verb, structured metadata, and immutable created-at timestamp. The log is the audit artefact.
• Hold evidence as relationships to a document store. The document entity is separate from the finding entity; the relationship supports many-to-many evidence sharing across findings and audits.
• Capture the source field on every finding. Multi-source ingest decomposes by source for reporting and deduplication; the column-mapping discipline at intake is reusable across imports of the same source.

How the engagement record carries the data model

The data model gets cleaner when the finding, the asset binding, the named owner, the override record, and the activity log live on the same engagement record the rest of the operational work lives on, rather than across a separate ticketing system that diverges from the security operating record after the next state change. The platform does not write the programme policy for the team; it does make the eight design decisions above operable from a single workspace.

SecPortal pairs every finding to a versioned engagement record through findings management. The findings table carries the workspace identifier, the engagement identifier, the title, the severity (a five-value enumeration: critical, high, medium, low, info), the status (a fifteen-value enumeration covering open through verified plus the parallel compliance-control state set), the description, the affected asset, the remediation guidance, the category, the control reference, the CVSS score, the CVSS vector, the resolved-at timestamp, the verified-at timestamp, and the immutable created-at timestamp. The schema implements the seven field classes described above.

The finding overrides feature holds the structured three-class override decision (false_positive, accepted_risk, severity_override) keyed to the (workspace, finding, target) tuple, preserves the original severity, names the override creator, and captures the reason and timestamps; the record survives every scan cycle so recurring detection inherits the disposition without re-triage.

The activity log with CSV export carries the append-only chronology of every state change, ownership reassignment, severity change, override decision, and document attachment by named actor with structured metadata; the log is what the audit query reads against rather than the current state of the finding alone. Team management with role-based access (owner, admin, member, viewer, billing) supplies the named owner reference and the actor identity store the log resolves against.

The asset binding uses structured foreign-key references for native scanners: verified domain identifiers for external scans and authenticated scans; connected repository identifiers for code scans. Third-party scanner output lands on the same schema through bulk finding import with reusable column mapping that preserves the deterministic ingest pattern across repeat imports from the same source. Document management supplies the structured evidence relationship paired to the finding. Engagement management groups findings, assets, evidence, and activity to a versioned engagement record so the per-engagement view of the data model reads consistently across reporting periods.

Honest scope. SecPortal does not synchronise the finding record to Jira, ServiceNow, Linear, Azure DevOps, or any external ticketing system; the operating record lives in the workspace and the data model is the workspace schema. The platform does not ship a built-in semantic similarity engine that automatically merges per-capture findings into per-issue identifiers; the workspace operates per-instance through the (workspace, finding template, target) tuple. The platform does not enforce engineering-side SLAs through external messaging integrations; the SLA discipline is the workspace policy paired with the activity log and the named-owner reference. The platform does not ship a built-in CMDB or asset inventory beyond the structured asset references for native scanners; programmes needing a wider asset registry land the resolved canonical reference into the affected_asset field at import time.

For internal security teams, the operating commitment is that the data model is opinionated, the seven field classes are captured by default, and the schema supports every downstream discipline (triage, ownership routing, SLA reporting, audit citation, evidence reuse). For vulnerability management teams, the value is that the per-instance identifier strategy, structured state enumeration, and append-only activity log decompose the remediation cycle into measurable segments without external integration. For AppSec teams and security engineering teams, the structured asset binding through verified domains and connected repositories means the routing primitive resolves deterministically. For GRC and compliance teams, the activity log carries the audit-grade chain of events with named accountability and structured severity rationale across SOC 2, ISO 27001, PCI DSS, NIST SP 800-53, NIST CSF 2.0, CIS Controls, and DORA citations. For CISOs and security operations leaders, the operating record is one schema across the programme rather than a federation of tool-specific records that diverge over time.

Conclusion

The vulnerability programme data model is the leverage point because every downstream discipline (triage, ownership routing, SLA cadence, audit citation, evidence reuse, leadership reporting) reads against the underlying record schema. Improving the dashboard without improving the record reorganises a view of unchanged data; improving the record automatically improves every downstream view. The deliberate-design exercise covers seven field classes (identity, description, severity, classification, status, accountability, provenance), three identifier strategies (per-capture, per-instance, per-issue), three asset-binding patterns (free-text, foreign key, external registry), a structured state enumeration with transition reasons, a three-class override schema, an append-only activity log, multi-source ingest with reusable column mapping, CVSS vector capture with band and score, and document-relationship evidence storage.^1,3,8,15

Programmes that design the record well at the start carry a defensible operating model into every audit, every leadership review, and every policy change. Programmes that adopt whatever schema the first tool brought in inherit the constraints of that tool and run the programme against assumptions they did not choose. The data-model decision is one of the cheapest decisions to get right at the start and one of the most expensive to retrofit later. The platform you use does not have to write the data model for you. It does have to support the seven field classes, the eight design decisions, and the append-only activity log discipline on the same operating record the rest of the programme runs on.

Frequently Asked Questions

Sources

1. NIST, SP 800-53 Revision 5: Security and Privacy Controls (RA-5 Vulnerability Monitoring and Scanning; SI-2 Flaw Remediation)
2. NIST, SP 800-40 Revision 4: Guide to Enterprise Patch Management Planning
3. NIST, Cybersecurity Framework (CSF) 2.0 with GV.RR Governance Roles and Responsibilities, ID.RA Risk Assessment, and RS.MA Response Management
4. ISO/IEC, ISO 27001:2022 Annex A.8.8 Technical Vulnerabilities, A.5.4 Management Responsibilities, A.5.7 Threat Intelligence
5. AICPA, SOC 2 Trust Services Criteria with CC4.1 Monitoring of Controls, CC7.1 System Operations Monitoring, CC9.1 Risk Mitigation
6. PCI Security Standards Council, PCI DSS v4.0 Requirements 6.3.1 Vulnerability Identification, 6.3.3 Vulnerability Rankings and Remediation, 11.3 External and Internal Vulnerability Scanning
7. CIS, Critical Security Controls v8.1 Safeguard 7 Continuous Vulnerability Management
8. FIRST, Common Vulnerability Scoring System (CVSS) v3.1 Specification
9. FIRST, Common Vulnerability Scoring System (CVSS) v4.0 Specification
10. FIRST, Exploit Prediction Scoring System (EPSS)
11. MITRE, Common Weakness Enumeration (CWE)
12. MITRE, Common Vulnerabilities and Exposures (CVE)
13. CISA, Stakeholder-Specific Vulnerability Categorization (SSVC) Decision Trees
14. CISA, Known Exploited Vulnerabilities (KEV) Catalog and Binding Operational Directive 22-01
15. OWASP, Software Assurance Maturity Model (SAMM) Issue Management practice
16. European Union, Digital Operational Resilience Act (DORA) Article 9 ICT Risk Management Framework
17. SecPortal, Findings Management
18. SecPortal, Finding Overrides
19. SecPortal, Activity Log
20. SecPortal, Engagement Management
21. SecPortal, Bulk Finding Import
22. SecPortal Research, Security Engineering Handoff Latency
23. SecPortal Research, Vulnerability Remediation Throughput
24. SecPortal Research, Security Finding Ownership Decay
25. SecPortal Research, Security Finding Deduplication Economics