07 Vulnerability Management: HITRUST domain requirements

Why 07 Vulnerability Management is the domain that trips up i1 and r2 assessments

If you are preparing an e1, i1 or r2 and want to know where assessments most often stumble, 07 Vulnerability Management is one of the domains to plan for early. HITRUST's 2025 Trust Report names it as the lowest scoring domain for i1 validated assessments in 2024 and a close second for r2. The domain covers how you find, prioritize, patch and remediate weaknesses in the applications, libraries, containers and infrastructure that fall inside your assessed scope. It is one of 19 assessment domains HITRUST uses to group requirement statements and report scores, so a weak result here is visible on its own line in the report, not buried in an overall number.

The underlying risk is simple to describe. A known flaw in a web framework, an unpatched operating system package or an exposed container image gives an attacker a documented path into systems that handle regulated data, and the flaw is only useful to you if someone finds it before the attacker does. Assessors look for evidence that scanning runs on a defined schedule across the in-scope inventory, that findings are triaged and assigned, and that remediation happens within timelines your own policy sets. Ask your team to confirm three things now: which assets are in scope, which tool produces the findings for each asset type, and who signs off on accepted risk when a patch cannot be applied.

Two scoring rules from the Assessment Handbook shape how much margin you have. The e1 and i1 require the core requirement statements in each domain to average at least 83, while the r2 requires each domain to average at least 62 across all its requirement statements. Because the r2 threshold works on the domain average, a few weak statements can be offset by stronger ones, but an i1 has less room to absorb a gap. Read the current scoring rules in the HITRUST Assessment Handbook before you size remediation work, and confirm with your assessor how they will count your statements.

Which systems, code and teams fall inside vulnerability management scope

Vulnerability management scope in a HITRUST assessment follows the assessed environment, not the whole company. The decisions below determine which assets must be scanned, patched and evidenced, and which can be inherited or excluded, so settle them before readiness work starts.

Applications and APIs in scope

Every customer-facing or internal application that stores, processes or transmits in-scope data falls under the domain, including the APIs they expose. Testing evidence must cover the same endpoints the assessor sees in the system description. Confirm the application inventory matches the assessed boundary before scanning starts, because a missing API is the most common gap a reviewer finds late.

Third-party and open-source libraries

Libraries, frameworks and packages compiled into in-scope applications create vulnerabilities your team did not write but must still track. Maintain a software bill of materials per release and record which versions are deployed. Ask whether dependency findings are triaged with the same workflow as scanner results, since secure coding failures appeared among common corrective action plans in 2024.

Container images and build pipelines

Container images carry operating system packages and runtime libraries that drift between builds. Scope covers base images, the registries that store them and the pipeline steps that rebuild them. Check whether images are rescanned after rebuilds and whether running containers are compared with the image digests that were approved.

Cloud and on-premises infrastructure

Virtual machines, managed databases, load balancers and hypervisors in the assessed environment all need authenticated scanning and patch records. Hybrid estates often leave on-premises systems outside the scanner's reach. Map every subnet, account and region to a named owner so the scan schedule covers the whole boundary rather than the systems that are easiest to reach.

Endpoints that reach the environment

Laptops, workstations and servers that can connect to in-scope systems belong in scope even when they are not hosting data themselves. Confirm which device populations administrators and developers use, and whether each one reports software inventory to a central tool. Endpoint scope overlaps with 02 Endpoint Protection, so align the device list between the two domains.

AI security requirements

Pursuing the AI security certification adds AI security requirement statements to this domain. These cover AI components that sit inside the assessed environment, such as model-serving infrastructure and agent tooling, and the software they depend on. Confirm with your assessor which AI components are in the boundary before you assume the additions apply to your environment.

Inherited components and the assessed boundary

Patching of a cloud provider's physical hosts or managed platform layers may be inherited from that provider's own HITRUST results, rather than tested again. Document each inherited component, the provider's scope statement and the responsibility split, and keep your own patch evidence for everything you control. Ambiguity at the boundary is where scope disputes usually start.

How a HITRUST assessor tests vulnerability management

This table walks through the test steps an Authorized HITRUST External Assessor typically follows for the 07 Vulnerability Management domain, the evidence each step asks for, and where findings usually arise. Read it as a preparation checklist: each row is something the organization should be able to show before fieldwork starts.

Test step	What the assessor checks	Evidence requested	Where findings usually arise
Procedure review	Whether a written scanning and patching procedure exists, assigns owners and sets remediation expectations by severity	Approved vulnerability management procedure, scan schedule, roles and approval records	Procedure exists but is not followed, or ownership is unclear between platform and application teams
Asset coverage	Whether scans reach every in-scope asset, including servers, containers, libraries and cloud resources	Current in-scope asset inventory compared with scanner target lists and scan coverage reports	Assets in the inventory that no scanner targets, or scans that silently skip hosts
Scan result sampling	Whether scans run as scheduled and results are reviewed by a named person	Sample of scan reports across the assessment period with review sign-off	Gaps in the period, reports never reviewed, or results without a clear disposition
Remediation sampling	Whether findings are triaged, assigned, fixed or formally accepted within the defined timeframes	Sample of remediation tickets linked to scan findings, with closure evidence and retest results	Tickets closed without retest, or findings aged beyond the organization's own deadlines
Patch verification	Whether operating system and application patches are applied and confirmed on in-scope systems	Patch deployment reports, change records and post-patch scan results for sampled systems	Patch records that do not match what is running on the host
Secure coding guidance	Whether written secure coding standards exist, cover common flaws such as injection and cross-site scripting, and are applied in development	Coding standard, training records, code review or static analysis results and sampled remediation of flaws	Guidance is generic or unenforced; this requirement was a top corrective action plan in 2024
Exception verification	Whether each unremediated vulnerability has a documented risk acceptance, owner, compensating control and expiry	Exception register with approvals, compensating control descriptions and review dates	Exceptions with no expiry, no approver, or no compensating control
AI security requirements (if in scope)	Whether AI-related requirements added by the AI security certification are covered in this domain	Evidence for each AI security requirement statement mapped to this domain	Requirements omitted from scope because the AI security certification was not considered at scoping
Assessor independence	That only an Authorized HITRUST External Assessor performs the validated assessment and HITRUST performs quality assurance before reports issue	Confirm the assessor's authorization on HITRUST's assessor directory before engagement	Consultants or readiness partners cannot issue the validated result; they prepare evidence only

How to implement vulnerability management before an assessment

This sequence turns vulnerability management from a scanning habit into a documented, repeatable process that an assessor can test end to end. Each step produces an artifact that becomes evidence for the 07 Vulnerability Management domain.

Build the asset and software inventory
Start by listing every host, container image, library and cloud resource inside the assessed scope, with its owner and the software installed on it. The organization owns this list, and an implementation partner can help build collection through agents or existing configuration tooling. The step is done when the inventory reconciles with the system boundary in the scope statement and an owner signs off on every line. Expect the inventory to be the first thing an assessor asks to see.
Set scanning cadence and tooling per asset type
Assign a scanning method to each asset class from the inventory, such as host-based software inventory matching for endpoints, network scanning for servers and dependency analysis for application libraries and container images. Record the frequency, the tool, the credentials used and who reviews the output. Open-source options such as Wazuh, Fleet and Greenbone Community Edition can cover different asset types, but the team should confirm each tool's coverage against its own environment. The output is a scanning standard that names the tool, the schedule and the reviewer for every asset class.
Define severity-based remediation timelines
Agree on a severity scale, map each level to a remediation deadline, and write the rules for escalation when a deadline is missed. The organization sets these timelines itself, so the team should choose values that match its own risk appetite and confirm them with leadership and, where contracts require it, with customers. The output is an approved remediation standard and a tracking method, such as tickets linked to scanner findings, that shows when each finding was raised, assigned and closed.
Add secure coding guidelines and code scanning to the pipeline
Publish secure coding guidelines that address common flaws such as injection and cross-site scripting, then wire static analysis and dependency checks into the build pipeline so that findings are visible before release. HITRUST's 2025 Trust Report names a secure coding requirement in this domain among the most frequent corrective action plans in 2024, so this step deserves early attention. The step is complete when the guidelines are approved, developers have been trained on them, and pipeline runs produce stored results that link to tracked findings.
Run a dry-run scan cycle
Execute one full cycle from scan through triage, ticketing, remediation and closure across a representative part of the scope, before the assessor's fieldwork window opens. Track how long each step takes, where findings were duplicated or lost, and which owners missed their deadlines. Use the results to correct the inventory, tool configuration and workflow. The output is a dry-run report listing the findings, the actions taken and the process changes made, which shows the assessor that the process has been operated, not only written.
Document exceptions and risk acceptance
Some findings cannot be fixed within the timeline, for example because a vendor has not released a patch or a legacy system must stay in service. For each such case, record the affected asset, the reason, compensating controls, the approver and a review date. Route these decisions through the organization's formal risk process rather than leaving them in tickets. The step is done when every open exception has a named approver and an entry in the risk register, which is the evidence an assessor will sample when testing whether exceptions are controlled.

Which open-source tools produce vulnerability evidence

Host-based tools answer the question of which software is installed on each monitored system and whether any of it has known vulnerabilities. Wazuh and Fleet take different approaches to this job. Wazuh runs agents on monitored endpoints that collect a software inventory, then correlates that inventory with a vulnerability repository to identify weaknesses in the operating system and installed applications. Fleet enrolls hosts and matches installed software against published vulnerability sources.

Wazuh inventory correlation: Each agent reports its software inventory, and the manager matches it against the Wazuh CTI vulnerability repository or a locally hosted offline copy.
Offline operation: The offline copy option matters for air-gapped or restricted networks, so confirm how the copy is updated and who approves updates.
Fleet source matching: Fleet matches installed software against sources including the NVD, OVAL definitions, Microsoft security bulletins, Amazon Linux advisories and OSV.
License caveat: Wazuh is licensed under GPL-2.0-only, and Fleet is licensed under MIT. Legal review should confirm that the licence terms fit how the organization distributes or modifies the software.
Coverage gaps: Host tools see only what they are deployed on, so confirm that every in-scope endpoint, server and container host is enrolled.

Confirm that inventory records, match results and remediation tickets for each in-scope host can be exported for the assessor to sample.

Evidence that passes a vulnerability management review

Assessors test 07 Vulnerability Management by sampling records that show scanning, remediation and exceptions actually happened over time. The cards below cover the artifacts most often pulled from the sample, and each one needs a recurring routine so it reflects current operations rather than a one-time export.

Scan configuration and schedules

Export the scan task definitions, target lists, credentials used for authenticated scans, and the schedule each task runs on. An assessor compares the schedule with the scan dates in the reports to see whether scanning ran as documented. Keep the configuration under change control, so each edit leaves a dated record. Review it at least once per cycle to confirm new in-scope systems were added as targets.

Dated scan reports

Keep the raw output of each authenticated and unauthenticated scan with its start and end date, the target set, and the scanner version and feed date. Assessors look for gaps between runs and for reports that cover only part of the environment. Store reports in a location with retention rules, and generate a dated summary each cycle so no period is missing from the sample.

Asset inventory linked to scan coverage

Maintain an inventory of in-scope hosts, containers, images and applications, and tag each asset with the scan task that covers it. A scanner report alone does not prove that every in-scope system was tested. Reconcile the inventory against scan targets at each review, and record unscanned assets with a reason and an owner.

Remediation tickets with closure proof

For each confirmed finding, keep a ticket that records severity, owner, due date, the fix or compensating step, and a rescan result showing the finding cleared. Assessors often trace a sampled finding from the scan report to the ticket and then to a passing rescan. Tickets that close without a verification scan are a common source of exceptions.

Risk acceptance records

When a finding is not fixed by its due date, record who accepted the risk, why, the compensating controls, and the date the decision must be reviewed. Assessors check that acceptance sits with a named authority rather than the team that owns the system. Set a review trigger so accepted risks return to the queue when the system or exposure changes.

Secure coding standards and pipeline scan results

Keep the written secure coding guideline that addresses common flaws such as injection and cross-site scripting, along with the build pipeline configuration and the results of static and dependency scans for each release. HITRUST's 2025 Trust Report names a secure coding requirement among the fourth most frequent corrective action plans in 2024, so this artifact deserves early attention. Show that failed scans block or are triaged before release.

What meeting the vulnerability management requirement costs

This table breaks the cost of meeting the 07 Vulnerability Management domain into components, showing who is paid, whether each cost is one-time or recurring, and what moves it up or down. Use it to shape a request for quote and to see where open-source scanners remove license spend. No single figure applies, because cost follows the size and shape of the assessed environment.

Cost component	Who is paid	One-time or recurring	What drives it
Scanning tools and licenses	Software vendor or none if open source	Recurring for commercial scanners, near zero license cost for self-hosted open-source tools	Number of hosts, containers and applications in scope; choice of commercial or open-source scanner
Engineering time to deploy and tune scanners	Internal platform team or implementation partner	One-time, with periodic retuning	Number of asset types, credentialed scan needs, network segments and integration with ticketing
Triage, deduplication and remediation labor	Internal security, operations and development teams	Recurring	Scan frequency, false positive rate, patch cadence and how many findings reach remediation
Secure coding and application testing	Internal developers, or a testing firm for external work	Recurring for tooling and reviews, periodic for external tests	Application count, release frequency and whether injection and cross-site scripting checks run in pipelines
Evidence upkeep	Internal compliance or security staff	Recurring	Retention of scan results, remediation tickets and exception records across the assessment period
Readiness review	Independent consultant or implementation partner, if engaged	One-time before the validated assessment	Maturity of current scanning, gaps in scope and number of domains reviewed alongside this one
Assessor fieldwork time	Authorized HITRUST External Assessor organization	Per validated assessment	Assessment type (e1, i1 or r2), sample sizes and the fieldwork window of up to 90 days

Where organizations usually fall short on vulnerability management

Most vulnerability management findings in HITRUST assessments trace back to a small set of process gaps rather than missing tools. The cards below pair each recurring gap with the step that closes it, so the evidence exists before an assessor asks for it.

Incomplete asset inventory

Scans only find what they are pointed at. If the inventory omits cloud workloads, containers, build servers or endpoints that reach the in-scope environment, the scope of 07 Vulnerability Management is silently smaller than the assessed boundary. Reconcile scanner targets against your asset register and cloud account lists each cycle, and confirm that every in-scope host reports a software inventory. Wazuh and Fleet both depend on agents or enrolled hosts, so unenrolled systems stay invisible to them.

Scanning without remediation deadlines

A scan that runs weekly but has no agreed fix window produces a backlog, not a control. Assessors look for defined timeframes by severity, evidence that findings were assigned, and proof that overdue items were escalated. Ask the organization to document remediation targets by severity and owner, then confirm that ticket data from the scanner or DefectDojo shows open age against those targets. Many teams discover at assessment time that the targets were never written down.

Unreviewed library and container findings

Vulnerable packages in application dependencies and base container images are often reported by scanners but never triaged, because no team owns them. The result is a long list of unreviewed alerts that auditors read as a missing process. Assign each image and repository an owner, deduplicate findings across tools, and record a disposition for each one: fixed, accepted with reason, or not applicable. Fleet matches installed software against sources such as the NVD and OSV, so the same package can appear under several identifiers.

Secure coding guidance missing from the pipeline

The fourth most frequent corrective action plan in 2024 concerned secure coding guidelines that prevent common flaws such as injection and cross-site scripting. Written guidance on a wiki does not satisfy the requirement on its own. Connect the guidelines to code review checklists, static analysis gates and developer training, and keep records showing that teams followed them. Ask engineering leads to show where the rules are enforced in the build pipeline, not only where they are published.

Exceptions without owners or expiry dates

Accepted risks and deferred patches are a normal part of operations, but an exception with no named owner, business justification or expiry date becomes permanent. Assessors test whether exceptions are approved by someone with authority, reviewed on a schedule and closed when the condition changes. Maintain a register that records each exception, its approver, the compensating measure and the review or expiry date. Check the register against open findings in the scanner to find exceptions that have quietly outlived their reason.

Evidence gathered only at audit time

When teams rebuild scan history, remediation tickets and approvals just before fieldwork, the gaps between those records are visible and the assessor must test each period. Continuous evidence removes that pressure. Export scan results, ticket closures and exception approvals on a fixed schedule into a retained evidence store, and confirm that the records can be reproduced for any date in the assessment window. The fieldwork window for e1, i1 and r2 is at most 90 days, so evidence must cover the full period, not only the final weeks.

Who does what: your team, a partner and the assessor

Your organization owns the vulnerability management program in the assessed scope. HITRUST scores the controls as operated by you, so the decisions that matter most stay in-house: which assets are in scope, how often scanning runs, what severity triggers action, and who accepts risk when a finding cannot be fixed in time. A partner can recommend thresholds, but the policy must be approved and followed by your staff.

Scope and asset ownership: Maintain the inventory of hosts, containers, libraries and applications that the assessment covers, and name an owner for each.
Remediation decisions: Set remediation timelines by severity and assign owners to every finding that stays open.
Risk acceptance: Document who may accept residual risk, the conditions, the review date and the compensating controls.
Operating records: Keep scan schedules, ticket histories, exception approvals and patch records that show the program runs between assessments.
Governance: Report vulnerability status to the people who own the risk, so the program has management attention.

Before engaging anyone, confirm that your policy names the owner of each decision above, because an assessor will ask for that ownership first.

Questions buyers ask about vulnerability management for HITRUST

How much effort does vulnerability management take compared with other HITRUST domains?

Vulnerability Management is one of the harder domains to score well in, so it usually takes more sustained effort than its size suggests. The 2025 HITRUST Trust Report names it as the lowest scoring domain for i1 validated assessments in 2024 and a close second for r2. Effort rises when scanning coverage is incomplete, when patch timelines are not written down, or when findings are tracked in spreadsheets rather than a single system of record. Ask your assessor and readiness partner which requirement statements in this domain your environment touches before you estimate work, since the answer depends on your scope and on any inheritance you already have.

Can our own team run vulnerability management for HITRUST in-house?

Yes, many organizations run it in-house, but the team needs clear ownership, a defined scanning cadence, documented remediation timelines and evidence that a person reviews results. The organization owns its controls. An implementation partner can help set up scanners, ticketing and reporting, and an independent Authorized HITRUST External Assessor performs the validated assessment and HITRUST performs quality assurance before reports are issued. Decide early which parts your staff will own day to day, such as triage and patch approval, and which parts you want an outside party to design or test, such as scanner deployment or a pre-assessment review.

What does this domain need from engineering and security staff?

Security staff own the policy, risk acceptance, exception handling and the review of scan results. Engineering staff own the patching of operating systems, libraries, containers and applications, and they need to fix findings within the timelines the organization has written down. Typical work includes:

Maintaining an inventory of in-scope hosts, images and applications
Running authenticated scans on a defined schedule
Triaging findings, assigning owners and tracking remediation to closure
Keeping secure coding guidelines current, since a common corrective action plan in 2024 concerned coding flaws such as injection and cross-site scripting
Retaining records that show each finding's status over time

How long does it take to get vulnerability management evidence ready for fieldwork?

The assessor's validated fieldwork window is at most 90 days for e1, i1 and r2 assessments, according to the HITRUST Assessment Handbook v1.1. The evidence must already exist before that window opens, because assessors test whether controls operated over time, not only whether they were designed. Preparation time depends on how mature your scanning and remediation records are, how many systems are in scope and whether you need an incubation period to build a track record. Confirm with your assessor which evidence periods and sampling rules apply to your assessment type before you set a date.

Do AI security requirements add work to vulnerability management?

They can. HITRUST's AI Security Assessment help page places AI security requirement statements in this domain, so an e1, i1 or r2 with the AI security certification adds requirements here. Confirm the exact statements that apply to your scope with HITRUST's current materials and your assessor, because the CSF version and the AI security add-on determine which requirements are included. Plan to bring AI components, such as model-serving containers and the libraries they depend on, into the same scanning and remediation process as other in-scope software.

Are open-source vulnerability tools acceptable evidence for HITRUST?

Open-source tools can produce the scan results, inventories and tracking records that support this domain, but the tool does not make you compliant. Assessors look at whether the tool covers the in-scope assets, whether it runs on a schedule, whether findings are reviewed and remediated, and whether the records can be exported and tied to owners and dates. Tools such as Wazuh, Fleet, DefectDojo and Greenbone Community Edition each cover different parts of the workflow, including endpoint vulnerability detection, software inventory, finding deduplication and network scanning. Confirm with your assessor which evidence formats they accept and how they want the tool configured, since acceptance is their decision.

What should we ask for in a quote for vulnerability management work?

DeployOpen does not publish a price list, and a quote follows from a written scope. Ask for the in-scope assets and environments, the tools to be deployed or integrated, the evidence to be produced and in what format, the handover of documentation, and which activities are one-time versus recurring. Also ask what is excluded, such as the assessor's fees, remediation work performed by your own engineers, and ongoing scanning or retainer support. Request deliverables and timelines in writing before work starts, and ask how changes to scope will be priced.

How DeployOpen scopes vulnerability management work

DeployOpen starts this domain with a fixed-scope written agreement that lists which assets, applications, libraries, container images and infrastructure components the vulnerability management work covers, which scanning and consolidation tools will be deployed, and which findings sources feed the process. The agreement also names the client's owners for patching decisions and exception approvals. Before any work begins, the client should confirm the boundary of the HITRUST assessment scope, because a host, image or repository left out of that boundary can still create scoring gaps if it touches in-scope data. Ask for the asset inventory the scope is built from and check that it covers operating systems, installed applications, third-party libraries and cloud workloads.

Within that scope, DeployOpen deploys self-hosted tooling inside the client's own cloud accounts, data centers or air-gapped networks. Typical components include Greenbone Community Edition for network and host vulnerability scanning, Wazuh for vulnerability detection on monitored endpoints, Fleet for software inventory matching on enrolled hosts, and DefectDojo to import findings from the other tools, deduplicate them and track remediation to closure. Each choice depends on the environment. Confirm the scan schedules, credentialed scan accounts, offline vulnerability feed handling for restricted networks, and who in the client organization receives and triages findings. Scan results and feed data stay under the client's control throughout.

DeployOpen prepares the evidence an external assessor will sample: scan configurations and schedules, scan reports, the consolidated findings register with severity and ownership, remediation tickets, exception approvals with compensating controls, and records showing that secure coding requirements were applied to in-scope software. Where a requirement statement needs a judgment call, such as whether a given control is applicable or how a finding was accepted, DeployOpen documents the reasoning for the client to review. DeployOpen does not issue reports or certifications. Only an Authorized HITRUST External Assessor can perform the validated assessment, and HITRUST performs quality assurance before a report is issued. Clients should confirm assessor selection separately from this implementation work.

How DeployOpen prepares vulnerability management evidence

DeployOpen plans, implements and documents self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks. For 07 Vulnerability Management, we prepare the scanning, tracking and remediation records that your organization owns and that an independent HITRUST External Assessor reviews. We do not issue reports or certifications.

How we scope

Agree in writing which applications, libraries, containers and infrastructure fall inside the assessed environment.
Record which scanning sources, asset inventories and remediation timelines your organization will own and operate.
Confirm with your assessor which requirement statements in this domain apply, including any AI security statements if that add-on is in scope.

How we build

Deploy vulnerability detection tools such as Wazuh, Fleet, Greenbone Community Edition or DefectDojo in your environment.
Connect host inventories and scan results so findings flow into one tracked place with consistent deduplication.
Test scan coverage against a sample of in-scope assets and document gaps before the assessor arrives.

How we hand over

Deliver runbooks covering scan schedules, triage rules, severity handling and remediation ownership for your team.
Provide evidence packs with scan configurations, scan history, finding records and remediation tickets, mapped to the domain.
Document open items and known limitations so your team can explain them to the assessor without rework.

How we support

Ongoing support, upgrades and continuous testing are available as a retainer, agreed in a separate written scope.
Review scan coverage and finding trends with your team before each assessment window or significant system change.
Confirm the scope of any support with your written agreement, including which tools and environments it covers.