Work / Case study
Building a vulnerability management program from nothing
The starting point was an organization with no policy and no scanning. The end point was a signed policy, a server team that agreed to it, and one full round of remediation that cut findings by 80%.
- Role
- Analyst, end to end
- Platform
- Tenable on Azure VMs
- Scripting
- PowerShell and Bash
- Result
- 30 findings down to 6
The problem
A scanner is the easy part of vulnerability management. The hard part is getting the people who own the servers to trust the process, because they carry the risk when a fix breaks something.
So this project treats the program as two tracks that run together: the policy and the people, then the scans and the scripts.
Policy and buy-in
- Drafted the policy. It set scope, responsibilities, and remediation timelines.
- Took it to the server team. They pushed back on a 48-hour window for critical findings, so we agreed on one week.
- Got sign-off from upper management on the revised policy.
- Agreed how to scan. One server first, watch the resource impact, and use just-in-time Active Directory credentials.
Scan and prioritize
I provisioned an intentionally insecure Windows Server, ran an authenticated scan, and ranked the findings by impact and by how easy each was to fix:
- Remove outdated third-party software (Wireshark)
- Disable insecure protocols and cipher suites
- Take the guest account out of the Administrators group
- Apply Windows OS updates
The protocol and cipher change went through a mock Change Control Board with a rollback script and a tiered rollout.
Four rounds of remediation
Each round followed the same loop: run the script, rescan, confirm the finding is gone.
| Round | Change | How |
|---|---|---|
| 1 | Removed outdated Wireshark | PowerShell |
| 2 | Disabled insecure protocols and cipher suites | PowerShell |
| 3 | Removed guest from Administrators | PowerShell |
| 4 | Re-enabled Windows Update and patched fully | Windows Update |
Results
first remediation cycle
- total findings
- 30 → 6
- critical
- -100%
- high
- -90%
- medium
- -76%
Critical findings reached zero by the second scan. In a production environment, asset criticality would also shape the order of work.
What comes next
After the first cycle the program moves to maintenance: scheduled scans, ongoing patching, periodic policy reviews, internal audits, and regular updates to stakeholders.
What I took from it
The numbers came from the scripts, but the scripts only ran because the server team agreed to the plan. Rapport, transparency, and a timeline people can meet matter as much as the scanner.