Vulnerability management RFP questions for vendors

Vulnerability management RFP questions to ask before you select a scanner or partner

Before you select a scanner or a managed vulnerability provider, ask every bidder the same written questions and score their answers against the same criteria. The questions that matter most cover asset coverage and authenticated scanning, how false positives and duplicates are handled, which feeds and databases the tools depend on, how scans are kept safe in production, how remediation is tracked, and what evidence reaches auditors and engineering teams. Regulated organizations often run a mix of commercial scanners and open-source tools such as Greenbone, Trivy, Dependency-Track and DefectDojo, so the evaluation has to cover how those pieces connect, not only the scanner itself.

Send one written scope to every bidder, covering the asset inventory, network zones, cloud accounts, container registries, and any systems that cannot be scanned aggressively. Require answers tied to your own environment rather than generic product claims, and ask each bidder to name the feed or database each finding depends on and whether it is current in your network. Ask for a reference architecture showing where scanners, the tracking tool and the reporting layer run, and request sample reports before award. A sample report that a bidder cannot produce from your scope is a warning sign, whether the bidder is a vendor, a managed provider or an implementation partner such as DeployOpen, a Chainscore Labs company that implements open-source platforms.

Score each answer against the same criteria: coverage, false positive handling, feed and licensing terms, scan safety, remediation workflow, reporting and integration with engineering. Confirm licensing for every component, including which features need a paid feed or edition, because those terms change cost and evidence. Record the answers in the procurement file so that the scope, the responses and the award decision can be reviewed later by your own auditors.

What to ask about coverage, feeds, scan safety, workflow and reporting

How do you discover and cover hosts, containers, dependencies and cloud assets?

A good provider names each asset class, the discovery method for it, and the gap that remains. Ask how hosts are found (network sweeps, cloud account APIs, agent check-ins), how container images are inventoried from registries and running clusters, and how software dependencies are read from SBOMs or lockfiles. Trivy scans container images, filesystems, remote Git repositories, virtual machine images and Kubernetes, so ask which of those targets are in scope and which are handled by a separate process. Ask also how unmanaged or shadow assets are detected and who owns the reconciliation between the asset inventory and the scanner's target list. Request a written list of asset classes with the owner and tool for each.

Which scans run authenticated, and how are scanner credentials stored and rotated?

Authenticated scans log in to hosts and read installed packages, which finds far more than unauthenticated port probing. Ask which systems get credentialed checks, which run unauthenticated only, and why. Ask where credentials are kept, who can read them, how they are rotated, and whether the scanner account is limited to read-only actions. For Greenbone, the Notus Scanner compares installed software on a host against known vulnerable versions during every scan, so ask whether that comparison runs only when credentials are present. A strong answer documents each credential type, its vault location and its access log.

How are false positives handled, tuned and documented?

Ask for the written process that moves a finding from suspected to accepted, dismissed or risk-accepted, and who signs each step. For Greenbone results, ask how version-based Notus detections are checked against the installed package, and how overrides are recorded. For Trivy, ask which ignore file or VEX-style statement is used, who approves it, and whether it expires. For DefectDojo, ask how the deduplication hashcode is set for each parser, for example title and severity for Tenable reports or title, CWE and severity for ZAP reports, and whether the provider has tested that those fields do not merge distinct issues. Every suppression should carry a reason, an approver and a review date.

Does the scope include the Greenbone Community Feed or the Enterprise Feed?

The answer decides which vulnerability tests you receive. Greenbone describes the Community Feed as its free feed and the Greenbone Enterprise Feed as the full-featured commercial feed, and notes that Community Feed releases now exclude vulnerability tests for enterprise products. Ask the provider which feed is in the statement of work, which product families are covered by the tests in that feed, and what is missing for your estate. Ask whether the license for the Enterprise Feed is quoted separately and who holds it. Also ask how feed updates are scheduled and who checks that the feed version is current before each scan cycle.

How are Trivy databases and Greenbone data updated in air-gapped or mirrored networks?

Ask how each data set reaches the isolated network, how often, and by what controlled media or transfer path. Trivy's databases (trivy-db, trivy-java-db and trivy-checks) are published as OCI images that can be mirrored to an internal registry and selected with the --db-repository, --java-db-repository and --checks-bundle-repository options, and the documentation warns that mirrors must be kept updated. For offline hosts, the documented route is downloading the trivy-db or trivy-java-db archive on a connected machine and copying it into the cache db directory. Ask who runs the transfer, how the file is checked before import, and how a stale database is detected and reported. Greenbone feed data is loaded by data containers into volumes at startup, so ask how that data is staged for the offline deployment.

How do you keep scans safe on production and fragile systems?

Ask for the scan profiles, the rate limits, and the change windows that apply to each class of system. Good answers separate fragile devices, production databases and internet-facing hosts from general servers, and state which checks are excluded for them. Ask who approves a scan profile and who is on call if a scan causes a service impact. For Greenbone, ask how scan concurrency and target lists are set, and whether the Community Containers are sized for the scan load: the documentation lists at least 2 CPU cores, 4 GB of RAM and 20 GB of storage as the minimum, with 4 cores, 8 GB and 60 GB recommended. Request a written stop procedure and a record of past scan-related incidents.

How are remediation owners, SLAs and exception approvals set and enforced?

A good provider describes the ownership model before the first scan: which team owns each asset, who triages findings, and who approves deferrals. Ask for the severity-based timeframes you will use, how they are set and by whom, and how a finding is escalated when its owner misses one. Ask how exceptions are requested, how long they last, what compensating control is required, and who signs off. DefectDojo can track SLAs by severity and report on overdue items, so ask whether that tracking is in the proposed design and who maintains the configuration. Confirm that the timeframes come from your own policy, not from the provider's default.

What reports do auditors receive, and how do findings reach engineering through tickets?

Ask for sample reports before signing, covering scan coverage, scan dates, open and closed findings by age, exceptions with approvals, and rescan evidence. Confirm the export formats: Trivy can produce table, JSON, SARIF, template, SBOM and GitHub dependency snapshot output, and DefectDojo imports Greenbone reports in CSV or XML. Ask how each finding is pushed to the engineering ticketing system, which fields are mapped, whether duplicate tickets are prevented, and how closure is verified by a rescan rather than a comment. The provider should also state which records it keeps, for how long, and where they are stored.

How question sets differ for scanner vendors, managed providers and self-hosted builds

A commercial scanner vendor sells a product that your own team or a partner operates. The questions that carry the most weight are about what the subscription actually includes, because feed access, scan engine capacity and reporting modules are often sold separately. Ask which vulnerability tests are included at the tier quoted, and whether any coverage depends on a feed that is licensed apart from the product. Commercial terms also decide how the scanner can be deployed, so ask whether it can run in your network without sending scan data to the vendor.

Feed and coverage terms: Require the feed licensing terms in writing, including update frequency, which product families are covered and what happens to coverage if the subscription lapses.
Deployment and data residency: Confirm where scan results, credentials and metadata are stored, and whether they leave your jurisdiction.
Access model: Ask how scanner accounts, API tokens and vendor support access are created, logged and revoked.
Runbooks and upgrade process: Request the operating runbook, the upgrade procedure and the support escalation path, with the response targets stated in the contract.
Exit terms: Ask how findings, configurations and history can be exported in open formats if you leave.

Check every claim about coverage against a live test on a representative subnet before signing, and confirm the license terms with the vendor's contracts team rather than relying on the sales deck.

Answers that should worry you in a vulnerability management bid

A vulnerability management bid is only as strong as its answers on coverage, method and evidence. The red flags below are the places where vague or missing answers usually hide operational gaps that surface later in audits or incidents. Use them to press for specifics in writing before a scope is agreed.

Coverage claims without an asset list

A provider who says it covers "all systems" without naming the asset inventory, network ranges, cloud accounts and container registries is describing an intention, not a scope. Ask for the asset list, how it is discovered, and which assets are excluded and why. Unknown assets are where unpatched systems usually sit, so ask how new hosts enter the scan schedule.

No answer on authenticated scanning

Unauthenticated scans miss most installed software and patch levels on hosts, so a bid that does not explain how credentials are used is weak on coverage. Ask where scanner credentials are stored, who can read them, how they are rotated, and whether the scanner account has least-privilege access. Vague answers here usually mean findings will be thin and inconsistent.

False positives hidden by suppression

Suppressing findings without a record turns the scanner's output into a judgment the auditor cannot see. Ask how a false positive is confirmed, who approves a suppression, whether the reason and expiry date are stored, and whether suppressions are reviewed when the software changes. A provider that cannot show this trail will struggle to defend its numbers.

Unclear feed sources and update cadence

Ask which vulnerability feed the provider uses, whether it is a community or commercial feed, and how the feed is updated, verified and archived. Community feeds exclude some vulnerability tests for enterprise products, so a missing answer may mean coverage gaps. For air-gapped or restricted networks, also ask how updates reach the scanner and how the date of the last update is recorded.

Scans without profiles or change windows

Running aggressive scans against production systems or fragile devices without scan profiles, throttling and approved change windows can cause outages. Ask which scan profiles are used for legacy and medical or industrial devices, who approves each window, and how the provider stops a scan that affects a service. A bid that treats every target the same should be treated as a risk.

No remediation SLAs or exception approval

Findings without owners, due dates and a defined exception process are a list, not a program. Ask for the remediation timeframes by severity, how a deadline is extended, who approves a risk acceptance, and how overdue items are escalated to management. Request an example of a closed exception record, with its approver and review date, before signing.

Reports an auditor cannot reproduce

A report that cannot be traced to a scan date, scan configuration, feed version and scope will not stand up to sampling by an assessor. Ask whether each report can be regenerated from stored raw results, which scanner and feed versions it cites, and how the provider retains evidence. Also confirm that the provider prepares evidence only, since audit reports and certifications come from independent auditors and certification bodies.

How to score vendor responses consistently

This table lists the criteria to score scanning vendor and managed service answers against, and the evidence that earns full marks on each. Set your own weights before reading responses, and score each answer against the evidence column rather than the vendor's wording. Vendors that answer with documents you can test usually separate themselves from those that answer with claims.

Criterion	What a strong answer covers	Evidence that earns full marks
Asset coverage and discovery	How the vendor finds hosts, containers, cloud accounts and software, and how it reconciles them against your asset inventory	Sample asset discovery export and a written method for handling assets that appear or disappear between scans
False positive handling	How findings are validated, who can mark a finding as not applicable, and how that decision is recorded and reviewed	Sample report showing suppressed findings with reason, approver and review date
Feed and update model	Which vulnerability data sources are used, how often they update, and which features depend on paid feeds or editions	Feed source list, update schedule, and a written statement of which tests or data are excluded in the free tier
Scan safety in production	Scan profiles, rate limits, credentialed versus unauthenticated modes, and how fragile systems are excluded	Documented scan profiles and a change window procedure, plus a runbook for stopping a scan that causes impact
Remediation workflow	How findings become tasks, how severity and exposure set deadlines, and how exceptions and risk acceptances are handled	Workflow diagram, sample ticket with deadline logic, and an exception approval record
Reporting for auditors	Which reports are produced, how scan dates and scope are shown, and how evidence is retained and exported	Sample report covering scope, scan dates, authentication status, and closure history for a finding
Engineering integration	How findings reach development teams through ticketing, API, or pipeline checks, and how duplicates are merged	Live or recorded demo of an API export and ticket creation, with deduplication rules documented
Security of the platform itself	How scanner credentials are stored, who can access results, where data is hosted, and how the platform is patched	Architecture diagram, access control matrix, and documented patch and backup procedure

What drives the cost and effort behind each answer

Ask every bidder to price the same components separately, because the answers to the other RFP questions decide most of the cost. The main lines are scanner licensing or feed subscriptions, the infrastructure that runs scanners and the tracking database, triage and remediation coordination effort, integration with ticketing, and reporting work. Greenbone's Community Feed excludes vulnerability tests for enterprise products, so a bidder who promises full coverage of commercial software should state which feed or edition that depends on and what it costs. Trivy and Greenbone Community carry no license fee, but the bidder still pays for the people who run them. Ask for the scanner hardware sizing in writing. The Greenbone Community Containers need at least 2 CPU cores, 4 GB of RAM and 20 GB of storage, with 4 cores, 8 GB and 60 GB recommended, so the minimum is a floor rather than a sizing decision.

Separate one-time setup from recurring work in the quote. Setup covers asset discovery, authenticated scan credentials, scan profiles, the DefectDojo or Dependency-Track deployment, ticketing integration and the first set of reports. Recurring work covers feed and database updates (Trivy's databases must be kept current in an internal mirror), scan operations, weekly triage of new findings, remediation follow-up and report production. Ask the bidder whether a retainer covers upkeep, upgrades and continuous testing, and what it excludes. DefectDojo's README lists DefectDojo Pro from $100 per month, but the open-source edition uses local accounts and does not include SSO, LDAP or MFA, which are Pro features. Treat that list price as a vendor fact to confirm, not a quote. Any price, fee or duration must come from the bidder's written scope, with its assumptions about asset count, scan frequency and staffing stated, and no figure should be accepted without them.

How to run the RFP from written scope to award

This sequence turns a vague wish for better vulnerability management into a written scope, comparable vendor answers and a fixed-scope contract with clear acceptance criteria. Each step produces a record you can show an auditor and a board.

Write the asset scope and compliance drivers
Before contacting any vendor, the security lead and the asset owners list what must be scanned: hosts, network segments, cloud accounts, container registries, Kubernetes clusters, and software repositories with their dependencies. Mark which assets are in the regulated boundary, which cannot tolerate active scanning, and which sit behind separate networks. Record the compliance drivers that set scan cadence and remediation deadlines, such as your framework, sector regulator or customer contract clauses, and confirm the exact requirement wording with your compliance lead and assessor rather than relying on summaries. The step is done when one signed scope document lists assets, owners, exclusions, scan constraints and the evidence the business needs to produce.
Send identical questions and a sample scan request
Send every bidder the same question set covering coverage, authenticated scanning, false positive handling, feed sources and licensing, scan safety in production, remediation workflow, reporting and how findings reach engineering teams. Attach a sample scan request that names two or three representative targets from the scope, so answers describe the same work. Ask each bidder to state which features depend on a paid feed, edition or subscription, and which parts of the work they would perform versus the client's own staff. Keep a log of all clarifying questions and answers and share them with every bidder. The step is done when each response is in writing, answers the same questions in the same order, and every gap is recorded.
Run a proof of concept on a non-production segment
Ask shortlisted bidders to run the sample scan request against a non-production segment that mirrors the production estate as closely as safety allows. Agree in advance on the scan profile, credentials, time windows, and who approves any scan against fragile systems. Measure what matters: whether authenticated scans succeed, how many results are confirmed versus flagged for review, how duplicates are grouped, whether findings export into your tracking tool, and how the vendor documents a false positive decision. Record scanner load and any service impact observed. The step is done when a written proof of concept report exists for each bidder, with results compared against the criteria set in step one.
Score responses and check references
Build a scoring sheet with weighted criteria taken directly from the scope: coverage, scan safety, feed quality and licensing, remediation workflow, audit reporting and engineering handoff. Have at least two evaluators score each response independently, then reconcile differences in a recorded meeting. Ask each finalist for references from organizations with a similar sector, scale and deployment model, and ask those references specific questions about scan disruption, false positive handling and how the provider supported audits. Verify claims about certifications, partnerships or vendor status through the vendor's own documentation or the issuing body. The step is done when the scoring sheet, reconciliation notes and reference call summaries are filed together.
Contract a fixed-scope deliverable with acceptance criteria
DeployOpen typically works under written, fixed scope, with scope, deliverables and timelines agreed in writing before work starts, and a quote follows from that scope. Whichever partner or vendor you select, convert the winning proposal into a statement of work that lists the assets in scope, the deliverables (for example, configured scanners, tracker integration, report templates, runbooks and training), exclusions, responsibilities on each side, and the change process. Write acceptance criteria that can be tested, such as a successful authenticated scan of named assets, an imported finding set reviewed by your team, and a sample audit report that meets your assessor's stated format. Ask for the quote to show one-time work separately from recurring costs such as feeds, subscriptions, hosting and retainer support. The step is done when the signed statement of work and its acceptance tests are in your contract file.

How much work is an RFP and can we run it ourselves?

The effort behind a vulnerability management RFP is driven by four things: how many assets you have, how many scanners and data sources you already run, whether your ticketing system is in place and integrated, and whether your scanner feeds must be updated across an air-gapped boundary. A small estate with one scanner and an existing ticket queue is a much shorter exercise than a mixed estate with cloud accounts, container registries, operational technology and manual feed transfers. Before you contact any provider, confirm these four inputs in writing, because they determine how many questions in this set are relevant to you and how much evaluation time each answer needs.

Providers will ask you to supply several things before they can scope or quote. Expect to provide current asset lists with owners, a credentials policy that states which accounts may be used for authenticated scans and where secrets are kept, named owners for each remediation SLA, and the compliance drivers that set your reporting requirements, such as the framework your assessor uses. Ask each bidder to state which of these inputs it expects you to own, which it will build, and what it assumes you already have. Gaps in these inputs are the most common reason an evaluation stalls, and they add cost that appears only after contract signature.

You can run the evaluation internally. Use this question set as a scoring sheet, ask each bidder for written answers, and then run a proof of concept on a representative subset of hosts, containers and one application, with a sample of authenticated and unauthenticated results compared against known configurations. Measure false positive handling, deduplication quality and whether findings reach the right engineering queue. Internal teams usually need a named evaluator for scanning, one for ticketing and one for audit reporting. Bring in an implementation partner when the proof of concept shows integration or hardening work that exceeds your staff capacity, and confirm the scope and timeline in writing before work starts.

Evidence to request from every bidder

A bid is only as credible as the records behind it. The six artifacts below let you check coverage, feed handling, change safety, remediation discipline and audit reporting before you compare prices. Ask for them in the RFP response, then sample them against the environment you described.

Asset coverage list

Ask for the scan target list the bidder would use in your environment, showing how hosts, containers, cloud accounts and dependency manifests are discovered and grouped. Check whether authenticated scanning credentials are listed by asset class and who owns each exclusion. Compare the list against your asset inventory and note every gap. Assessors sampling scope in a PCI DSS 11.3 or ISO 27001 review will start from this list, so an incomplete list becomes an audit finding.

Sample findings export

Request an anonymized export from a comparable scan, in the format your ticketing or tracking tool will import, such as CSV, XML, JSON or SARIF. Look for the asset, the plugin or detection identifier, the CVE, the severity source and the first-seen and last-seen dates on each finding. Verify that duplicates are merged and that false positives carry a reason. Without these fields, deduplication and aging reports cannot be trusted.

Feed and update procedure

Ask how vulnerability data reaches the scanner, which feed or database is used, how often it updates, and what happens in a disconnected network. Confirm which feed tier provides which tests, since some enterprise product checks are not in the community feed. Ask for the procedure to mirror and verify data, and who runs it. Feed age at scan time should be recorded in every report, because a stale feed produces false assurance.

Scan profile and change-window runbook

Request the scan profiles the bidder would apply to fragile systems, including timing limits, rate controls, credentialed versus uncredentialed checks and the systems excluded from active probing. Ask for the runbook that defines change windows, who approves a scan, how operations staff are notified and how a scan is stopped mid-run. Compare the profiles against the systems you cannot patch or probe, such as clinical devices or control system networks.

Remediation SLA and exception policy

Ask for the written remediation timeframes by severity and asset criticality, along with the approval path for any deferral, compensating control or risk acceptance. Check whether exceptions expire, who signs them and how they appear in reports. Ask how known exploited vulnerabilities are prioritized above the general queue. A policy that lacks an expiry date or a named approver will not hold up when an examiner or auditor samples exceptions.

Sample auditor report

Request a redacted report that a compliance reviewer would receive, showing scan coverage over time, open findings by age, remediation rates against policy and the list of exceptions with approvals. Confirm the report can be regenerated for any period and that raw scan output is retained for the period your framework requires. Confirm the retention period with the bidder and your compliance lead, since the required duration depends on the framework and sector.

What to confirm in the contract before scanning starts

This sequence turns a vendor proposal into a signed scope that defines what will be scanned, how data is handled, who acts on findings and what the client keeps at handover. Each step ends with a written artifact that procurement and security leads can check before any scanner touches a production network.

Fix written scope and acceptance criteria
Start by listing the asset ranges, cloud accounts, applications and container registries in scope, and the ones explicitly excluded, such as medical devices or control system networks that need a separate assessment approach. Ask the provider to state the scan types for each asset class, whether scans will be authenticated, and how false positives are confirmed and recorded. Acceptance criteria should name the reports, coverage measures and review points the client will sign off on. The step closes when the scope and acceptance criteria are attached to the signed statement of work and both parties have initialed the exclusions.
Confirm data handling and storage location
Scan results contain hostnames, software versions, configuration details and sometimes credentials used for authenticated scans, so the contract must say where that data is held. Ask whether the provider will run scanners and databases inside the client's accounts or data centers, who holds administrative access, how credentials are stored and rotated, and how long raw results and exports are retained. Confirm how results are deleted or returned at the end of the engagement. The step closes when a data flow diagram and a retention schedule are attached to the contract and the security lead has reviewed them.
Name owners for triage and remediation
Each finding class needs a named person who decides whether it is valid, who owns the fix and who approves a risk acceptance or exception. Ask the provider to identify its triage analysts and the client to name asset owners, application owners and an approver for exceptions, with escalation contacts for critical findings. The contract should state which decisions the provider can make on its own and which require client sign-off. The step closes when a responsibility matrix listing each role, its named person and its decision rights is signed by both parties.
Agree the remediation workflow and ticketing path
Define how a confirmed finding becomes a tracked item in the client's ticketing system, including the fields that are required, how duplicate findings are merged and how status returns to the scanning record once a fix is verified by rescan. Ask whether the provider will integrate with the client's existing tracker or require a central tool, and who maintains that integration. Confirm the severity and deadline rules the client has already set, and record that the provider will apply them without substituting its own. The step closes when a worked example of one finding moving from detection to verified closure is agreed and written into the workflow document.
Hand over configuration, reports and runbooks
At handover, the client should receive everything needed to run scanning without the provider, or to switch providers without losing history. This includes scanner and scan task configuration, exclusion lists, report templates, the feed or database update procedure, and a runbook for routine scans and emergency scans of new exposures. Confirm the export formats for findings and the audit trail of triage decisions. The step closes when the client's security lead has accepted the handover package in writing and has run one report from it without provider assistance.

How DeployOpen scopes, delivers and supports vulnerability management evaluations

DeployOpen works on vulnerability management RFP questions as a self-hosted implementation inside your own infrastructure, so the answers you receive about coverage, feeds, scan safety and reporting are tested against your environment. Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.

How we scope

Written scope lists the asset classes, networks, cloud accounts and container registries your RFP questions cover.
We document which feed and edition each tool would use, and which features need paid feeds or subscriptions.
Scope records the scan windows, safe scanning rules and production constraints agreed with your operations teams.

How we build

We deploy the scanning and tracking tools inside your cloud accounts, data centers or air-gapped network.
We test coverage with authenticated and unauthenticated scans against a defined sample of hosts and images.
We verify that findings import, deduplicate and route to the ticketing workflow you specify.

How we hand over

Deliverables include configuration records, runbooks, feed update procedures and the report templates agreed in scope.
We document how false positive triage, exceptions and remediation deadlines are recorded for later audit requests.
Your team receives a walkthrough of answers to each RFP question, mapped to the evidence we produced during testing.

How we support

Ongoing support, upgrades and continuous testing are available as retainers after handover.
Retainers can cover feed synchronization, mirror updates for air-gapped or restricted environments, and tool upgrades.
We can rerun coverage and scan safety tests when new asset types or networks join the program.