Vulnerability management program onboarding
stand up the programme as a workspace record from charter to signed-off baseline

A named scope for the programme: which asset classes are in scope, which classes are excluded with rationale, which compliance framework set the programme reads against, which regulator regimes the programme answers to, which named executive sponsor accepts the programme outcome, and which named programme owner runs the operating cadence. The charter is the artefact the audit chain reads against scope completeness before scanning begins; without a charter the programme drifts into a tooling exercise that produces no audit-defensible record.

A structured asset inventory the programme will operate against. Each in-scope asset class carries the named technical owner, the named accountable owner, the named cadence (daily, weekly, biweekly, monthly), the named criticality band (mission-critical, high, standard, low), the named regulator scope (PCI cardholder data environment, HIPAA ePHI surface, GDPR personal data surface, DORA ICT surface, NIS2 essential or important entity surface), and the named compliance framework citation per asset class. The map is the planning surface and the first audit-evidence row.

A documented intake source register that names the verified intake channels: external scanning across the sixteen modules, authenticated scanning behind verified domains with stored credentials, code scanning against connected repositories, and bulk finding import from any third-party scanner output (Nessus, Burp Suite, CSV, Semgrep output). Each source carries the named credential lifecycle, the named scan-target validation gate, the named authentication mode, and the named first controlled test against a low-criticality target before the broader baseline runs.

A named programme-wide baseline scan window the assessor reads against scope coverage in cycle one. The window opens with the agreed scheduling cadence per asset class, returns the first finding cohort onto the findings record with CVSS 3.1 severity and template binding, and is signed off as a versioned snapshot rather than a moving target. The baseline names the start state the operating cadence reads progress against; subsequent cycles read the change-event stream against the baseline rather than reconstructing it.

A documented per-severity SLA policy the programme commits to (critical, high, medium, low; per-asset-class differential where the criticality band warrants it) and the named SLA clock convention (clock starts at finding-created timestamp, pauses only with named exception, never resets on rescan). The SLA policy is published on the workspace as a document, attached to the programme engagement record, and referenced from the leadership read cadence so the operating discipline reads against the published policy rather than against folklore.

A documented exception register operating model that runs the finding overrides feature as the live record. Each override carries the eight named fields: type (severity override, accepted risk, compensating control, deferral, false positive), named approver, named scope, named expiry, named rationale, named review cadence, named compensating control reference, and named renewal trigger. The register is ratified before the baseline runs so conditional-acceptance entries land on a queryable record rather than on a wiki page that nobody owns.

A documented RACI matrix that names the programme owner (workspace owner role), the triage lead, the remediation owners per asset class, the retest engineer, the governance and compliance partner, and the leadership read recipient. The named roles back the named-owner field on findings, the named-approver field on overrides, and the named-actor activity-log entries on engagement records. MFA via TOTP is enforced across the workspace boundary so the named-actor chain on every record carries authentication assurance.

A documented leadership read cadence (weekly operational, monthly leadership, quarterly audit committee or board read) paired with AI-generated reports drafted from the live workspace record: executive summary, technical narrative, remediation roadmap, exception register sweep, retest closure narrative, framework evidence read. The first leadership briefing composes from the baseline scan window, the SLA cohort sweep, the exception register snapshot, and the first cycle of retests so the leadership read is evidence rather than narrative from day one.

A structured audit-evidence pack the first ISO 27001, SOC 2, PCI DSS, NIST 800-53, NIST CSF 2.0, HIPAA, NIS2, DORA, FedRAMP, or HITRUST assessment reads against. The pack names the programme charter, the asset estate map, the verified intake source register, the baseline scan window, the SLA policy, the exception register, the RACI, the leadership read cadence, and the per-framework citation grid. The pack is assembled from the live engagement record rather than reconstructed at fieldwork.

A documented sign-off event closes the onboarding engagement and hands the programme over to the steady-state operating record. The programme owner signs the baseline, the executive sponsor counter-signs the audit-evidence pack, the GRC partner attaches the framework citation grid, and the operating cadence reads from the named handover point forward. From sign-off, the programme is consumed by the wider operating-workflow set (security testing programme management, backlog management, debt portfolio management, leadership reporting) rather than by the onboarding engagement.

A new programme owner kicks off with a slide deck and a tracking spreadsheet, the first scan runs against an unverified asset list, and twelve months later the first ISO 27001 or SOC 2 assessor reads the discipline as immature because there is no chartered record. The fix is opening the programme as a chartered engagement on the workspace with the named sponsor, scope, framework set, regulator regimes, named programme owner, and named outcome on day zero so the discipline carries an artefact rather than a narrative.

The onboarding produces an asset spreadsheet with 200 rows, four people edit it once, and twelve months later half the assets are stale, fifteen production systems are missing, and the assessor reads the scope completeness gap as a control weakness. The fix is the asset estate map on the workspace with the named technical owner, named accountable owner, named cadence, named criticality, named regulator scope, and the verified domain register or repository connection as the durable identity anchor rather than a free-text spreadsheet column.

The baseline scan runs against authenticated targets but the credential mode was never validated against a low-criticality test, half the targets fall back to unauthenticated scope, and the baseline cohort represents perimeter findings rather than authenticated coverage. The fix is the named scanner authentication validation step against a low-criticality target before the broader baseline runs, the encrypted credential vault scoped to the verified domain, the named rotation cadence, and the named scan-target validation gate so the baseline cohort represents the intended scope.

The SLA policy is published as "high severity inside 30 days, critical inside 7 days" but the clock convention is never named (does the clock start at finding-created, at finding-triaged, at finding-assigned, or at scan-execution?). The first quarter ends with the same finding triaged as on-time on one team and breached on another. The fix is the named SLA clock convention published with the policy: clock starts at finding-created timestamp, pauses only with named exception, never resets on rescan; the convention reads the same way on every team because it lives on the workspace record.

Accepted-risk and compensating-control decisions land on a wiki page that nobody owns, the renewal cadence is never named, three months later an overrides sweep finds twenty-eight entries past expiry that the operating cadence still treats as live, and the audit chain reads the exception programme as silent acceptance. The fix is the exception register as the finding overrides feature on the workspace with the eight-field decision chain, the named approver, the named expiry, the named renewal cadence, and the named review trigger so the register is queryable and the renewal cadence is auditable.

The kickoff names a few owners on a slide, the named-owner field on the first 500 findings stays blank, three months later the operating cadence reads against an unowned queue, and the assessor reads the role-clarity gap as a process weakness. The fix is the RACI captured against the team management RBAC on the workspace, the named-owner field populated against the live workspace roles, and the named-approver field on overrides backed by the same role-management surface so the role assignment is named on the record rather than in the kickoff deck.

The first executive briefing happens at month three, the slide deck recaps the kickoff plan rather than the live record, the board reads narrative about intent rather than evidence about delivery, and the second-cycle assessment reads the leadership oversight gap as immature governance. The fix is the leadership read cadence configured at onboarding (weekly operational, monthly leadership, quarterly audit committee), the AI-generated programme report pack drafted from the live workspace record from cycle one, and the first board pack composing evidence from the baseline scan window, the SLA cohort sweep, and the first retest cycle so the leadership read carries data rather than narrative from the first delivery.

The first ISO 27001 or SOC 2 assessor opens the file twelve months in, the programme owner spends three weeks reconstructing the audit-evidence pack from email, Slack, and spreadsheets, and the per-framework citation grid arrives at fieldwork as a folder of PDFs without named author or named approver attribution. The fix is the audit-evidence pack on the workspace from the first cycle, the per-framework citation grid attached to the programme engagement record, and the named-author and named-approver chain captured at capture so the pack is queryable rather than rebuilt at fieldwork.

The onboarding engagement closes at month three with a "we are now live" Slack message, the operating workflows (backlog management, debt portfolio management, leadership reporting) inherit an unsigned baseline and an unratified exception register, and the first operating cycle exposes the same scope gaps onboarding was supposed to resolve. The fix is the documented handover event with the programme-owner sign-off, the executive-sponsor counter-signature, the GRC framework-citation attachment, and the named handover point from which the operating workflows consume the record forward.

The onboarding drifts past month three, six, nine; the baseline is repeatedly "almost ready"; twelve months in the first audit assessor reads the programme as never having completed cycle one. The fix is the named baseline sign-off date in the charter (typically 60 to 90 days from charter), the documented gates per onboarding phase (charter, asset map, intake, baseline, SLA, exceptions, RACI, leadership read, sign-off), and the audit-evidence pack assembled at sign-off so cycle one starts from a signed point rather than a perpetually-pending baseline.

The named role accountable for the programme outcome, the budget envelope, the regulator-facing narrative, and the audit committee or board read. Signs the programme charter at open, signs the audit-evidence pack at baseline sign-off, and chairs the recurring leadership read on the cadence the audit committee chair governs. The sponsor sits inside the security leadership and reads the programme record against the wider operating model rather than against a recap deck.

The named role accountable for running the onboarding engagement. Opens the chartered record on the workspace, holds the asset estate map, validates the intake source register, runs the baseline scan window, publishes the SLA policy, ratifies the exception register, assigns the RACI, configures the leadership read cadence, and signs the baseline at sign-off. The programme owner sits inside the vulnerability management or AppSec leadership and holds the workspace owner role on the engagement.

The named roles that operate the triage queue and the remediation cycle inside the programme. Each asset class carries a named remediation owner (web application, external infrastructure, internal infrastructure, cloud account, code repository, container image, SaaS surface, mobile application, API estate, third-party asset, OT or ICS zone). The triage lead reads the queue against the published SLA policy; the remediation owners hold the per-asset-class remediation cycle against the SLA clock and the retest workflow.

The named role that closes the loop on remediation. Reads the retest queue against the resolved-but-not-verified findings, runs the retest paired to the original finding, captures the proof-of-fix evidence, and moves the finding to the verified state on the workspace. The retest engineer sits inside the security engineering or AppSec function and reads the retest record against the SLA clock so closure carries verified evidence rather than self-attestation.

The named GRC role that reads the audit-evidence pack against the framework set the programme reads against. Attaches the per-framework citation grid (ISO 27001 Annex A 5.7 and A.8.8, SOC 2 CC7.1 and CC7.2, PCI DSS 6.3.1 and 11.3, NIST SP 800-53 RA-5 and SI-2, NIST CSF 2.0 ID.RA and DE.CM, NIS2 Article 21, DORA Article 8 and 13, HIPAA 164.308, FedRAMP, HITRUST) at baseline sign-off, runs the recurring audit-fieldwork evidence-request fulfilment cycle, and reads the exception register against the regulator-facing posture.

The named engineering and product leaders that own the systems the programme tests. Read the baseline scan window against their services, inherit remediation ownership through the named-owner field, hold the retest workflow for their service, and read the per-cycle leadership briefing against their delivery commitments. Named representation per affected service means the operating queue never carries unowned items and the named-owner chain reads consistently.

The named architectural and platform roles that read the programme baseline against the wider security architecture. Hold the control-improvement queue items that ship from the programme (authentication mode changes, scanner coverage expansion, control library updates, framework crosswalk refinement), read the recurring failure-mode catalogue against the architectural posture, and own the platform-side runbook revisions the programme produces.

The named audit-committee and board recipients of the consolidated leadership read. Read the programme charter at open, read the baseline sign-off at cycle one, read the recurring leadership briefing pack on the named cadence, and read the audit-evidence pack at audit-cycle close. AI-generated reports compose the audit-committee narrative from the live workspace record so the governance read never disagrees with the operating chronology.

The chartered engagement record is open on the workspace with the named executive sponsor signature, the named programme owner, the named in-scope asset classes, the named exclusion scope with rationale, the named compliance framework set, the named regulator regimes, and the named first-cycle outcome. Without Gate 1 closure the onboarding has no audit-defensible artefact; without it the audit chain reads the launch as informal.

The asset estate map is named on the workspace, each in-scope domain is verified through the domain verification register, each in-scope repository is connected through OAuth, each asset class carries the named technical owner and the named accountable owner, the criticality bands are named, the regulator scope is named, and the framework citation grid is attached. Gate 2 closure produces the first audit-evidence row the assessor reads against scope completeness.

The intake source register is named on the workspace: external scanning across the sixteen modules verified, authenticated scanning credentials stored in the encrypted credential vault with named rotation cadence, code scanning connected to the repository OAuth, bulk finding import templates validated against the existing third-party scanner output, and one controlled first scan run against a low-criticality target to validate authentication mode and target-validation chain. Gate 3 closure means the intake chain is ready for the baseline window.

The baseline scan window has executed against the verified asset estate, the first finding cohort has landed on the workspace findings record with CVSS 3.1 severity and template binding, the per-engagement attribution pairs each finding to its originating scan execution, and the baseline is named as a versioned snapshot. Gate 4 closure produces the start state the operating cadence reads progress against.

The per-severity SLA policy is published as a document on the workspace, attached to the programme engagement record, and the named SLA clock convention is documented. The exception register operating model is ratified against the finding overrides feature with the eight-field decision chain, the named approver field, the named expiry field, the named renewal trigger, and the named review cadence. Gate 5 closure means conditional acceptance lands on a queryable record from this point forward.

The RACI matrix is captured against the team management RBAC on the workspace (owner, admin, member, viewer, billing). MFA via TOTP is enforced across the workspace boundary. The named-owner field on findings, the named-approver field on overrides, and the named-actor activity-log entries on engagement records all read against the role assignment captured here. Gate 6 closure means the role chain is auditable.

The recurring leadership read cadence is configured (weekly operational, monthly leadership, quarterly audit committee or board read). AI-generated reports compose the first executive summary, the technical narrative, the remediation roadmap, the exception register sweep, the retest closure narrative, and the framework evidence read from the live workspace record. Gate 7 closure means the leadership read carries evidence from cycle one.

The programme owner signs the baseline against the engagement record, the executive sponsor counter-signs the audit-evidence pack, the GRC partner attaches the per-framework citation grid, and the named handover point is recorded on the activity log with named timestamp and named actors. From Gate 8 the operating cadence reads the record forward; the onboarding engagement closes and the steady-state workflows take over.

Reads against the chartered programme record, the documented threat intelligence inputs, the asset estate map, the verified intake source register, the SLA policy, and the exception register. The Clause 6.1.3 risk treatment plan reads against the programme charter; the Clause 9.3 management review reads against the leadership read cadence.

Reads against the intake source register, the baseline scan window, the per-cycle scheduled cadence, the change-event detection chain, the SLA clock convention, and the exception register. The TSP CC criterion wants named monitoring and named response, not narrative; the audit-evidence pack on the workspace carries the named-actor entries the assessor verifies.

Reads against the named cardholder data environment scope, the quarterly external and internal scan cadence, the named-ASV record where applicable, the SLA policy per severity, the exception register conditional-acceptance entries, and the remediation closure evidence with retest pairing. The assessor reads the programme charter for scope, the intake register for scan source, and the baseline plus operating cycles for delivery evidence.

Reads against the asset estate map for the named system boundary, the intake source register for the named tools, the baseline scan window for the named frequency, the SLA policy for the named response time, the exception register for the named risk decisions, and the retest workflow for the named verification. The RA-5(2) enhancement reads against the update cadence; the SI-2(2) enhancement reads against the automated remediation status tracking.

ID.RA reads against the asset estate map, the criticality bands, the framework citation grid, and the programme charter scope statement. DE.CM reads against the verified intake source register, the per-cycle scheduled cadence, the continuous monitoring schedules, and the change-event detection chain on the workspace.

Reads against the cybersecurity risk management policy, the asset estate map and named regulator scope, the vulnerability handling discipline, the incident-handling integration, the supplier-risk handling integration, the SLA policy, the exception register, and the recurring leadership read on the named cadence the competent authority expects.

Article 8 reads against the programme charter, the named ICT risk management framework, the asset estate map and ICT-asset register, the SLA policy, and the named protective measures. Article 13 reads against the recurring leadership read, the lessons captured against the operating cadence, and the maturity progression evidence the workspace record carries cycle over cycle.

Reads against the risk analysis evidence the programme charter carries, the ongoing evaluation evidence the leadership read cadence carries, the named ePHI scope on the asset estate map, the per-cycle scan evidence, and the documented exception register entries with named expiry and renewal cadence.

Both audit chains read against the chartered programme, the documented asset boundary, the verified intake source register, the baseline scan window, the SLA policy, the exception register, the retest closure evidence, and the recurring leadership read. The audit-evidence pack on the workspace carries the named citations rather than reconstructing them at fieldwork.

Reads against the chartered programme, the asset estate map, the verified intake source register, the baseline scan window, the per-cycle scheduled cadence (Safeguard 7.5 and 7.6), the SLA policy (Safeguard 7.7), the exception register, the retest workflow, and the documented review of the discipline (Safeguard 7.1).