Standing up a vulnerability management program is not the same task as running one. The first ninety days set the ceiling on what the program can achieve for the next three years: if the asset inventory is wrong, if the charter has no teeth, or if the SLA was picked to sound impressive rather than to survive contact with a real backlog, every cycle after that inherits the debt. Below is an order that holds up in practice, with the decision points made explicit.
Prerequisites before day one: asset inventory, ownership data, executive sponsor
Before a single scanner runs, three things need to exist, and none of them are the scanner.
The first is an asset inventory that is actually reconciled, not assumed. Pull from the CMDB, the cloud provider’s own inventory API (AWS Config, Azure Resource Graph, GCP Asset Inventory), and a network discovery pass, then diff them against each other. In most organizations doing this for the first time, the three sources disagree on 15 to 30 percent of hosts: decommissioned servers still in the CMDB, shadow cloud accounts with no CMDB entry, subnets nobody scanned in a year. That gap is the real starting scope of the program, and it needs to be closed, or at least documented, before you report a single finding. A dedicated asset inventory layer that ingests from multiple sources and flags the discrepancies automatically saves weeks of manual spreadsheet reconciliation here.
The second is ownership data. Every asset needs a named team or individual attached to it, not a department label. “IT” is not an owner; “Platform Engineering, on call rotation X” is. Without this field populated before intake starts, findings pile up in a queue that nobody feels responsible for, and the triage team ends up as the default owner of remediation work that was never theirs.
The third is an executive sponsor with actual authority, in writing, before the first scan. The sponsor’s job is narrow: adjudicate when a business unit refuses to remediate within SLA. Define the escalation trigger now, for example five business days of no response from the asset owner escalates to their manager, and fifteen days with no remediation plan escalates to the sponsor. If this path does not exist on paper, it will not exist under pressure, and the program’s first serious disagreement with a business unit will stall indefinitely.
Writing the program charter: scope, exclusions, authority
The charter is a one page document, not a wiki page. It needs a signature from the CISO or CIO, and ideally the executive sponsor, so it can be pointed to later when someone disputes what the program covers.
Scope should name asset classes explicitly: internal network, cloud workloads by account or subscription, internet facing web applications, and any vendor managed or SaaS systems the organization has contractual visibility into. Do not write “all systems.” It reads as thorough and functions as unenforceable.
Exclusions matter as much as scope, and they belong in writing rather than handled informally. Common exclusions in a first year charter: legacy systems already scheduled for decommission within a defined window, state the window, for example six months; OT or ICS segments that need a separate program with different tooling and different SLAs; and assets from a recent acquisition that have not yet been integrated into the CMDB.
Authority is the section most first year charters get wrong. State plainly whether security can mandate a remediation deadline or can only recommend one. If the answer is “recommend,” the SLA in the next section is aspirational, not operational, and the charter should say so rather than imply otherwise. Get the CIO’s sign off that non compliance can be escalated to the sponsor by name, not by title alone.
Choosing an initial policy and SLA baseline you can actually hold
The most common first year failure in this step is importing a textbook SLA table, critical: 15 days, high: 30, medium: 90, straight from a framework document without checking it against remediation capacity. The table looks credible in a slide deck and breaches within the first reporting cycle.
Two adjustments make the baseline survivable. First, tie SLA tiers to exposure and exploitability, not to CVSS score alone. A CVSS 9.8 on an internal, non routable asset with no known exploit is a different risk than a CVSS 7.5 on an internet facing host with a listed CISA Known Exploited Vulnerabilities entry. A workable first year table looks like this:
| Exposure and exploit status | SLA |
|---|---|
| Internet facing, in CISA KEV or with a public working exploit | 7 days |
| Internet facing, critical or high CVSS, no known exploit | 21 days |
| Internal, critical or high CVSS | 30 days |
| Internal, medium CVSS | 90 days, best effort |
Second, run the capacity math before publishing any table. Estimate how many high priority findings the first full scan will generate, divide by how many your patching teams can realistically close per week given existing change windows, and compare that rate to the SLA clock. If the math shows the backlog growing faster than it can shrink, either narrow the initial scope, for example internet facing assets only, or extend the SLA windows for the first two cycles and say so explicitly in the charter. A published SLA that breaches on day one trains the organization to ignore it for the life of the program.
Standing up intake, triage and the first work queue
Findings need a single system of record from day one. If scanner output, pentest reports, and manually reported issues live in three different places, the program cannot produce a coherent backlog number, and owners end up with contradictory tickets about the same underlying issue.
Between intake and the work queue, insert a triage gate with three concrete checks before a finding is allowed to become a ticket: deduplication against findings already open for that asset (the same CVE reported by two scanners is one ticket, not two), validation that the finding is not a false positive in that specific environment, and confirmation of an asset owner. Skip this gate and the first work queue floods with unconfirmed or duplicate items within the first week, which is usually the point where remediation teams stop trusting the program’s output.
Manual triage of a first full scan, which commonly returns several thousand raw findings, is not realistic for a small team. Platforms that automate this phase, such as SITEY, cross reference scanner output against exploit intelligence and prior findings before anything reaches a human, turning that raw volume into a queue of a few dozen confirmed, deduplicated items an owner can actually act on. Whether the step is automated or done by hand, the criterion for promoting a finding out of triage should be written down, not left to whoever is on shift that day. For the scanning layer itself, keeping an explicit map of which tool covers which asset class in scan management avoids the common gap where two scanners silently cover the same subnet while a third goes unscanned for months.
The first three reporting cycles and what to expect from them
The first cycle’s report should be framed as a baseline, not a scorecard. Expect an inflated backlog, and lead with coverage percentage, meaning the share of the inventory actually scanned, rather than a raw vulnerability count, which will otherwise dominate the conversation and read as failure.
The second cycle typically shows a wave of SLA breaches as remediation catches up to the baseline. This is expected, not a sign the program is failing, provided the breach rate is trending down rather than flat. If more than roughly 30 to 40 percent of findings are structurally missing SLA by the second cycle, the SLA table itself needs recalibration rather than more pressure on owners.
By the third cycle, the metric that matters is the trend line for mean time to remediate on the highest risk bucket specifically, not the overall average, which can be flattered by a large volume of low priority items closing quickly. A closing loop matters here too: a finding marked “remediated” because a patch ticket was closed is not the same as one confirmed closed by a re scan of that specific check. Programs that skip the re-test step routinely discover in the third cycle that a meaningful share of “closed” findings are still present. Report progress to the sponsor in terms of risk reduced on the tracked bucket, and keep the underlying data behind that summary in reporting that owners can drill into rather than a static slide.
First-year mistakes: over-scoping, count-based metrics, no exception path
Three mistakes account for most first year program failures, and all three are avoidable by decisions made at the charter stage.
Over-scoping is the most common. Trying to cover cloud, on premises, OT, mobile, and third party vendor systems in the same initial rollout guarantees that none of them get proper attention. Phase scope by asset criticality tier instead: internet facing production first, internal production second, everything else once the first two tiers have a stable cadence.
Count-based metrics are the second mistake. “We closed 500 vulnerabilities this month” says nothing about whether risk actually went down, since 500 low severity internal findings closing does not offset one internet facing critical sitting open past SLA. Report median age of open critical findings and the percentage of KEV listed internet facing items remediated within SLA instead. Both numbers are harder to game and both map directly to actual exposure.
The third mistake is having no formal exception path. Some findings genuinely cannot be remediated on schedule: a vendor dependency, a compensating control already in place, a system awaiting decommission. Without a defined risk acceptance workflow, these cases either sit as silent SLA violations that erode trust in the reporting, or get handled informally through emails that leave no audit trail. Build the exception request with three required fields from the start: the compensating control in place, an expiry date, and a mandatory re-review date before that expiry. Routing these requests through a defined approval gate rather than an inbox thread means the sponsor sees every exception before it becomes permanent by default, which is usually how undocumented risk accumulates in year two and three of a program that looked clean on paper in year one.
About SITEY
SITEY is an autonomous vulnerability management platform. It discovers, validates, prioritizes, remediates and re-tests vulnerabilities through an eight-phase automated pipeline, unifying output from 17 integrated scanners. SITEY is self-hosted: it runs in your own infrastructure and your findings are stored there. Outbound connections are limited to licence activation and the optional services you enable, such as an AI provider, CVE enrichment and patch catalogues. Pricing is 599 USD per month or 5,999 USD for a perpetual lifetime license. See pricing or how the platform works.