Use Case

Vulnerability remediation campaign management
one engagement from cohort scope to verified closure

Sometimes the queue needs more than steady-state remediation. A regulatory mandate names a fix deadline. A risk-register review surfaces a class of findings that has aged out. A new control owner inherits a backlog that needs draining before the next audit. Engineering wins a window for a library upgrade that touches dozens of services. The right answer is a time-boxed remediation campaign: a defined cohort of findings, named owners across teams, parallel work streams, a daily cadence, mid-campaign re-prioritisation, and a verification pass that turns campaign closure into evidence rather than assertion. Run the campaign as a structured engagement on the workspace so the cohort scope, the owner assignment, the work-stream status, the verification scans, and the post-campaign report all land on the same record.

No credit card required. Free plan available forever.

Run a remediation campaign on one engagement record from cohort scope to verified closure

Steady-state remediation works against a moving queue: new findings ingest, owners triage, closures drain, the cycle repeats. Sometimes a defined cohort needs more than the steady cadence. A regulator publishes a deadline. The risk register surfaces a class of findings that has aged past the programme tolerance. Engineering wins a window to retire a deprecated library across services. The last leadership review committed the programme to a specific outcome. A post-incident review names a category of fixes that has to land before the next audit. The right answer is a time-boxed remediation campaign: a defined cohort, a named accountable owner, parallel work streams across teams, a daily cadence on the live record, a deliberate response to mid-campaign scope and capacity changes, and a verification pass that turns closure into evidence.

SecPortal models the campaign as a structured engagement on the workspace. The intake opens against the trigger with the deadline, the named accountable owner, and the executive sponsor. The cohort scope captures which findings are in the campaign and which are out. The baseline snapshot fixes the starting position so the burn-down reads against a reference rather than against a moving denominator. Work streams stand up with named owners across teams. The daily cadence reads the engagement record live. Verification scans turn each closure into evidence. AI-assisted reporting draws the post-campaign report from the structured engagement data. The activity log carries the audit trail.

Six campaign triggers a structured engagement opens against

Campaign-mode remediation is not the steady-state queue. The intake captures the trigger source as a structured field so the programme reports on demand patterns, sets source-specific cadences, and budgets the campaign load against the channels that actually produce campaigns.

Regulatory remediation deadline

A regulatory window closes against a class of findings: a PCI DSS quarterly external scan failure, a DORA ICT-third-party remediation deadline, a CISA BOD KEV catalogue due date, an NIS2 incident-related fix requirement, an HHS HIPAA Security Rule corrective action. The campaign opens against the published deadline with the regulator reference and the cohort filter the deadline applies to. The campaign cadence reads against the regulator clock rather than against the steady-state SLA.

Risk-register decision to drain an aging cohort

The risk register surfaces a class of findings that has aged beyond the programme tolerance: open mediums past one hundred eighty days against a specific application, criticals beyond the SLA window in a regulated environment, a long tail of low findings against an asset class the next audit will sample. The risk owner names the deliberate decision to drain the cohort inside a defined window. The campaign is the operational answer to the risk-register action.

Library, framework, or platform upgrade across services

Engineering wins a window to retire a deprecated library, upgrade a major framework version, replace a vulnerable transitive dependency at the lockfile, or migrate off a deprecated TLS cipher across many services. The campaign coordinates the security side of the upgrade: findings against the old version close as the upgrade lands, dependent findings the upgrade unblocks land on the engagement, the verification scan confirms the new version is in production.

Programme commitment from a leadership review

The last security review committed the programme to a specific outcome: reduce open criticals by a defined count, close every finding against a specific application before a target date, complete the remediation pass on a newly acquired business unit before integration cutover. The campaign is the operational artefact behind the leadership commitment, with the engagement record carrying the named accountable owner, the executive sponsor, and the target outcome.

Post-incident remediation programme

An incident post-mortem identifies systemic remediation work: a class of misconfiguration that contributed to the incident, a category of finding the detection missed, a control gap the incident exposed. The remediation programme runs as a campaign rather than as line items on the standing backlog so the post-incident commitments to leadership, the audit, and the affected customers close on evidence rather than on assertion.

New asset or business unit onboarding pass

A new application, a newly acquired business unit, a freshly integrated cloud account, or a recently brought-in third-party platform needs a remediation pass before it joins the steady-state cadence. The onboarding campaign closes the discovered findings to a defined floor before the asset folds into the regular workflow, so the new asset does not inherit a silent open backlog from day one.

Six cohort filters that bound the campaign scope

The cohort scope is the campaign boundary. The filter is recorded on the engagement so it can re-run at any point during the campaign to confirm new ingest that matches the cohort and to evaluate the closing position against the same definition that opened the campaign.

By CVE identifier or template

Filter findings by CVE identifier (every open finding linked to CVE-YYYY-NNNNN), by upstream library and version range, by finding template reference, or by tag. CVE-driven cohorts are typical for emergency campaigns triggered by an upstream advisory; template-driven cohorts are typical for OWASP cleanup campaigns and for SAST-rule rollout campaigns.

By severity band and aging bucket

Filter findings by severity (critical, high, medium, low) and by days-since-clock-start aging bucket (under thirty, thirty to ninety, ninety to one hundred eighty, beyond one hundred eighty). Severity-and-aging cohorts are typical for risk-register drain campaigns and for pre-audit cleanup campaigns where the audit sample is biased toward the long tail.

By affected asset class or business unit

Filter findings by the affected asset reference: a specific application, a defined business unit, a cloud account, a connected repository, a deployment environment, an asset criticality band. Asset-scoped cohorts are typical for onboarding campaigns, for M&A integration campaigns, and for application-specific remediation passes the application owner has committed to.

By named owner or team

Filter findings by the assigned named owner or by the owning team. Owner-scoped cohorts are typical for org-restructure handovers (the outgoing team drains its open queue before the handover) and for capacity-windowed campaigns (a single team commits to a one-week fix push on its own backlog).

By control reference or compliance framework mapping

Filter findings by the mapped control reference: ISO 27001 Annex A.8.8, SOC 2 CC7.1, PCI DSS 6.3, NIST 800-53 RA-5, NIST CSF DE.CM, CIS Control 7. Control-scoped cohorts are typical for compliance-driven campaigns where the cohort is the set of open findings against the controls the next audit will sample.

By fix path

Filter findings by the planned fix path: library upgrade, configuration change, code patch, infrastructure-as-code change, asset retirement. Fix-path cohorts are typical when one upgrade unblocks many findings at once, when one configuration template rollout closes a class of misconfiguration findings, or when one decommissioning closes the open findings against a sunset asset.

Four work-stream patterns the campaign uses to keep parallel teams unblocked

A campaign that runs one queue against many teams creates a contention point. Splitting the cohort into named work streams gives each owner a clean slice of the work while the campaign owner reads the rollup across streams. The right split depends on the campaign trigger.

Per-team work streams

Group findings by the assigned named owner team so each team sees its own slice of the cohort. Per-team streams are typical for cross-team campaigns where engineering, platform, infrastructure, and security each carry a sub-cohort. The team lead reads its own queue without the noise of every other stream, the campaign owner reads the rollup across streams, and the activity log captures both views.

Per-asset work streams

Group findings by the affected asset so each application owner sees the cohort against the system they run. Per-asset streams are typical for onboarding campaigns, for M&A integration campaigns, and for application-specific drain passes. The asset owner does not have to filter the platform queue against an asset reference on every check-in.

Per-fix-path work streams

Group findings by the planned fix path so the work that closes together stays together. Per-fix-path streams are typical for library-upgrade campaigns (every finding the upgrade closes sits on the same stream), for IaC template rollouts (every misconfiguration the template fixes sits on the same stream), and for decommissioning campaigns (every finding the retirement closes sits on the same stream).

Per-priority-band work streams

Group findings by the prioritisation layer the campaign is biased toward: KEV-listed criticals on one stream, internet-facing highs on another, regulated-asset findings on a third. Per-priority streams are typical for emergency-mode campaigns where the campaign owner has a hard ordering preference and wants each band of work treated as a distinct stream.

Where remediation campaigns usually go wrong

Six failure modes account for most campaigns that finish with the team feeling busy and the auditor feeling unconvinced. Each one is silent during the campaign and loud at the post-mortem.

No baseline snapshot, so the campaign cannot prove what it drained

A campaign that starts work without snapshotting the starting cohort cannot tell whether closures actually drained the cohort or whether new ingest masked the drain. The starting baseline is the campaign reference; without it, the post-campaign report says nothing audit-defensible about the outcome, and the next cycle has no comparison point.

Cohort scope drifts silently as new findings ingest

New findings that match the cohort filter land during the campaign window. Without a structured scope-change decision, the campaign quietly grows beyond what was committed, the team owns more than it scoped, the deadline becomes unrealistic, and the post-mortem cannot tell whether the slip came from execution or from undisclosed scope drift. Scope additions need to be deliberate decisions, not silent inheritance.

Daily progress lives in a chat channel and dies when the campaign closes

A campaign run on chat-channel standups produces no record after the channel archives. Six months later the auditor asks how the cohort closed and the team reconstructs the timeline from memory. The engagement record is the durable artefact; chat-channel updates feed the engagement record, not the other way around.

Closures are declared without verification scans

Findings marked resolved without a verification scan, retest, or follow-up scan are assertions, not evidence. Some of them will be regressions on the next steady-state scan cycle and the campaign report carries claims it cannot defend. Every closure on a campaign engagement attaches to a verification source so closure is evidence.

Mid-campaign capacity loss is absorbed silently

A team that loses capacity mid-campaign quietly slows. The campaign owner does not see the capacity gap until the burn-down trend turns flat. Capacity adjustments need to be structured decisions on the engagement so the deadline, the cohort scope, or the exception coverage adjusts deliberately rather than slipping by accident.

Campaign closes without a post-mortem, so the next one starts blind

A campaign that closes without a post-mortem cannot transfer what worked into the next one: which fix paths drained on plan, which work streams stalled, which verification surfaces caught regressions, which scope filters produced the cleanest cohort. The post-campaign retrospective is part of the campaign deliverable, not optional.

How the campaign workflow looks in SecPortal

A remediation campaign is one workflow stitched into the same feature surfaces the rest of the vulnerability lifecycle runs on. The campaign engagement looks structurally similar to a steady-state engagement; the difference is the time-boxed scope, the named cohort, and the verification-gated closure.

Structured campaign intake

The intake opens a campaign engagement under engagement management. The trigger reference, the deadline, the named accountable owner, the executive sponsor, and the cohort filter land as structured fields rather than as a slide title.

Cohort scope and baseline snapshot

Apply the cohort filter through findings management and global search to scope the cohort and snapshot the baseline count, severity distribution, and ownership gaps.

Bulk import of in-scope findings

Where the cohort includes findings exported from another platform, the bulk finding import workflow lands them on the campaign engagement with the cohort tags and the source artefact reference.

Cross-team work streams

Stand up parallel work streams through team management with role-based access. Application owners, platform owners, infrastructure owners, and security watchers join at the right access level.

Verification at every closure

Each closure attaches a verification source through retesting workflows, a follow-up code scan, or an authenticated scan. Closure carries the verification timestamp, not just the resolved status.

Cadence notifications and audit trail

Notifications and alerts surface stuck findings to the named owner. The activity log retains the timestamped state changes with CSV export for evidence binders.

Leadership briefing and customer publication

Draft the executive summary and the customer-facing artefact with AI report generation against the structured engagement evidence. Publish through the branded client portal on the tenant subdomain.

Compliance evidence the audit reads

Compliance tracking maps the campaign closures to control references (ISO 27001 Annex A.8.8, SOC 2 CC7.1, PCI DSS 6.3, NIST 800-53 RA-5) so the audit reads from the engagement rather than from a reconstruction.

Five campaign signals the engagement surfaces by default

When campaign-mode remediation runs on engagements rather than on memory, five signals come straight off the record without a manual reporting pass. They drive the daily cadence, the leadership brief, the mid-campaign re-prioritisation, and the post-mortem agenda.

Burn-down curve against the baseline cohort

The campaign engagement carries the starting cohort count and the running closure rate. The burn-down reads as a curve against the baseline rather than as an absolute open count, so net-new ingest that matches the cohort filter does not distort the headline. Leadership sees whether the campaign is on track against the committed deadline.

Per-stream closure velocity and stall events

Each work stream carries its own closure velocity. Streams that stall surface against the campaign cadence so the campaign owner can ask the right question to the right team rather than triaging the whole campaign at once. Stall events (findings idle in in_progress beyond a defined threshold, no activity-log entries for a defined window) read off the live record.

Verification-failure rate per stream

The verification scan attaches the closure to evidence. Verification failures (closures that did not survive the follow-up scan) read as a rate per stream so the campaign owner can see whether a specific team or fix path has a regression problem. Verification-failure rate is a leading indicator of post-campaign regression and a primary post-mortem signal.

Cohort coverage by named owner

Findings without a named owner are findings the campaign cannot drive. The engagement surfaces the unowned subset so the campaign opens with the ownership gap visible rather than discovered late. The unowned-cohort ratio is a leading indicator of campaign slip and a primary onboarding signal.

Exception register additions during the campaign window

When a finding inside the campaign cohort moves to an exception decision, the exception lands on the register with the named approver, the residual rationale, and the hard expiry. The exception-addition rate during the campaign is a structural signal: a small share is expected, a large share means the cohort scope was wrong or the fix path was harder than estimated.

Reviewer checklist before the campaign engagement closes

Before the campaign engagement is marked closed and rolls into the post-mortem queue, the named accountable owner runs through a short checklist. Each line takes seconds; missing any one of them is the source of the failure modes above.

  • The campaign engagement carries the trigger reference, the named accountable owner, the executive sponsor, the deadline, and the baseline snapshot.
  • The cohort scope filter is recorded on the engagement so the same filter can re-run at any point in the campaign.
  • Work streams are assigned with named owners and the right team-management access level.
  • Every closure on the cohort carries a verification source (a scan re-run, a retest pairing, or a manual evidence artefact attached as a finding state event).
  • Scope changes, capacity adjustments, and deadline extensions during the campaign are recorded as structured decisions on the engagement, not as silent slips.
  • The final post-campaign report draws from the engagement record (AI report generation against the structured evidence) rather than from a separate slide deck.
  • The activity log CSV export covers the audit ask for ISO 27001 Annex A 8.8, SOC 2 CC7.1, PCI DSS 6.3, and the regulator window the campaign opened against.
  • The post-mortem captures which work streams drained on plan, which fix paths to preserve as a template, and which verification surfaces caught regressions.

Where campaign management sits across the vulnerability lifecycle

The campaign engagement sits alongside the steady-state vulnerability lifecycle on the same engagement primitives. The campaign focuses scope, named ownership, and verification for a time-boxed window; the steady-state workflows continue against the rest of the backlog in parallel. When the campaign closes, the cohort assets fold back into the regular cadence.

Steady-state remediation

Remediation tracking and patch management coordination cover the rolling cadence. The campaign bypasses the cadence on the cohort assets and folds them back in once the engagement closes.

Emergency response

The zero-day and emergency vulnerability response workflow opens against a single critical CVE trigger. A follow-on campaign may pick up the class of findings the emergency response surfaced.

Backlog management

Vulnerability backlog management holds the standing posture; the risk-register decision to drain an aging cohort usually opens a campaign engagement against the backlog subset.

Prioritisation and exceptions

The vulnerability prioritisation workflow holds the queue model the campaign applies on each finding. Exceptions during the campaign land in the vulnerability acceptance and exception management workflow with named approver and hard expiry.

Fix verification

Security finding fix verification holds the per-finding verification pattern the campaign closure gate applies. The campaign engagement aggregates the verification evidence across the cohort.

Leadership reporting

Security leadership reporting reads the campaign signals into the recurring review cycle. The campaign post-mortem feeds the next leadership review with named-outcome evidence.

Pair the workflow with the supporting research and guides

Campaign-mode remediation lives alongside the rest of the vulnerability lifecycle 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 vulnerability prioritisation framework for the layered queue the campaign applies on each finding, the remediation SLA policy guide for the deadline vocabulary, the vulnerability remediation throughput analysis for the capacity-versus-ingest model, the security debt economics analysis for the carry-over framing, and the CISA KEV catalogue guide for the regulatory-deadline signal that often opens campaign engagements.

Buyer and operator pairing

A structured remediation campaign is the operating model internal security teams, vulnerability management teams, AppSec teams, security engineering teams, security operations leaders, and CISOs rely on when steady-state remediation cannot answer a deadline or a leadership commitment alone. The framework references that shape the campaign cadence include ISO 27001, SOC 2, PCI DSS, NIST CSF 2.0, and DORA. The supporting tools include the vulnerability remediation worksheet, the vulnerability management programme scorecard, and the security exception register template.

Frequently asked questions

What is the difference between a remediation campaign and steady-state remediation tracking?

Steady-state remediation runs against the open queue continuously. Every new finding enters the queue with an SLA, an owner, and a triage decision; closures drain the queue at the rate the programme capacity supports. A remediation campaign is a time-boxed, scope-bounded push on a defined cohort of findings, with named owners across teams, parallel work streams, a daily cadence, and a verification pass at the end. Steady-state remediation is the operating model; the campaign is the operational answer to a regulatory deadline, a risk-register drain decision, a library upgrade window, or a leadership commitment from the last review. Both run on the same engagement primitives in SecPortal, with the campaign opening a dedicated engagement so the cohort, the cadence, and the post-campaign evidence stay distinct from the standing backlog.

How is a remediation campaign different from a zero-day emergency response engagement?

A zero-day emergency response engagement opens against a single critical CVE with active-exploitation evidence (a Log4Shell-style or MOVEit-style trigger), runs the exposure assessment across the estate, and closes when every confirmed exposure on the engagement is verified remediated or accepted. A remediation campaign opens against a broader cohort filter (a class of findings, a category of fix, an aging bucket, an asset cohort) and runs across a planned window that may be days, weeks, or a quarter long. The emergency response is reactive against a single trigger; the campaign is deliberate against a defined cohort. The two workflows share the engagement primitives in SecPortal and can hand off to each other (an emergency response that uncovers a class of findings can hand off to a follow-on campaign).

Can SecPortal bulk-import findings from another platform into the campaign engagement?

Yes. The bulk finding import workflow lets the campaign engagement ingest findings from CSV exports, from scanner outputs (Nessus, Burp Suite, and similar formats), and from the global search across the workspace. The imported findings inherit the cohort tags and the campaign engagement reference so they land on the campaign cohort rather than on the standing backlog. The import event lands on the activity log with the source artefact reference so the audit trail captures the import provenance.

How does the platform verify a closure inside a campaign?

Closure verification draws from the same scanning surfaces the rest of the platform runs: a follow-up authenticated scan against verified domains with stored AES-256-GCM-encrypted credentials, a re-run of the code scan against connected GitHub, GitLab, or Bitbucket repositories with Semgrep SCA, an external scan against the affected internet-facing surface, or a manual retest pairing through the retesting workflow. The verification source attaches to the finding as a state event with the timestamp and the scan reference. Closures without an attached verification source stay open in the campaign report; the deadline does not absolve the verification requirement.

How does the campaign engagement support audit and leadership reporting?

The engagement carries the campaign trigger, the cohort scope filter, the baseline snapshot, the work-stream owners, the per-finding response decisions, the verification scan artefacts, the exception register additions, and the closure timeline as structured fields. AI-assisted report generation drafts the executive summary, the audit-evidence narrative, and the customer-facing artefact where the campaign affects downstream consumers. The activity log retains the timestamped state changes for the plan-defined window with CSV export. ISO 27001 Annex A 8.8 (technical vulnerability management), SOC 2 CC7.1 and CC7.2, PCI DSS Requirements 6.3 and 11.3, NIST SP 800-53 RA-5 and SI-2, and CISA BOD 22-01 audit questions read from the engagement record.

Does SecPortal connect to ticketing systems for the campaign work?

SecPortal models the campaign on its own engagement record with findings, named owners, status workflow, notifications, activity log, and verification scans. The platform does not run a built-in connector to Jira, ServiceNow, Slack, or other external ticketing or chat platforms. 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 works in an external system, the campaign engagement remains the durable record (the cohort scope, the verification evidence, the audit trail) while the external system holds the engineering execution detail. The scanner-to-ticket handoff governance workflow describes the boundary discipline if the campaign needs to surface tickets externally.

How it works in SecPortal

A streamlined workflow from start to finish.

1

Define the campaign trigger and the cohort scope

Every campaign opens against a named trigger: a regulatory remediation deadline (PCI DSS quarterly scan miss, DORA window closure, CISA BOD KEV deadline, NIS2 incident-related remediation), a risk-register decision to drain an aging class of findings, a programme decision to retire a deprecated library across services, a leadership commitment from the last security review, or a major release window engineering won for a coordinated upgrade. The trigger lands on the engagement with the deadline, the named accountable owner, and the executive sponsor. The cohort scope captures which findings are in the campaign and which are out: filter by CVE identifier, by affected component, by severity band, by aging bucket, by asset class, by team, or by tag. The scope record is the campaign boundary, not the open backlog.

2

Snapshot the starting position so the campaign has a reference baseline

Before the campaign starts work, snapshot the cohort: total findings in scope, distribution by severity, distribution by named owner, distribution by team, distribution by aging bucket, count of findings already with an active exception, and count of findings without a named asset owner. The baseline lives on the engagement as the starting reference for burn-down progress and for the final post-campaign report. Without a baseline, the campaign cannot tell whether closures are draining the cohort or whether new ingest is masking the drain.

3

Stand up parallel work streams with named owners across teams

A campaign almost always crosses team boundaries. Use team management with role-based access to bring the application owners, platform owners, infrastructure owners, and incident-response watchers onto the engagement at the right access level. Group findings into work streams by team, by asset, or by fix path so each owner sees their queue without the noise of every other stream. Watchers from security leadership, GRC, and the programme management office join read-only so the campaign cadence reads off one record rather than from cross-channel status updates.

4

Run the daily campaign cadence on the live engagement record

Campaign-mode remediation needs a faster cadence than the steady-state queue. Each work stream updates finding status (open, in_progress, awaiting_retest, resolved) against the case lifecycle so the engagement record reflects live progress rather than yesterday standup notes. Notifications surface stuck findings to the named owner. The activity log carries the timestamped state changes so the post-campaign retrospective is reconstructible rather than reconstructed from memory. The daily standup reads the engagement record live; the spreadsheet stays closed.

5

Re-prioritise mid-campaign when scope, capacity, or risk shifts

No campaign lands on plan. New findings ingest that match the cohort filter. A team loses capacity. A fix path turns out to be harder than scoped. A dependent service blocks the upgrade. Capture the change as a structured decision on the engagement: scope additions, capacity adjustments, deadline extensions with executive sign-off, exceptions for findings that will not close inside the window. The deliberate decision is recorded; the silent slip is not allowed. Re-prioritisation is part of the campaign, not the failure of the campaign.

6

Verify every closure with a retest or a follow-up scan

Campaign closure is evidence, not assertion. Each finding that moves to resolved triggers a verification pass: a follow-up authenticated scan against a verified domain, a re-run of the code scan against the connected repository, an external scan against the affected internet-facing surface, or a manual retest pairing through the retesting workflow. The verification scan attaches to the same finding as a state event so the closure carries the verification timestamp and the verification source. Findings that did not survive verification stay open with the regression reason captured so the next cycle starts from the same record.

7

Close the campaign, publish the report, and feed the next post-mortem

Mark the engagement closed when every cohort finding is verified remediated, accepted with documented residual risk through the exception register, retired with a decommissioned asset, or escalated to a follow-up programme with a named owner. Use AI-assisted reporting against the structured engagement evidence to draft the executive summary, the audit-evidence narrative, and the customer-facing artefact where the campaign affects downstream consumers. Publish through the branded client portal on the tenant subdomain. The activity log CSV export covers the audit asks. The closed engagement feeds the post-mortem: which work streams drained on plan, where verification surfaced regressions, which fix paths the next campaign should preserve as a template.

Run the next remediation campaign on one engagement record

Cohort scope, named owners across teams, parallel work streams, daily cadence, verified closure, and audit-ready post-campaign evidence. Start free.

No credit card required. Free plan available forever.