Vulnerability finding data export and warehouse ingest
run as a documented pipeline so the enterprise data warehouse, BI dashboards, and leadership reads stay current with the operational record

A point-in-time snapshot of the open finding population pulled from findings management with the canonical columns the warehouse analyst expects: finding identifier, title, CVSS 3.1 vector, severity at intake, severity now, named owner, engagement reference, client or business unit, asset binding, source pipeline (external scan, authenticated scan, code scan, manual entry, bulk import), open date, last activity date, last severity change date, and exception state. The snapshot ships as CSV from the findings view or as an AI report table export so the warehouse loader can ingest it without bespoke API code. Each snapshot row carries the workspace identifier and the snapshot timestamp so the warehouse fact table preserves the as-of view and the analyst can reconstruct any prior open backlog state.

A delta export of findings that closed during the reporting cycle, suitable for remediation throughput dashboards and SLA attainment fact tables. Each row carries the finding identifier, the open date, the close date, the elapsed days, the severity at close, the named remediator, the engagement reference, the asset binding, the retest reference where applicable, and the source pipeline. The delta export is the foundation of the mean-time-to-remediate fact table, the SLA attainment percentage by severity band, and the cycle-over-cycle remediation throughput trend the leadership dashboard reads against.

The active exceptions surface as a separate fact class because risk-accepted findings need separate analytical treatment from open or remediated findings. Each row carries the cited finding identifier, the override class, the business rationale summary, the compensating control reference, the named approver, the residual risk band, the expiry date, the framework citation, and the cycle the exception was last re-attested. The export feeds the warehouse exception fact table the GRC dashboard and the board risk briefing read against without re-querying the operational workspace.

A CSV export of the activity log narrowed to the cycle window, the entity classes the warehouse cares about (findings, engagements, clients, documents, team), and the actions analytically relevant (state changes, owner assignments, severity edits, override decisions, document uploads, role grants). Each row carries the actor identifier, the entity type, the entity identifier, the action, the metadata payload, and the timestamp. The activity slice feeds the warehouse event fact table the security analytics engineer joins against the finding dimension to compute lifecycle latency, ownership rework, override frequency, and reassignment churn.

The AI report chat surfaces structured tables (severity distribution, remediation throughput, exception register, control coverage attestation) that download as CSV or Excel directly from the report view. The tables are pre-shaped for downstream consumption: the severity distribution table is the source for the leadership dashboard severity ring, the remediation throughput table is the source for the rolling four-cycle trend chart, the exception register table is the source for the GRC exception backlog tile, and the control coverage attestation table is the source for the audit-committee control attainment slide. The warehouse loader can ingest each table without reshaping because the AI report already aligned the rows to the question the dashboard answers.

Dimension exports anchor the warehouse star schema so the fact tables can be joined to engagement metadata (name, type, start date, close date, status), client or business unit metadata (name, tier, contract reference), and asset metadata (target, target type, verified domain, last scanned date). The dimension exports are usually monthly or quarterly because the dimensions change slowly. They give the warehouse analyst the join keys to roll severity attainment to the business unit, mean-time-to-remediate to the engagement type, and exception load to the asset tier.

The CISO asks the analytics team for the open critical backlog, the analyst pulls a quarter-old snapshot from the warehouse, the operational workspace has moved on, and the leadership read disagrees with the working dashboard. The fix is a cadenced export on a documented cycle (typically weekly for snapshots, daily for the activity log slice, per-cycle for the dimension exports) so the warehouse currency is explicit and the analyst can name how old any number is.

The first export ships with twelve columns, the second with thirteen because a new field surfaced in the operational workspace, and the warehouse loader fails on the schema change without a rollback. The fix is treating the export column set as a contract: pick the columns the warehouse cares about, document them on the export job, and review the contract before any column change ships. The AI report table export is more stable than an ad-hoc CSV pull because the table shape is anchored to the report prompt.

A single monolithic dump of the finding population gives the dashboard the current state but the warehouse cannot reconstruct the trajectory because every prior snapshot has been overwritten. The fix is shipping the snapshot with the snapshot timestamp as a column and loading each snapshot as an immutable fact row so the warehouse preserves the as-of view. Pair it with the activity log slice so the event grain captures the transitions between snapshots.

The dashboard shows open and closed counts but the exception register is in a parallel spreadsheet maintained by the GRC lead. The board reads a chart that hides one hundred and twenty risk-accepted findings the exception register knows about. The fix is exporting the exception register as its own fact class on the same cadence as the snapshot so the dashboard query can union or filter open versus accepted findings explicitly.

The warehouse holds the open and close timestamps but cannot compute time-in-triage, time-in-remediation, or time-in-retest because the intermediate state transitions never reached it. The fix is exporting the activity log slice narrowed to the analytically relevant actions so the warehouse can reconstruct the lifecycle from the event fact table joined to the finding dimension. The plan-bound activity log retention determines how far back the warehouse can backfill from the operational workspace.

The CSV is pulled manually by one named GRC analyst, the file lands in a personal cloud drive, the warehouse loader reads from the personal drive, and the pipeline fails the week the analyst goes on leave. The fix is running the export against a named service account with documented role-based access, a documented landing zone the warehouse loader reads from, and an activity-log entry that records the pull on the operational workspace so the chain is reconstructable.

The dimension export is monthly but the snapshot is weekly, an engagement closes mid-month, the snapshot omits it, the warehouse loader writes findings against a missing engagement key, and the dashboard surfaces orphaned rows. The fix is shipping the dimension exports as a soft-deleted view (engagement record retained with closed status) rather than a hard filter so the warehouse star schema preserves referential integrity across cycles.

The finding description carries the raw exploit payload, the asset binding carries an internal hostname, and the activity log slice carries the named actor of a sensitive override decision. The warehouse environment has broader read access than the operational workspace, the data lands there, and the access review the next cycle flags the leak. The fix is treating the export classes as data-classified artefacts: scope the columns the warehouse needs, redact or hash columns the warehouse does not need, and capture the data-classification decision on the export job alongside the schedule.

NIST CSF 2.0 (Govern and Identify functions, specifically GV.OV oversight and ID.RA risk assessment) explicitly expects the entity to maintain awareness of the current cybersecurity risk posture and to communicate the posture to senior management and the board. A warehouse-side fact table that reads off cadenced exports from the operational record is the analytical surface the GV.OV oversight reads against. The CSF 2.0 Govern function explicitly contemplates that the organization roles, responsibilities, and authorities are defined; the named service account, documented landing zone, and activity-log entry on the export job make the oversight defensible.

CA-7 (continuous monitoring) expects a strategy that includes metrics to be monitored, frequencies of monitoring, ongoing security control assessments, ongoing status monitoring of organization-defined metrics, correlation and analysis of security-related information generated by assessments and monitoring, and reporting. The warehouse fact tables back the metric trend; the operational workspace remains the source of truth for any individual finding. The split is the procedure CA-7 reads against.

CC4.1 (selects, develops, and performs ongoing and separate evaluations) explicitly contemplates the entity using monitoring activities including management monitoring outputs, internal audit testing, and other independent assessments. The warehouse-side dashboard is one such monitoring activity; the documented cadence, schema contract, and data-classification rules make the monitoring activity testable.

Clause 9.1 (monitoring, measurement, analysis, and evaluation) requires the entity to determine what needs to be monitored and measured, when, by whom, and how the results are analysed and evaluated. The export job specification (the export class, the cadence, the named owner, the warehouse landing zone) is the documented monitoring procedure Clause 9.1 reads against. Annex A 8.16 (monitoring activities) reinforces the requirement; the activity-log entry on the export job captures the operating evidence.

Requirement 10 (log and monitor all access to system components) and Requirement 12.4 (executive management oversight of the information security programme) anchor both the activity log slice the export ships and the oversight read off the warehouse. The export pipeline is one of the systems within the cardholder data environment that itself needs the activity-log capture; the operational workspace records the export pull as a workspace event so the chain is preserved.

Safeguard 8.10 (retain audit logs across enterprise assets for a minimum of 90 days) and Safeguard 17.4 (establish and maintain an incident response process) read the activity log retention and the warehouse-side analytics. The plan-bound activity log retention (30, 90, or 365 days depending on workspace plan) sizes how far the warehouse can backfill without a separate archival store; the warehouse-side fact table preserves the longer-horizon trend the operational workspace does not retain on the lower retention tiers.

Builds and runs the export jobs, the warehouse loaders, the dimension model, and the data classification rules. Reads the schema contract queue, the pipeline incident queue, and the backfill queue. Pairs with the GRC liaison to scope sensitive columns and with the security operations leader to time the snapshot ahead of leadership reads.

Joins the finding fact table to the activity log event fact and the engagement dimension to compute lifecycle latency, ownership rework, override frequency, severity recalibration, and the warehouse-side analytical questions the operational workspace alone cannot answer. Reads the snapshot cadence and the activity log retention to size what is computable.

Reads the warehouse-side throughput dashboard, the cycle-over-cycle SLA attainment chart, and the asset-class concentration chart. The dashboard query roll-up matches the operational workspace because the snapshot and the activity log slice ship from the same record the operational view reads.

Reads the warehouse-side exception backlog tile, the framework crosswalk attainment, and the audit-committee evidence pack. The exception register export is the source of truth the GRC dashboard reads because the operational workspace exception decisions land directly on the export.

Reads the board-level cyber risk briefing, the leadership dashboard, and the audit-committee deck off the warehouse fact tables. The leadership read regenerates from the same export classes the security data engineering team runs on cadence so the operational workspace and the boardroom dashboard tell one story.

Reads scoped access on the operational workspace for sample retesting during fieldwork (covered on the audit fieldwork evidence request fulfillment workflow), then reads the warehouse-side trend tables for the multi-cycle assertions the audit working paper expects. The warehouse trend tables back the assertions; the workspace live record is the source of truth for any sampled finding.

Read the leadership dashboard and the board risk briefing off the warehouse, set the cadence the snapshot ships on, and read the cycle close summary alongside the trend tables. The CISO persona page and the security operations leaders persona page cover the leadership read.

Own the operational record the snapshot reads against and read the warehouse-side throughput dashboard against the same backlog the workspace shows. The vulnerability management persona page and the AppSec persona page cover the operating side.

Join the warehouse finding fact to the activity log event fact to compute lifecycle latency, ownership rework, and override frequency the operational workspace alone does not surface. The security data analysts persona page and the detection engineering teams persona page cover the analytical read.

Read the warehouse-side exception backlog tile, the framework crosswalk attainment, and the audit-committee evidence pack against the same operational record. The GRC and compliance teams persona page covers the evidence read alongside the warehouse trend tables.