Most security teams do not choose ad-hoc remediation on purpose. They inherit it. Scanners produce findings, the worst ones get attention, and the rest sit in a backlog that nobody can fully account for. When a deadline matters, it lives in someone’s head or a side spreadsheet. This works until the program grows, the finding count climbs, and an auditor asks a question that the team cannot answer with evidence.
SLA-driven remediation is the alternative. Instead of reacting to whatever feels urgent, every finding carries a deadline derived from its severity, and the platform tracks that deadline, escalates when it slips, and groups related work into campaigns that report their own progress. The shift is less about working harder and more about making the clock and the accountability explicit.
This article compares the two operating models across six criteria that decide whether remediation scales: how deadlines are set, what happens when one slips, how the clock reacts to severity changes, how work is coordinated, how progress is measured, and how accountability is captured for audit. The comparison stays grounded in how PMAP implements SLA configuration and remediation campaigns, so the claims reflect real platform behavior rather than aspiration.
If you are weighing a move from reactive patching to a structured model, the goal here is a clear-eyed read on what each approach actually gives you and where the ad-hoc model quietly fails as the program scales.
Two Operating Models for Fixing Vulnerabilities
Ad-hoc and SLA-driven remediation are not two settings of the same dial. They are different ways of relating to time and ownership.
In the ad-hoc model, a finding has a severity and a status, but no contract about when it must be resolved. Prioritization happens in the moment. The team patches what looks dangerous this week, defers the rest, and revisits the backlog when capacity allows. There is nothing inherently wrong with triage by judgment, but the model has no memory. A finding that was deprioritized in March looks the same in June, and no system flags that it has aged past any reasonable window.
In the SLA-driven model, severity maps to a number of hours. A finding inherits a deadline at the moment it is created, calculated from its severity against a configured threshold. PMAP resolves that threshold through a precedence chain and stamps an sla_deadline on the finding when it lands. From that point, the deadline is a tracked property of the record, not a memory or a side note.
Campaigns sit on top of this. A remediation campaign in PMAP is a named, time-bounded grouping of findings assigned to a responsible owner. It is the mechanism for coordinating work across many vulnerabilities and tracking progress toward closure at the program level rather than finding by finding. The state machine, the ownership, and the progress metrics turn a pile of deadlines into a managed effort.
The rest of this comparison walks through where these two models diverge in practice.
Criterion 1: How Deadlines Are Set
The first and most consequential difference is whether a deadline exists at all.
Ad-Hoc: No Deadline, No Clock
In a purely ad-hoc workflow, a finding’s urgency is a judgment call repeated every time someone looks at the queue. There is no clock counting down, so there is no objective signal that a finding is late. “Late” is whatever the team feels guilty about. This makes prioritization unstable, because the same finding can be urgent on a quiet week and forgotten on a busy one.
PMAP still functions if you never configure SLAs, and that fallback is instructive. When no config exists at any level, ResolveHours falls back to built-in defaults: urgent 24 hours, critical 72 hours, high 168 hours, medium 720 hours, and low 2160 hours. So even the platform’s most permissive starting point is not truly deadline-free. The hardcoded values exist precisely because a finding with no deadline is a finding nobody is accountable for. Running without your own thresholds means accepting someone else’s defaults, which is a weaker position than choosing them.
SLA-Driven: Severity Decides the Deadline
The SLA-driven model makes the deadline a function of severity and scope. In PMAP, an SLA config is a severity-to-hours mapping that governs how long a finding of a given severity may remain open before it breaches. You define these thresholds at the company level for all findings within a company, or at the project level for a specific project, and they layer on top of platform-wide global defaults.
The practical effect is that a critical finding in a payment project can carry a tighter deadline than a critical finding in an internal tool, because the project-level config overrides the company-level one. Severities recognized are urgent, critical, high, medium, and low, matching the finding domain exactly, so the mapping is unambiguous.
The resolution follows a strict precedence chain. For a given severity, project, and company, PMAP applies this waterfall:
- Project config thresholds for that severity
- Company config thresholds for that severity
- Global defaults from admin settings
- Hardcoded values (urgent 24 h, critical 72 h, high 168 h, medium 720 h, low 2160 h)
- A final fallback of 168 hours
A level is skipped if its config row is absent, or if the specific severity field is null or zero. The first non-zero positive value wins. This is why partial overrides work. An admin can set a tighter deadline for critical at the project level and let medium and low inherit from the company or global level. You tighten what matters and leave the rest to cascade, which keeps configuration small and intentional. For a deeper look at how thresholds and routing are configured, see SLA thresholds and escalation routing.
This is the foundation of the whole comparison. Once a deadline exists as a stored property, everything downstream becomes possible: escalation, recalculation, progress reporting, and audit. Without it, none of those have anything to anchor on.
Criterion 2: What Happens When a Deadline Slips
Setting a deadline is only useful if something happens when it passes. Otherwise the date is decoration.
In the ad-hoc model, nothing happens automatically. A missed window is discovered when someone notices, if anyone does. Escalation, where it exists, is a manual message to a manager, and it depends entirely on whoever is paying attention. The breach has no structure and leaves no trail.
The SLA-driven model encodes escalation into the configuration. Each PMAP SLA config can specify up to three escalation contacts. Each contact is a user paired with a days-after-breach trigger, which means escalation is tiered rather than a single alert. You can route a first notice to the assigned owner a day after breach, a second to a team lead a few days later, and a third to a manager further out. The config holds escalation_level1_user_id through escalation_level3_user_id, each with its own days value, at company or project granularity.
This is the difference between an alert and a chain of accountability. A single escalation tells one person once. A three-level chain reflects how organizations actually respond to overdue risk: the owner gets a chance first, then their lead, then leadership. Because the chain lives in the config rather than in someone’s calendar, it fires consistently whether or not anyone remembers to send the message.
Routing is the operational half of this story. For how thresholds and escalation chains are configured end to end, the dedicated guide on SLA thresholds and escalation routing covers the mechanics. The point for this comparison is structural: ad-hoc remediation treats a breach as an exception you happen to notice, while SLA-driven remediation treats it as a defined event with a routed response.
Criterion 3: Recalculation When Severity Changes
Real findings do not hold still. A medium finding gets reclassified as high after new exploit intelligence. A critical gets downgraded once a compensating control lands. The question is whether the deadline keeps up.
In an ad-hoc workflow, there is no deadline to update, so a severity change has no effect on any clock. The team simply re-judges the finding the next time they look at it.
In PMAP, the deadline is recomputed whenever the inputs change. The finding service calls SLA resolution in four places: when a finding is created and gets its initial deadline, when a finding is updated and its severity changes, when an SLA pause is resumed and accumulated pause hours are subtracted, and during a bulk status change for affected findings. So a severity change is not a cosmetic relabel. It moves the deadline to match the new contract.
Configuration changes propagate too. When a company or project SLA config is saved through a PUT, the handler immediately recalculates sla_deadline for all open findings in scope and returns the count in an X-Recalculated-Count header. You do not have to manually re-stamp existing findings after tightening a threshold. The platform does it inline. There is also an on-demand bulk recalculation endpoint for cases like a global-default change in admin settings, where you want to re-run the math without altering the stored config.
The recalculation formula is explicit. For each open finding with a non-null deadline, the new deadline is the finding’s creation time plus the resolved SLA hours plus any accumulated pause hours. If the recomputed deadline lands in the future, the sla_notified flag is reset to false so the notification pipeline re-fires as the new deadline approaches. This reset matters. Without it, a finding whose deadline was pushed out would never warn again, because the system would still think it had already notified. The flag reset keeps notifications honest after a recalculation. The deadline calculation mechanics are covered in depth in the cluster guide on SLA deadline calculation.
The contrast is sharp. Ad-hoc remediation has no clock to drift, which sounds like an advantage until you realize it also means there is no clock to trust. SLA-driven remediation keeps a single deadline that stays correct as severity, pauses, and policy change underneath it.
Criterion 4: Coordinating Work, Campaign vs Case-by-Case
Deadlines tell you when each finding is due. They do not, on their own, organize the work of fixing many findings together. That is where the two models diverge again.
Ad-hoc remediation is case-by-case by nature. Each finding is its own small project, assigned informally or not at all, with progress visible only by opening the record. There is no object that represents “the Q3 web app hardening effort” as a trackable thing. The effort exists only in meetings and status updates.
PMAP’s answer is the remediation campaign. A campaign is a named, time-bounded grouping of findings with a responsible owner, start date, and due date. Findings are linked into a campaign by UUID, and the service enforces that they stay within the campaign’s company at the database layer, so a campaign cannot accidentally pull in cross-tenant findings. This gives the program a real object to plan against rather than a loose collection of records. For the full lifecycle of building and running these, see remediation campaign management.
Campaigns move through an enforced state machine. The valid transitions are:
drafttoactiveorcancelledactivetorevieworcancelledreviewtocompleted, back toactive, orcancelledcompletedis terminalcancelledis terminal
An invalid transition is rejected rather than silently applied. This is what separates a campaign from a tag. A tag is just a label you can attach and remove at will. A campaign has a lifecycle that the platform enforces, so its status means the same thing every time you read it. A campaign in review has genuinely moved past active work and is being verified, not merely labeled that way by someone’s optimism.
Bulk Assignment and Ownership
Coordinating work also means assigning it efficiently. PMAP’s bulk-assign lets you assign a single user to all findings in a campaign, or to a specified subset, in one request. The operation is scoped to findings actually linked to the campaign through the membership join, so passing finding IDs from outside the tenant silently affects zero rows rather than leaking data.
Each affected finding emits a FindingAssigned notification event, so assignment is not a silent database write. The people who just received work get told. In an ad-hoc workflow, assignment is usually a message in a chat channel that scrolls away. In the campaign model, ownership is a property of each finding and a notification at the moment it changes, which is the difference between informing people and hoping they saw it.
Criterion 5: Measuring Progress and Closure
You cannot manage what you cannot measure, and ad-hoc remediation is notoriously hard to measure. Progress is a feeling assembled from individual statuses, and “how are we doing” gets answered differently depending on who you ask.
PMAP computes campaign progress directly. Fetching a campaign by ID returns four computed counters: total_findings, closed_findings, overdue_findings, and a closure_rate expressed as a float. These are not numbers someone maintains by hand. They are derived from the current state of the linked findings every time the campaign is read.
This turns a vague status update into a defensible metric. total_findings is the scope of the effort. closed_findings is what has actually been resolved. overdue_findings is the count past deadline, which only has meaning because the SLA model gave every finding a deadline to be past. closure_rate is the single number a manager can report upward without caveats. The progress view ties the SLA half and the campaign half together, because overdue is a function of the deadlines from Criterion 1, surfaced through the campaign from Criterion 4.
The ad-hoc equivalent of these metrics is a spreadsheet someone updates on Friday, which is stale by Monday and trusted by nobody. The structural advantage is not that the numbers are prettier. It is that they are computed from the source of truth at read time, so they cannot drift from reality the way a manually maintained tracker does.
Criterion 6: Accountability and Audit
The final criterion is the one that decides whether your remediation program can survive scrutiny. When an auditor, a customer, or an executive asks who owned a finding, when it was due, and what happened when it slipped, the two models give very different answers.
Ad-hoc remediation answers from memory. Ownership was a conversation, the deadline was an understanding, and the escalation, if it happened, was an email someone may have kept. None of it is structured evidence. Reconstructing the history of a single overdue finding can take hours of digging, and the result is a narrative rather than a record.
SLA-driven remediation answers from data. The escalation contacts are stored in the config, so the routing policy is itself a documented control: these people are notified at these intervals after a breach. Each campaign carries its owner and due date as first-class fields, so ownership and scheduling are recorded rather than recalled. The campaign also tracks created_by and timestamps, so there is a clear record of who set the effort up and when.
This is where the SLA and campaign models reinforce each other. The SLA config defines the time contract and the escalation chain. The campaign defines the owner, the schedule, and the measured outcome. Together they produce the chain of evidence that compliance work depends on: a deadline that was set by policy, a routing that fired by configuration, an owner who was accountable by record, and a closure rate that was computed from the findings themselves. For how this evidence fits into broader audit readiness, see the pillar on vulnerability management for compliance and audit.
External frameworks reinforce why the deadline matters in the first place. NIST SP 800-40 Revision 4 frames patch and vulnerability management around timely, risk-prioritized remediation rather than reactive patching. The CISA Known Exploited Vulnerabilities catalog goes further by attaching explicit due dates to actively exploited flaws, which is the public sector’s version of an SLA. A model that cannot represent a due date cannot align with guidance built around due dates. The FIRST CVSS specification gives you the severity inputs that feed the threshold mapping. Aligning your own thresholds with these references turns an internal preference into a defensible policy.
When Ad-Hoc Is Tempting and Why It Breaks at Scale
It would be unfair to pretend ad-hoc remediation has no place. For a very small program with a handful of findings and one or two people who fix them, the overhead of configuring thresholds and running campaigns can feel like ceremony. When the whole backlog fits on one screen and the person fixing it also triaged it, the deadline lives in their head accurately enough.
The model breaks on three predictable axes as the program grows.
It breaks on volume. Once findings number in the hundreds or thousands, no one can hold the queue in their head. The findings that get attention are the ones that happen to be visible, not the ones that are most overdue, and there is no deadline to make overdue visible.
It breaks on handoff. Ad-hoc ownership is informal, so when the person who knew the context leaves or rotates, the context leaves with them. SLA-driven remediation stores ownership and deadlines as data, so a handoff is a reassignment rather than a knowledge loss.
It breaks on accountability. The first time leadership or an auditor asks for a defensible answer about overdue risk, the ad-hoc model has only anecdotes. Program-level tracking through campaigns and SLAs beats finding-by-finding firefighting precisely because it produces evidence as a byproduct of normal work, not as a special project assembled under pressure.
The honest framing is not that ad-hoc remediation is always wrong. It is that ad-hoc remediation does not scale, and most programs cross the threshold where it stops working before they notice. By the time the cracks show, the team is already firefighting, which is the worst moment to start building structure.
How PMAP Drives Remediation by SLA and Campaign
Putting the criteria together, PMAP implements the SLA-driven model through two cooperating domains that map cleanly onto the comparison above.
The SLA config domain owns the time contract. It resolves a deadline for every finding through the precedence chain (project, then company, then global defaults, then hardcoded values, then a 168-hour final fallback), stamps sla_deadline on the finding, and recalculates that deadline whenever severity, pauses, or thresholds change. It carries the three-level escalation routing that turns a breach into a tiered response, and it resets the notification flag during recalculation so warnings stay accurate. Because resolution is one-directional and the config is a pure provider, the deadline logic stays predictable and the same severity always resolves the same way for a given scope.
The campaign domain owns the coordination. It groups findings into named, time-bounded efforts with an owner and due date, enforces a state machine so status always means what it says, bulk-assigns work with per-finding notification events, and computes live progress metrics on every read. It enforces company scope at the database layer so a campaign never reaches across tenants.
Together they replace the ad-hoc loop with a tracked one. A finding arrives, inherits a deadline from policy, joins a campaign with a clear owner, escalates on its own schedule if it slips, and reports its closure into a metric leadership can act on. None of those steps depend on someone remembering to do them, which is the entire point of moving from firefighting to a tracked model.
If you are evaluating that move, the SLA and KPI datasheet and the vulnerability management for compliance and audit pillar show how the deadline-driven model produces the metrics and evidence that ad-hoc patching cannot. Download the SLA and KPI datasheet and replace ad-hoc patching with deadline-driven remediation in PMAP.
