Security testing program management
one record across every engagement, vendor, and asset

The list of assets the programme is committed to test, grouped by type (web applications, external infrastructure, internal infrastructure, cloud accounts, mobile apps, code repositories, OT/ICS zones). Each asset carries the test type, cadence, last tested date, and the next scheduled engagement. Coverage gaps appear on the dashboard rather than on an audit finding two months later.

Every pentest, scan window, code review, and retest opens as an engagement linked to the parent programme. Engagements can be delivered by an internal team, a primary vendor, or a panel of vendors run on rotation. The programme is vendor-agnostic; what matters is that each piece of work is on the same record.

Findings persist across engagements, vendors, and reporting cycles. A finding raised in a Q1 web app pentest is still tracked when the same asset is retested in Q3 by a different vendor, with the same identifier and the same remediation owner. The catalogue is the durable artefact; the report is a snapshot of it.

Each finding carries its remediation owner, target SLA, retest history, and verification status. Closed findings stay on the record with the close-out evidence. Aging findings flag at the SLA threshold. The retest ledger is the proof that the programme delivers fixes rather than just identifies issues.

The quarterly or annual programme report pulls from the live record: engagements delivered, coverage achieved, findings opened and closed, retests completed, SLA performance, and the aging picture. AI-assisted reporting drafts the executive summary against real delivery so the board update is evidence rather than narrative.

Single-engagement project management runs one pentest from scoping to delivery. It owns the scope document, the team assignment, the kickoff meeting, the daily check-ins, the report, and the retest. Programme management runs above it: it coordinates many engagements over months and years, and it carries the cross-engagement signal (aging findings, repeat issues, coverage gaps) that no single engagement can see.

Retainer management is a commercial parent layer for one client relationship: the contracted block of hours or test count, the drawdown ledger, the billing cadence, and the renewal terms. Programme management is the operational parent layer: it spans multiple clients (for a vendor), multiple vendors (for a buyer), and asset groups that may sit outside any single retainer. A programme can include retainers, but it is broader than them.

Continuous testing is an always-on technical pattern: scheduled scans, live findings, retests paired to originals, and reports generated on demand. Programme management is the planning and oversight layer above it. A programme often includes both continuous testing for fast-moving assets and discrete scheduled engagements for the rest of the estate.

A vulnerability management programme typically begins after an engagement closes and the findings have been handed over. Programme management starts earlier: at the planning of which engagements run when, which assets they cover, and which vendors deliver them. The two are complementary; the testing programme produces the catalogue that the vulnerability management programme then runs against.

Each vendor delivers reports through its own portal or as a standalone PDF. The buyer has no consolidated view; the next coverage decision is made from a folder of files rather than from a dashboard. When the auditor asks for the programme view, the team spends a week stitching it together by hand.

A finding raised in a Q1 pentest is closed-out at delivery. When the same vendor or a different vendor retests in Q3 and finds the same issue, it lands as a brand-new finding with a new identifier. Repeat issues are invisible because the catalogue does not span engagements; the same critical finding gets reported, fixed, and reintroduced over and over.

The annual testing plan was approved at the start of the year as a deck. Six months in, nobody knows which assets have actually been tested, which are scheduled, and which slipped. The coverage gap is discovered at the next compliance audit when an asset that should have been tested twice in the year was not tested at all.

Each engagement reports its own SLA performance in its closing slide. The aggregate SLA picture across the programme is never assembled because no record carries it. Aging risk debt accumulates silently, the board update reports per-engagement satisfaction, and the actual mean-time-to-remediate trend is never visible.

The decision to renew, replace, or expand a vendor is made on partner-level relationships and the most recent engagement memory rather than on data. There is no record of how many findings each vendor produced, how many were valid, what the false positive rate was, or how their SLA performance compared. The next procurement runs on vibes.

The programme parents pentest project management for each child engagement, plus continuous penetration testing for always-on coverage and retesting for verification.

The programme aggregates remediation tracking and pentest evidence management so the audit-ready picture is current rather than reconstructed.

The programme record is the testing evidence package for ISO 27001, SOC 2, and PCI DSS cycles, alongside compliance audits workflow.

For vendor-side delivery, the programme can be funded by a pentest retainer; the retainer is the commercial relationship and the programme is the operational picture above it. When a buyer runs more than one approved vendor, the supplier-side governance lives on the parallel pentest vendor panel record so the programme decides what gets tested and the panel decides who tests it.

Internal security functions that own the annual testing plan use the programme record to plan engagements, track delivery, and report up to leadership. The programme spans whatever delivery model the team uses: internal pentesters, external vendors on rotation, or a mix of both.

Fractional and virtual CISOs running the testing programme for a portfolio of client organisations use one programme record per client. Each client gets its own coverage map, engagement portfolio, findings catalogue, and board view, while the vCISO sees the aggregate workload across all clients in a single account.

MSSPs running security testing as part of a managed services umbrella use the programme record to deliver oversight to the client and coordination to the delivery team. The branded portal carries the programme view to the client; the internal record carries the operational view to the MSSP.

Teams responsible for SOC 2, ISO 27001, PCI DSS, or sectoral assurance use the programme record as the testing evidence package. Coverage, findings, retests, and SLA performance are produced from the live record for each audit cycle without the team rebuilding the picture from individual reports.

Coverage, findings, retests, SLA performance, and aging are all on one programme dashboard. The quarterly review is reading the dashboard rather than rebuilding it from individual reports the week before the meeting.

The board update cites engagements delivered, coverage achieved, mean time to remediate, aging open findings, and SLA performance directly from the record. The number on the slide is the same number on the dashboard.

The auditor asks for the testing evidence package for the period and the programme owner exports it from the record. The activity log carries the audit trail and the findings catalogue carries the cross-engagement history.

The decision to renew, replace, or expand a vendor runs from the programme record: findings produced, valid rate, false positive rate, and SLA performance per vendor over the period. The next procurement is grounded in delivery rather than in partner relationships.