How to Run a Vulnerability Management Engagement

A vulnerability management engagement runs on a continuous cycle, not a single event: scan the environment, triage findings by real-world exploitability, remediate down to zero open criticals, and produce audit-ready evidence at every step. Most engagements take four to six weeks to reach a stable rhythm, then continue as an ongoing program.

What a Vulnerability Management Engagement Actually Covers

Vulnerability management gets confused with a one-time penetration test, but they solve different problems. A pen test is a point-in-time attack simulation. A vulnerability management program is the operational discipline that finds, prioritizes, and closes weaknesses across your infrastructure on an ongoing basis, which is what SOC 2, ISO 27001, and most enterprise security questionnaires actually expect to see evidence of.

For a Canadian B2B SaaS company selling into the US, this distinction matters. Auditors and enterprise security teams do not just want to know you ran a scan once. They want a documented process: scan cadence, triage criteria, remediation SLAs, and a closed-loop record proving issues got fixed, not just found.

Week 1: Scoping and Asset Discovery

Every credible engagement starts with an honest inventory. You cannot scan what you do not know exists, and most companies underestimate their own attack surface, especially after a few years of shadow IT, forgotten staging environments, and third-party integrations.

• Cloud accounts, VPCs, and public-facing IPs (AWS, Azure, GCP)
• Internet-exposed applications, APIs, and subdomains
• Internal endpoints, servers, and containers in scope for authenticated scanning
• Third-party SaaS tools that touch customer data

This week also sets the rules of engagement: scan windows, notification protocols for production systems, and who owns remediation on the client side. Skipping this step is the single most common cause of a vulnerability management program stalling after month two.

Weeks 2 to 3: Deploying Continuous Scanning

Once scope is locked, scanning tooling gets deployed across the environment, covering network, application, and cloud configuration layers. The goal is continuous coverage, not a quarterly sweep. New code ships weekly, new dependencies get pulled in constantly, and a scan cadence that runs monthly or less leaves weeks of blind spots between checks.

A working program typically runs:

• Daily or weekly automated scans against external-facing assets
• Authenticated internal scans on a regular schedule
• Dependency and container image scanning tied into CI/CD

This is also where a lot of in-house attempts break down. Tooling is easy to buy. Someone actually reading the output every week, without alert fatigue burying the one finding that matters, is the harder part.

Triage: Why Exploitability Matters More Than CVSS Score

A raw scanner report from a mid-sized environment routinely returns hundreds or thousands of findings. Treating every "critical" CVSS score as equally urgent is how teams burn out and stop paying attention to the report entirely.

Real triage weighs exploitability in context, not the score in isolation:

• Is the affected asset actually internet-reachable, or sitting behind three layers of network controls?
• Is there a public proof-of-concept or active exploitation in the wild?
• Does the vulnerable component process customer data or sit adjacent to it?
• Are compensating controls already in place?

This is where a partner with real offensive security experience earns its keep. A firm that has published CVEs and understands how attackers actually chain vulnerabilities together triages differently than a checklist reviewer working purely off scanner severity labels. A CVSS 9.8 finding on an isolated internal test box is a lower priority than a CVSS 7.1 on a production login endpoint, and a program that cannot make that call generates noise instead of security.

Weeks 3 to 6: Remediation to Closed, Not Remediation to "Reported"

The step most programs quietly fail at is closing the loop. Plenty of scanning tools generate a report and stop there. A functioning vulnerability management engagement tracks each finding through to a verified fix, with SLAs tied to severity:

• Critical findings on exposed assets: days, not weeks
• High severity: typically within two to four weeks
• Medium and low: scheduled into the next patch cycle, not indefinitely deferred

Remediation itself is usually a mix of patching, configuration changes, and occasionally compensating controls when a fix requires a larger engineering effort. A good partner does not just hand your team a spreadsheet of findings and disappear. They help prioritize the fix against your actual roadmap and re-scan to confirm the issue is actually closed, not just marked closed.

Turning the Program Into Compliance Evidence

If the end goal is SOC 2, ISO 27001, or answering enterprise security questionnaires, the vulnerability management cycle needs to produce evidence as a byproduct, not as a separate scramble before the audit. Auditors want to see scan history, triage rationale, remediation timelines, and proof of closure, going back a full review period.

Companies pursuing SOC 2 alongside a broader compliance program save significant time when vulnerability management evidence is already structured this way from day one, instead of reconstructing six months of scan logs the week before an auditor asks for them.

Where a Canadian Partner Adds Value

Boutique firms based in Canada bring two advantages larger vendors and generic platforms do not. First, familiarity with the Canadian regulatory layer: PIPEDA obligations around breach notification and Quebec's Law 25 for companies handling Quebec residents' data, both of which intersect with how vulnerability findings get documented and reported. Second, proximity. traztech works with technology companies in Toronto, Waterloo, Ottawa, Vancouver, Calgary, and Montreal, and understands the specific pressure Canadian SaaS companies face when a US enterprise deal is blocked on a security review.

Large platform vendors sell you a dashboard and leave the triage and remediation judgment to your own team. A boutique engagement puts an experienced practitioner in the loop on the calls that matter, which is usually the difference between a program that produces clean audit evidence and one that produces an ignored backlog.

What a Realistic Timeline Looks Like End to End

• Week 1: Scoping, asset discovery, rules of engagement
• Weeks 2 to 3: Scanning tooling deployed, first full-environment sweep
• Weeks 3 to 4: First triage pass, exploitability-based prioritization delivered
• Weeks 4 to 6: Remediation sprint on criticals and highs, re-scan to verify closure
• Ongoing: Continuous scan cadence, monthly reporting, evidence accumulation for audit

By week six, a company has a working baseline: a known asset inventory, a live scan cadence, and a first cycle of findings taken from discovery through to verified remediation. Everything after that is maintaining the cadence and building the evidence trail an auditor will eventually ask to see.

Getting Started

Running vulnerability management well is less about the scanning tool and more about the judgment applied to what it finds and the discipline to close the loop every cycle. If your team is heading toward a SOC 2 audit, responding to enterprise security questionnaires, or just tired of a scanner report nobody reads, get in touch with traztech to scope a vulnerability management engagement built around your environment and timeline.

What the Auditor Actually Asks For

Auditors do not read your dashboard. They pull a sample and follow it end to end. Expect a request for the complete asset population as of a date inside the review period, so they can confirm the scanned population matches the systems in scope, then expect them to pick five to fifteen findings at random and ask, for each one, when it was detected, how it was rated, which ticket tracked it, who approved the fix, and what evidence shows the rescan came back clean. Expect a question about scan configuration, because an unauthenticated scan of a Linux fleet finds almost nothing. Keep the credentialed scan success rate as a reported figure, since a scan that silently fell back to unauthenticated on forty percent of hosts is a real finding about your programme rather than a technicality.

The failure mode is rarely a missing control. It is a ticket that says "patched" with no rescan attached, or a finding closed the day it opened with a comment reading "not applicable" and no name against it.

The Findings You Cannot Fix

Every environment has some: an appliance whose vendor has not shipped firmware in two years, a library pinned because the next major version breaks an API you expose publicly, an operating system you cannot move off until a database migration lands. None of these are audit failures on their own. Silence about them is.

What closes the gap is a proper exception record. Capture the finding identifier, the affected assets by name, why the standard fix is unavailable, the compensating control that reduces exposure meanwhile, the named owner, the approver with authority to accept the risk, and an expiry date. The expiry date is the part teams skip and the part reviewers look for, because an exception without one is a permanent decision disguised as a temporary one. Review the register monthly and force each entry to be renewed on the record or closed. Eleven live exceptions with dates and owners reads as a functioning programme; two hundred inherited entries with no expiry reads as a backlog somebody renamed.

False Positives, and How to Retire Them Honestly

A meaningful share of scanner output on any mature Linux estate is wrong. Distribution maintainers backport fixes without changing the reported version string, so the scanner reads the banner, matches a CVE, and flags a host patched weeks ago. Suppress these, but with evidence attached and an expiry on the rule. A suppression that records the package version, the distribution advisory covering it, and the date it was verified survives a review. One that says "false positive, confirmed by Dave" does not, and worse, it hides the finding permanently when the next image build reintroduces the real vulnerability. Set suppression rules to lapse every ninety days.

Numbers Worth Reporting, and One to Ignore

The metric most programmes lead with is total findings closed, which measures scanner noise more than security. More useful: percentage of known assets covered by a successful authenticated scan last cycle, median time to remediate by severity, findings past their SLA with owner names beside them, and reopen rate, which catches fixes that did not hold through the next deployment. Watch coverage drift specifically. New accounts and clusters appear faster than most inventories update, and a programme quietly scanning eighty percent of production is the common way this work goes wrong unnoticed.

What Drives the Cost of an Engagement

Price tracks asset count, how many cloud accounts and engineering teams are involved, whether credentialed access can be granted quickly or needs three weeks of approvals, and whether scanning has to be built into an existing pipeline. Fixed-scope work is listed on pricing and penetration testing starts from $1,000, but ongoing ownership sits under a retainer described on engage, because the value is in the weekly triage judgment.

When You Should Not Hire Anyone for This

If you run one cloud account, under fifty assets, and a single platform engineer who already patches on a rhythm, hiring a firm to run vulnerability management is a poor trade. Turn on the scanning your cloud provider already includes, enable dependency and image scanning in your repository, book a recurring hour every second week to triage the output, and write a one page procedure describing your severity definitions and target fix times. That costs very little and satisfies most early-stage buyer reviews. Bring in help when the backlog outgrows the attention available for it, when an audit period has started and the evidence trail behind you is thin, or when your architecture has grown past what one person can hold in their head. Buying a programme before then tends to produce a tidy report and no change in risk.