What does vulnerability management look like in a regulated industry?

In a regulated industry, vulnerability management means four things you can show an examiner: a current inventory of what you run, remediation timelines based on real risk, evidence that you met them, and a recorded decision for every exception. Finding vulnerabilities is the easy part. Proving the process is the work.

Why is regulated vulnerability management different?

An unregulated team can decide by feel which bugs to fix first. A regulated team must explain the choice, and keep the explanation.

NIST SP 800-40 Rev. 4 describes enterprise patch management as identifying, prioritizing, acquiring, installing and verifying patches and updates throughout an organization. It frames patching as preventive maintenance, a cost of doing business, and notes the common divide between business owners and security staff about its value. That divide is where regulated programs stall: nobody has authority to take a system down for a patch.

How do current rules set priority?

US federal civilian agencies now follow CISA's BOD 26-04, published 10 June 2026, which revokes BOD 22-01 and BOD 19-02. It sets remediation urgency from four variables: whether the asset is publicly exposed, whether the vulnerability is in the Known Exploited Vulnerabilities catalog, whether an adversary can automate every step of exploitation, and whether exploitation gives partial or total control.

Two details are worth copying even if you are not a federal agency. First, timelines are dynamic: removing a system from the internet changes its exposure and its deadline. Second, the directive requires agencies to tag assets by organization, environment, exposure and asset type. Prioritization depends on that inventory.

The directive binds agencies, and generally not contractors unless a contract says so. Treat it as a model, and read your own regulator's text.

Is scanning enough?

No. FedRAMP's Vulnerability Detection and Response rules state that detection is not limited to traditional vulnerability scanning. They list assessment, threat intelligence, disclosure channels, bug bounties, penetration testing, incident response, automated control testing and supply chain monitoring as sources. They also say an out-of-date control statement in the security record is itself a vulnerability to be fixed.

For payment environments, PCI SSC publishes resource guidance on vulnerability scans and Approved Scanning Vendors. Utilities under NERC's CIP-013 must address vendor disclosure of known vulnerabilities and verification of vendor patches. The sectors differ, and the pattern repeats: more than one source feeds the process, and vendors are part of it.

What evidence do examiners want?

Expect to produce these without a scramble:

• the inventory with owners and exposure;
• the policy that sets timelines and who may grant exceptions;
• time-stamped records of discovery, decision, fix and verification;
• exception records with a reason, compensating control, approver and expiry;
• metrics on overdue items, reviewed by someone senior.

A spreadsheet can work at small scale. At larger scale, keep records where they are created, so they are not rebuilt before each audit.

Where does reachability fit?

Not every vulnerable library is a live risk. Reachability analysis asks whether your code can actually call the vulnerable function, which helps order the queue and justify a deferral. It is a prioritization input and does not replace exposure, exploitation and impact data. Record the reasoning when you defer on that basis, and recheck it when code changes.

What to do

1. Build an inventory with asset type, environment, owner and internet exposure.
2. Write a policy with timelines driven by exposure, known exploitation and impact, and name who can approve exceptions.
3. Feed the process from several sources: scanners, advisories, vendor disclosures, testing and incident findings.
4. Track every finding through discovery, decision, fix and verification, with timestamps.
5. Require expiry dates on every accepted risk and review them on a schedule.
6. Add dependency and component data, not only hosts, so software libraries are covered.
7. Report overdue items to senior management monthly.
8. Run a mock examination once a year and fix the gaps it shows.

Quick check

Sources

• NIST, SP 800-40 Rev. 4, Guide to Enterprise Patch Management Planning
• CISA, BOD 26-04: Prioritizing Security Updates Based on Risk
• CISA, BOD 22-01 (revoked)
• FedRAMP, Vulnerability Detection and Response
• PCI SSC Blog, PCI DSS v4.x Resource Hub
• NERC, CIP-013-2

Last reviewed: 18 October 2026.