How to Get Vulnerability Management: A Step-by-Step Guide

Most teams do not wake up one day and decide they want vulnerability management for its own sake. Something forces the issue: a customer security questionnaire, a SOC 2 audit, a cyber insurance renewal, or a scare after a competitor got breached. Whatever brought you here, the good news is that vulnerability management is one of the more mechanical security programs to stand up. There is a clear sequence of steps, and each one has a realistic timeline attached to it.

This guide walks through that sequence: from having nothing in place to running a program that continuously finds, prioritizes, and closes out vulnerabilities, and produces evidence you can hand to an auditor without scrambling.

Step 1: Define what "in scope" actually means

Before any tool touches your environment, write down what you are protecting. This sounds obvious, but it is the step most teams skip, and it is the reason programs stall six months in when someone asks "wait, does this cover our staging environment?" and nobody knows.

At minimum, your scope should list:

• External-facing assets (websites, APIs, VPN endpoints, cloud load balancers)
• Internal infrastructure (servers, containers, internal APIs, databases)
• Cloud accounts and the services running in them (AWS, Azure, GCP)
• Endpoints, if your risk profile calls for it (laptops, workstations)
• Code and dependencies (open-source libraries, container images, IaC templates)

Realistic timeline: one to two weeks, mostly spent asking teams "what do we actually have running" and reconciling the answer against your cloud billing console, which rarely agrees with anyone's mental model.

Step 2: Pick tooling that matches your stack, not the vendor's demo

Vulnerability scanning tools split roughly into a few categories: network and infrastructure scanners, cloud security posture management (CSPM) tools, container and image scanners, and software composition analysis (SCA) tools for dependencies. Very few organizations need all of them on day one. A SaaS company running everything in containers on AWS has a very different starting point than a manufacturer with an on-premises network and a handful of legacy servers. Pick the tool that covers the largest share of your actual attack surface first, get it running well, then expand coverage. Trying to deploy five tools simultaneously is how programs die before they produce a single useful report.

Realistic timeline: two to four weeks for procurement, agent or scanner deployment, and initial configuration, longer if you have change-control processes that require approval for anything touching production.

Step 3: Run the first scan and expect noise

Your first scan will return a number that looks alarming. Hundreds, sometimes thousands, of findings. This is normal, and it is also where most in-house attempts at vulnerability management go sideways: someone looks at a CVSS score of 9.8, panics, and the team spends a week chasing a finding that is not actually exploitable in their environment because the affected service is not internet-facing, or the vulnerable code path is never called. The fix is triage by real exploitability rather than raw CVSS score. That means layering in context: is the asset reachable from the internet, is there a known exploit in the wild, does your configuration actually trigger the vulnerable behaviour, and what would an attacker gain if they used it. A 6.5-rated finding on an internet-facing admin panel deserves more urgency than a 9.1 on an isolated internal service with no path to it. This is the difference between a scan report and a program.

Realistic timeline: the first full triage pass typically takes one to two weeks for a mid-sized environment, and it gets faster every cycle once your team has a working sense of what is exploitable in your specific setup.

Step 4: Build a remediation workflow, not a spreadsheet

Findings need an owner, a due date tied to severity, and a place to live where progress is visible. A shared spreadsheet works for the first month. It stops working the moment you have more than one team fixing things, because nobody updates it consistently and it is the first thing an auditor will pick apart. Route findings into whatever ticketing system your engineering team already uses (Jira, Linear, ServiceNow) so remediation happens where the work happens, and track everything through to closed, not just "assigned." An open ticket that has not moved in three months is functionally the same as no ticket at all.

Realistic timeline: workflow setup is quick, a few days, but building the discipline to actually close tickets on schedule takes a full quarter to become habit.

Step 5: Make it continuous

A one-time scan tells you about the vulnerabilities that existed on the day you ran it. New CVEs are disclosed constantly, and your environment changes every time someone ships code or spins up a new cloud resource. Vulnerability management only earns its name when scanning is continuous rather than a quarterly fire drill. This is where the program shifts from a project into an operating rhythm: continuous scanning feeding triage, triage feeding tracked remediation, and remediation feeding evidence you can show. Our vulnerability management service is built around exactly this loop, so findings do not just get discovered, they get closed and documented.

Realistic timeline: once the loop is running, most organizations settle into a weekly triage cadence and a monthly reporting cadence, with critical findings handled as they appear rather than batched.

Step 6: Turn the program into audit evidence

If part of your motivation is SOC 2, ISO 27001, or a similar framework, your vulnerability management program is doing double duty whether you planned it that way or not. Auditors want to see that you find vulnerabilities on a regular cadence, that you prioritize them sensibly, and that you can prove remediation actually happened, not just that a ticket exists. Keep records simple but complete: scan history, triage decisions and rationale, remediation timelines against your own SLA, and closure evidence. If this program sits inside a broader compliance program, structure the evidence the same way from day one so you are not reconstructing history under audit pressure.

Realistic timeline: if steps one through five were done properly, evidence compilation for an audit takes days, not weeks. If they were not, this is where teams discover the gaps the hard way.

Where a partner actually helps

None of these steps require specialized expertise you cannot build in-house given enough time. What a partner changes is the timeline and the noise. An experienced team has already made the tooling mistakes, already knows which findings in your stack are typically exploitable versus theoretical, and can get you from zero to a running program in weeks rather than the two or three quarters it often takes a team building this for the first time while also doing their day job. That is particularly true for the triage step, where judgment matters more than any tool's default severity rating, and for keeping remediation tracked to closed instead of letting tickets go stale, which is the single most common reason vulnerability management programs fail an audit even after months of scanning.

Get started

If you are staring at a customer questionnaire, an upcoming audit, or just a gap you know you need to close, we can help you stand up a vulnerability management program that runs continuously and holds up under scrutiny. Get in touch and we will walk through your current environment, your timeline, and what a working program looks like for your team.

Setting SLAs you can actually meet

Every framework will ask what your remediation timelines are, and most teams answer with numbers copied from a template: critical in seven days, high in thirty, medium in ninety, low in a year. Those numbers then become the standard you are measured against for the rest of the program's life, including by an auditor who will pull a sample of findings and check the closure dates against them.

Write the numbers you can hit. A seven-day critical SLA is achievable if you can deploy on demand and your dependency updates are mostly automated. It is not achievable if you ship on a monthly release train, if a customer-facing change requires a change advisory board, or if the vulnerable component is embedded in a vendor appliance you do not control. Teams in that position are better served by a fourteen or thirty-day critical SLA with a documented compensating control and an exception process, because a policy you miss half the time is worse evidence than a slower policy you meet consistently.

Build the exception path into the policy from day one. There will be findings you cannot fix: an end-of-life library with no patched version, a vulnerability in a system scheduled for decommission next quarter, a fix that breaks a customer integration. The auditor is not looking for zero exceptions. They are looking for exceptions that were reviewed, approved by someone with authority, given a compensating control, and assigned a review date. An undocumented open critical is a finding. A documented risk acceptance signed by the CTO with a WAF rule in front of it is a functioning program.

Asset inventory is the part that quietly fails

Scope was step one, but scope written once in a document is not an inventory. The number that matters is coverage: what proportion of your actual estate is being scanned, measured against an independent source of truth rather than against the scanner's own list. A scanner cannot tell you about the host it does not know exists.

Reconcile from at least two directions. Pull the resource list from your cloud provider's API and compare it against scanner coverage. Pull the list of domains and subdomains from your DNS provider and your certificate transparency logs, because forgotten subdomains pointing at decommissioned infrastructure are one of the most reliable ways for an outsider to find something you have stopped watching. Compare your container registry against what is actually running in your clusters. Every one of those comparisons finds something in the first pass.

The gaps that recur most often in our engagements: development and staging environments excluded from scanning that turn out to hold production data copies, ephemeral infrastructure spun up by CI that lives long enough to be attacked but not long enough to be scanned on a weekly cadence, machine identities and service accounts nobody owns, and acquisitions or side projects running in a separate cloud account that never made it onto the register.

What auditors actually ask, and how the questions land

Auditors rarely ask whether you have a vulnerability management program. They ask questions that only a working program can answer. Expect these.

Show me the scan configuration. Not the report, the configuration. They want to see what was in scope, whether credentials were used, whether the schedule matches your policy, and whether anything was excluded. Unauthenticated scanning of an internal estate produces a comfortingly short list and proves very little, and experienced auditors know to check.

Pick a finding from four months ago and walk me through it. This is the sampling question, and it is where programs come apart. They will trace a specific finding from detection through triage, ticket, fix, and verification. If the ticket says "closed" with no comment, no linked commit, and no rescan evidence, you have a gap regardless of how good the rest of the program looks.

How do you know the fix worked? Closing a ticket is a claim. A subsequent scan showing the finding absent is evidence. For findings closed by configuration change rather than a patch, you need something equivalent: a screenshot, a configuration export, a test result.

Who reviews the metrics and how often? Somebody with authority needs to be looking at open findings past SLA on a regular cadence, and there needs to be a record that the review happened. A monthly summary sent to the CTO with a short note in the meeting minutes covers this. Nothing at all does not.

Metrics that mean something

Total open findings is a vanity number that goes up whenever your tooling improves and down whenever coverage lapses. It tells you nothing about whether the program is working. Track these instead.

Mean time to remediate by severity. The trend matters more than the absolute figure. A team moving from sixty days to thirty on highs is improving. A team holding steady at twenty-five is stable. Report both the mean and the worst case, because the outlier that sat open for eight months is the one an auditor will find.

Percentage of findings past SLA. This is your single best health indicator and the number to put in front of leadership. If it is climbing, either your SLAs are wrong or your remediation capacity is insufficient, and both are decisions for someone above the security team.

Recurrence rate. Findings that come back after being closed usually mean the fix was applied to a running instance rather than to the image or the template it was built from. A high recurrence rate points at a build pipeline problem, not a patching problem, and fixing it upstream removes the work permanently.

Coverage. Assets scanned in the last cycle divided by assets known to exist. Anything under ninety percent needs an explanation ready before somebody asks for one.

Cost drivers people underestimate

Tool licensing is the visible cost and usually the smaller one. The larger cost is engineering time spent on remediation, and it is rarely budgeted. A first triage pass on a neglected estate can generate several hundred hours of legitimate remediation work, and that work competes directly with the product roadmap. Teams that do not have this conversation with leadership before starting end up with a scanner producing findings nobody has capacity to fix, which is a worse audit position than having had no scanner, because now there is a documented record of known issues left open.

The second underestimated cost is triage labour. Even a well-tuned program needs somebody making judgment calls weekly on which findings matter in your specific environment. Budget a few hours a week, and expect more in the months following any major infrastructure change.

The third is the retest and evidence overhead if this feeds a certification. Producing an audit-ready evidence trail from a program that was not designed to produce one costs weeks of archaeology. Designing for it from the start costs almost nothing extra. This is one of the reasons we push clients to store scan history, triage rationale, and closure evidence in one place from the first cycle, which is what the free traztech Workspace exists to hold.

When it goes wrong

The most common collapse pattern is the backlog that becomes unmanageable. Six months in, there are 400 open mediums nobody will ever fix, the team has stopped looking at the queue, and the program is dead while still generating reports. The recovery is to declare a cutoff: risk-accept the aged low and medium findings in a single documented batch with a named approver, reset the queue, and enforce SLAs strictly from that date forward. Auditors accept this far more readily than teams expect, because a deliberate, approved decision is exactly the behaviour the control is meant to demonstrate. Quietly ignoring the backlog is what fails.

The second pattern is the tool that nobody trusts. If your scanner produces false positives that engineers waste days chasing, they will start dismissing real findings alongside the noise. Fix this by validating findings before they reach a developer's queue. It is better for a security person to spend twenty minutes confirming exploitability than for three engineers to spend a day each on something that was never reachable.

The third is loss of ownership after a departure. Programs built around one person's knowledge of the tooling do not survive that person leaving. Write down the scan schedule, the credential locations, the triage criteria, and the escalation path, and test whether somebody else can run a cycle from the documentation alone.

When you should not hire us for this

Vulnerability management is genuinely buildable in-house, and there are cases where paying anyone to help is a poor use of money.

If you run a small estate on a single cloud provider with fewer than thirty assets, the native tooling your provider already includes will cover most of what you need, and the honest first move is to turn it on and act on what it tells you. That costs nothing and will occupy you productively for a month.

If your real problem is that you have no patching discipline, no asset owner, and no capacity to fix anything, adding a scanner or a consultant produces a longer list of things you are not doing. Fix the operating basics first. A monthly patch window that actually happens beats a sophisticated program that generates unactioned reports.

If a customer questionnaire is the only driver and the question is narrowly about whether you scan, answer it honestly, describe your cadence, and move on. Standing up a full program to answer one question is over-buying.

Where an outside team earns its fee is the harder middle: a messy multi-account estate, a certification deadline, and no internal person who has run triage before. If that is where you are, our security work and ongoing retainer options are built around it, and a conversation will tell you quickly whether the answer is us or a weekend with your cloud console.