What NIS2 point 6.10 asks for and why it is hard to evidence
Point 6.10 of the Annex to Implementing Regulation (EU) 2024/2690 asks an entity to obtain information about technical vulnerabilities in its systems, evaluate how exposed it is to each one, and manage them through to remediation or a documented decision not to act. It also requires a procedure for disclosing vulnerabilities in line with the national coordinated vulnerability disclosure policy. The risk being addressed is simple: a known flaw in an operating system, application or network device that stays open after a vendor has published a fix. The point works in three parts. The first is intake, meaning a monitored feed from CSIRTs, competent authorities and suppliers. The second is scanning and remediation, where results are recorded, critical findings are fixed without undue delay, and a mitigation plan or a reasoned no-action record is kept. The third is disclosure, where the organization decides how it receives reports about its own products or services and how it shares what it has found.
The evidence trail is usually the weak point because each part produces records in a different place. Scanner output sits in one tool, ticket history in another, supplier advisories in an inbox and disclosure decisions in an email thread. An assessor will ask whether a specific critical finding was found, when it was scheduled for action, who decided, and when it was closed, and a patched host with no link to the original finding does not answer that. Confirm with your scanning and ticketing owners whether findings carry a persistent identifier from detection through closure, and whether the risk-acceptance decisions under point 6.10.3 are written down with an approver and a review date. Check the national coordinated vulnerability disclosure policy with your competent authority or national CSIRT before drafting the disclosure procedure, since the Annex defers to it.
Which systems, teams and suppliers fall under vulnerability handling
Point 6.10 applies to whatever the entity operates, so scope starts with the entity's own asset inventory and risk assessment rather than a fixed list. The cards below cover the asset classes, the teams and the external channels that feed vulnerability information into the process.
Endpoints and workstations
Laptops, desktops and mobile devices that hold operational access or administrative tools are the most common source of unpatched software. Decide whether personal devices used for work are in scope, and confirm that every enrolled host reports its installed software inventory. A scanner that cannot see an endpoint leaves a gap that an assessor will ask about.
Servers and operating systems
Physical and virtual servers carry the operating system and middleware that most vulnerability advisories name. Confirm that each server appears in the inventory with its operating system version, owner and scan schedule. Servers outside the inventory usually come from project work, so check for them before the first scan cycle.
Cloud workloads and containers
Virtual machines, managed container images and serverless functions change faster than a fixed scan schedule can track. Decide whether image scanning happens at build time, at deployment or both, and whether running workloads are rescanned. Ask the team which registry and account hold each workload, since ephemeral instances are easy to miss.
Network devices and appliances
Firewalls, routers, switches, VPN concentrators and load balancers run firmware that vendors publish advisories for, often outside the operating system scanning path. List each device with its firmware version and the person accountable for it. Confirm that the scanning tool reaches these devices, or that the vendor advisory channel is monitored by hand.
Third-party and open-source components
Libraries, plug-ins and bundled software inside applications often reach production without appearing in any operating system inventory. Record the software bill of materials for each service and decide who checks it against advisory feeds. Commercial products bought from suppliers need the same treatment, with the supplier named as a source of vulnerability information.
Suppliers, CSIRTs and authorities
Vulnerability information arrives from CSIRTs, competent authorities and suppliers, and point 6.10 requires monitoring each of these channels. Name the owner of each channel, the intake mailbox or feed, and the escalation path to the team that patches. Include managed service providers and hosting suppliers, because their notices reach the entity through contracts, not through the scanner.
How to implement vulnerability handling step by step
The sequence runs from naming where vulnerability information comes from to publishing a disclosure procedure, so that each finding ends in a recorded fix, a mitigation plan or a documented decision to take no action.
Define sources of vulnerability information
Name every channel the organization will monitor for technical vulnerability information. Point 6.10.2(a) expects input from channels such as CSIRTs, competent authorities and suppliers, so list each one, the person who receives its notices and the vendors whose advisories apply to your systems. Assign an owner for each feed and confirm that the list matches the asset inventory. The output is a written source register with named owners and a review date, which shows an assessor where information enters the process.
Set scan scope and scan intervals
Decide which systems are scanned, how often, and with which tools. Base the scope on the asset inventory and the risk assessment, and set intervals that are written down and followed. Point 6.10.2(b) asks for scans where appropriate at planned intervals, so record the scanner configuration, the schedule and the target ranges. Tools such as Wazuh, Fleet or Greenbone Community Edition can cover endpoints, hosts and network services. The output is a scan plan that names each scanner, its targets and its schedule, and that someone can check against actual scan runs.
Run scans and store the results
Execute the scheduled scans and keep every report, including runs that find nothing. Point 6.10.2(b) requires recorded results, so store raw output and the scanner version, timestamp and target list with each run. Greenbone stores results in PostgreSQL, and Wazuh and Fleet keep inventory-based detections that can be exported. Confirm that failed or incomplete scans are logged and rerun. The output is a retained archive of dated scan reports that links each run to its scope and configuration.
Deduplicate and triage findings
Merge the output of several scanners so each vulnerability appears once against each affected asset. DefectDojo can import reports from many tools and deduplicates findings using per-tool hashcode fields, which helps keep the register accurate. Assign each finding to an owner and check that it matches an asset in the inventory. Confirm the affected version and whether a fix exists before ranking it. The output is a single findings register in which every entry has an asset, an owner and a status.
Assess severity with CVSS and set the critical urgency rule
Score each finding using CVSS-based severity and adjust for exposure, such as internet reachability and the value of the affected system. Write down the rule that defines a critical vulnerability and the rule for addressing it without undue delay. Because the regulation does not give a fixed deadline in the facts supplied, the rule should name who approves the timeline and who is informed when it slips. Keep the scoring method documented so that severity decisions can be reproduced. The output is a severity rule and a scored register that identifies which findings are critical.
Record mitigation plans or documented no-action decisions
For each finding, either create a mitigation plan or record why no remediation is needed. Point 6.10.3 requires a mitigation plan where justified by impact, and a documented reason where it is not. A no-action record should state the assessed impact, the compensating factors and the approver. Review these decisions when the asset, its exposure or the threat changes. The output is a plan or justification for every finding in the register, with an approver and a review trigger attached to each.
Verify fixes and close findings
Confirm that each critical finding was addressed before closing it. Rescan the affected asset and keep the result with the original finding, so the record shows the vulnerability was no longer detected. Where a fix was not possible, keep the finding open under its mitigation plan. Evidence that critical findings were addressed is one of the examples ENISA's June 2025 guidance lists. The output is a closure record for each finding that links the fix to a verification scan.
Publish the disclosure procedure
Write and approve a procedure for disclosing vulnerabilities that aligns with the national coordinated vulnerability disclosure policy, as point 6.10.2(e) requires. Name the intake contact, the steps for receiving reports from outside, the coordination route with the national CSIRT designated under Article 12 and the record kept for each disclosed vulnerability. Confirm the policy text with your national authority or CSIRT, since the national policy governs the details. The output is an approved, published procedure and a register of disclosed vulnerabilities.
How an assessor tests vulnerability handling
A supervisor starts with the documents. The first question is whether the entity has written down how it finds out about vulnerabilities, how it scans, how it decides severity and how it disposes of each finding. The reviewer then checks that the written procedure matches the tools and roles in place, because a policy that describes a process nobody runs is a common reason for a finding. The reviewer also looks for the decision record that point 6.10.3 expects, which shows why a vulnerability was mitigated or left unremediated.
- Information sources: The procedure names the channels the entity monitors, such as CSIRTs, competent authorities and suppliers, and states who owns each one.
- Scan scope and cadence: The document sets which assets are scanned, how often and with which tools, and it explains where scanning is not appropriate.
- Severity and deadlines: The procedure defines how findings are rated, how critical findings are identified and what counts as addressing them without undue delay.
- Exception path: The document describes how a vulnerability can be accepted or deferred, who approves that decision and how it is reviewed.
- Disclosure procedure: The entity's process for receiving and publishing vulnerability reports is written down and tied to the national coordinated vulnerability disclosure policy.
Before accepting the documents, confirm that the named owners exist, the tools in the procedure are configured, and the review dates are current.
An assessor who samples findings works backward from the scanner output. The usual approach is to select a set of findings across severity levels and time periods, then trace each one to a ticket, a fix or a documented decision. The assessor does not accept a dashboard total as proof. They want to see that scans ran on schedule, that the results were recorded and that critical items moved to closure within the entity's own deadline.
- Scan records: Reports show the scanner configuration, schedule and target list for each scan, so the assessor can confirm the scan covered the in-scope assets.
- Severity basis: Ratings are traceable to a stated method, such as CVSS-based scoring, with any manual adjustment explained.
- Closure evidence: Each sampled critical finding links to a patch, configuration change or compensating control, with dates that fall within the entity's timeline.
- Deduplication: Repeated findings from several tools or scan runs are merged in a way that does not hide open items.
- Gaps in coverage: Assets that appear in the inventory but never appear in scan results are flagged for explanation.
For each sampled item, check that the evidence chain runs from detection to closure without a break.
The disclosure test looks at what happens when an outside party reports a flaw. An assessor asks for the intake route, the record of past reports and the way the entity coordinated with reporters and authorities. Because point 6.10.2(e) ties the procedure to the national coordinated vulnerability disclosure policy, the assessor also checks that the entity knows which CSIRT coordinates disclosure in its Member State. Many entities have a procedure on paper but no record of how they handled a real report, so the assessor often asks for a walkthrough.
- Intake channel: A published contact or security reporting address exists, is monitored and has a named owner.
- Triage record: Each received report shows the date, the assessment, the decision and the person responsible.
- Coordination trail: Communications with reporters, suppliers and the relevant CSIRT are logged, including any agreed disclosure timing.
- Register of disclosed vulnerabilities: The entity keeps a record of what it disclosed, when and to whom.
- Zero-report evidence: If no reports arrived, the entity can still show that the channel was tested and monitored.
Confirm with the entity's national authority which CSIRT and which coordinated disclosure policy apply, because the test depends on that local framework.
Evidence that satisfies point 6.10
Point 6.10 is tested through records, not tool screenshots. The artifacts below form one chain: the scanner setup, the schedule, the results, the severity decisions, the fix or justified exception, and the disclosure log. Each one must be kept current between audits and retained by the entity itself.
Scanner configurations
Keep a versioned record of each scanner's configuration, including the scan targets, credentialed or uncredentialed mode, plugin or feed update settings and the asset groups in scope. Assessors check that the configuration covers the systems in the asset inventory, so changes to scope should be traced to a change request. Export and store the configuration whenever it changes, not only before an audit. The tool does not decide scope for you. The entity must approve it and keep the record.
Scan schedules and reports
Document the planned scan intervals per asset class and retain the completed scan reports as proof they ran. Gaps between the planned schedule and the actual run history are the first thing a reviewer will question. Keep the scheduler configuration, the run logs and the generated reports in a retained location outside the scanner itself, so that history survives a rebuild. Confirm how long your scanner keeps task history by default, since that setting can drive your retention period.
CVSS-based severity assessments
Record the severity rating assigned to each finding, the CVSS version used and the rationale for any change from the scanner's default score. Environmental factors such as exposure, compensating controls and asset criticality often justify an adjustment, and the reason must be written down. Reviewers test whether critical findings are rated consistently across tools. Where findings from several scanners are merged, keep the mapping rules that set one severity scale for all sources.
Proof that critical findings were addressed
For each critical vulnerability, keep the ticket, the remediation or mitigation change, and a rescan showing the finding is gone or reduced. Point 6.10.2(c) requires critical vulnerabilities to be addressed without undue delay, so record the date the finding was identified and the date it was closed. Where a fix is deferred, the mitigation plan required by point 6.10.3 must sit in the same record. Confirm your internal deadline for critical findings with management, because the regulation does not set a number of days.
Documented exceptions and no-action decisions
Point 6.10.3 accepts a documented reason in place of remediation when a vulnerability does not warrant action. Keep each such decision with the affected asset, the exposure analysis, the approver and the review date. Reviewers look for exceptions that were never revisited, so set a recurring review in your vulnerability process. Deduplication in a findings platform can hide repeated exceptions, so keep the decision linked to every finding it covers.
Records of disclosed vulnerabilities
Keep a log of every vulnerability your organization received from outside, such as reports from researchers, CSIRTs or suppliers, and every disclosure you made under your procedure. Each entry should show the intake date, the triage outcome, the coordination contacts and the disclosure decision. The procedure itself must follow the national coordinated vulnerability disclosure policy, so confirm which CSIRT coordinates disclosure in your Member State. Entries should be retained even when no disclosure happened.
What meeting point 6.10 costs in money and effort
This table breaks down the cost components of running vulnerability handling under point 6.10, who is paid for each, whether it is one-time or recurring, and what drives it up. Use it to shape a quote request, since no price is supplied for this work and each figure depends on your own asset count, scan schedule and scope.
| Cost component | Who is paid | One-time or recurring | What drives it |
|---|---|---|---|
| Scanner and platform licenses | Commercial vendor, or no license fee for open-source tools such as Greenbone Community Edition, Wazuh, Fleet and DefectDojo | Usually recurring for commercial tools; open-source tools carry no license fee but still need hosting | Choice of tooling, number of endpoints and hosts, and whether vendor support is bought |
| Platform setup and hosting | Internal platform team or implementation partner | One-time for deployment, recurring for hosting, storage and patching of the scanner itself | Number of network segments scanned, database sizing for stored results, and high availability needs |
| Engineering time for configuration and triage | Internal security engineers or an implementation partner on a fixed-scope agreement | One-time for initial scan policies and asset mapping; recurring for triage of new findings | Scan frequency, false-positive rate, deduplication rules and the number of teams owning remediation |
| Evidence upkeep | Internal compliance or security staff | Recurring, tied to each scan cycle and each remediation record | How often scan reports, severity assessments and mitigation or no-action decisions must be recorded and retained |
| External scanning or penetration testing | Independent testing provider | Recurring if scheduled, one-time for a specific test | Scope of external exposure, test depth and whether the test is repeated after major changes |
| Remediation of critical vulnerabilities | Internal system owners or the operator of the affected systems | Recurring as new findings arise | Patch complexity, change approval steps and how many systems depend on a single component |
| Auditor or assessor sampling | Independent auditor or assessor, not DeployOpen | Recurring at each assessment cycle | Number of scan cycles and disclosed vulnerabilities the assessor samples, and the quality of records kept |
Who owns vulnerability handling and who can help
Your organization owns point 6.10 in full. Accountability for vulnerability handling sits with management and the security function, and nobody else can accept a risk, approve a mitigation plan or decide what your public disclosure procedure says. Your team decides how vulnerability information is prioritized against your actual exposure, and it signs off on every documented decision not to remediate.
- Risk decisions: Set the severity thresholds that count as critical for your environment, and decide when a vulnerability is accepted without remediation.
- Mitigation approvals: Approve mitigation plans where the impact justifies one, and record the owner and target for each action.
- Disclosure procedure: Write and maintain the procedure for receiving and disclosing vulnerabilities, aligned with the national coordinated vulnerability disclosure policy of your Member State.
- Scan scope and cadence: Decide which assets are scanned, how often, and who reviews the results.
- Ownership of records: Keep the scan reports, decisions and closure records that supervisors will ask for.
Before engaging any outside party, confirm in writing which of these decisions your management body has delegated, and to whom.
An implementation partner such as DeployOpen can prepare the systems and evidence that point 6.10 depends on. The partner deploys open-source scanners inside your infrastructure, configures schedules, connects findings to a tracking workflow and builds the reporting pipeline. The partner does not decide which risks you accept, and it does not certify that your vulnerability handling is compliant.
- Scanner deployment: Install and harden tools such as Wazuh, Fleet, Greenbone Community Edition or DefectDojo inside your own cloud accounts, data centers or air-gapped networks.
- Schedules and configurations: Set scan tasks and frequencies, and keep the scanner configuration under version control.
- Evidence pipelines: Route results into a findings register, deduplicate them and export reports that show scan dates, results and closure.
- Integration with feeds: Connect vulnerability information sources, including CSIRT and supplier advisories, to the tracking workflow.
- Documentation and handover: Write runbooks so that your staff can operate the tooling after the engagement ends.
Agree on the deliverables, the evidence formats and the ownership of each artifact in a written, fixed scope before work begins.
An independent auditor, assessor or the competent national authority tests whether your vulnerability handling works and reports on it. Their role starts where the implementation partner's role ends. They sample your records, check that the process ran as documented and form an opinion. They never produce the scans, write the procedures or close the findings for you, because doing so would remove the independence that makes their conclusions meaningful.
- Testing: Sample scan reports, verify that critical findings were addressed without undue delay and check the documented reasons for any non-remediation.
- Reporting: Issue the findings or opinion through the channel the assessment requires. No implementation partner issues such a report.
- Competent authority role: National authorities may inspect, request information and run security scans under NIS2 supervision.
- Independence line: An auditor who designed the controls it then tests creates a conflict. Ask your auditor to confirm in writing which services it has provided to you.
- Ownership of findings: Expect findings to be recorded against your controls, not against the consultant who prepared the evidence.
Before hiring any assessor, confirm its accreditation, its scope and whether it has any prior role in designing your controls.
Where organizations fall short on vulnerability handling
Most organizations scan for vulnerabilities, so the gaps in point 6.10 rarely come from missing tools. They come from missing decisions: who acts on a finding, how fast a critical one must move, and how a no-action call is recorded. Each card below names one gap and the check that closes it.
Scans without recorded results
Scanners often run on a schedule, but the results live only in the console or in an analyst's inbox. Point 6.10.2(b) expects scans at planned intervals with recorded results, and an assessor will ask for the scan configuration, the schedule and the report from a given date. Check that every scan task has a stored report, a named owner and a retention setting, and that you can reproduce the report for any past period.
No defined critical threshold
Point 6.10.2(c) requires critical vulnerabilities to be addressed without undue delay, but the regulation does not leave the word "critical" to each analyst. Without a written severity rule, a finding rated high by one tool and critical by another can sit unaddressed for months. Agree on a severity basis, such as CVSS-based ratings combined with asset criticality and exposure, and write the response expectation for each band into the vulnerability procedure.
Undocumented no-action decisions
Point 6.10.3 allows an entity to leave a vulnerability unremediated only if it documents why. Teams often accept risk in a chat thread or a ticket comment that is later closed, which leaves no evidence. For each accepted finding, record the asset, the rationale, the compensating control, the approver and a review date. Check that a supervisor could pick any closed finding and find this record in under a few minutes.
Unowned findings after import
Imported findings from several scanners frequently multiply, and duplicates or stale entries remain open without an owner. DefectDojo can deduplicate findings using per-tool hashcode fields, but deduplication does not assign accountability. Each finding should have a responsible team, a due date tied to its severity and a status that is updated when a fix is verified. Check whether your dashboard shows open critical findings without an owner, and treat any such item as a gap.
Missing disclosure procedure
Point 6.10.2(e) asks for a procedure for disclosing vulnerabilities in line with the applicable national coordinated vulnerability disclosure policy. Many entities have a security contact address but no written process covering intake, triage, coordination with the national CSIRT and communication with reporters. Confirm the national policy and the coordinating CSIRT with your competent authority, then write the procedure against it and test it with a tabletop exercise.
No link to patch management
A vulnerability record that stays open after the patch is deployed is a common audit finding. Point 6.10.3 expects a mitigation plan where impact justifies one, and that plan usually ends in a change record in the patch process. Connect each remediation ticket to the change or patch record that closed it, and verify the fix with a rescan. Check that a closed vulnerability always points to evidence that the affected asset no longer reports the issue.
Questions buyers ask about point 6.10
What does point 6.10 vulnerability handling cost, and what drives the price?
Cost depends on the size of the estate, how many scanners and endpoints must be covered, how many systems are in scope, and how much triage and remediation work the team already carries. No fixed figure applies to every entity. The cost falls into a few parts: the implementation work to deploy scanners and a findings platform, the one-time setup of scan schedules and severity rules, the recurring running cost of scanning, triage and reporting, and the internal time to fix critical vulnerabilities. Open-source tools remove license fees but not labor or hosting. Ask any implementation partner for a written, fixed-scope quote that names each system, each scan target, the integrations and who performs the remediation handover. DeployOpen does not publish prices; a quote follows from the agreed scope.
How long does it take to stand up vulnerability handling for point 6.10?
The supplied facts do not give a duration, so treat any timeline as something to agree in writing for your environment. The time depends on how many asset types need coverage, whether a software inventory already exists, how quickly scanner access and network permissions can be granted, and how many integrations with ticketing or reporting systems are required. Point 6.10 asks for monitoring of vulnerability information, scans at planned intervals with recorded results, prompt handling of critical vulnerabilities and a disclosure procedure, so each of these needs to be operating before evidence can be shown. Ask for a milestone plan that separates tooling deployment, first scan baseline, the disclosure procedure and a dry run of the critical-finding workflow.
What must our own team do for point 6.10, and what can be outsourced?
The organization owns its controls. An implementation partner can deploy and configure scanners, build scan schedules, connect findings to a deduplicated register and prepare evidence, but your team must decide the risk acceptance rules, approve mitigation plans, own the remediation of critical vulnerabilities and sign off on the disclosure procedure. Specifically, internal staff should:
- Define which assets and vendors are in scope and who receives supplier advisories
- Set the severity thresholds and the meaning of "without undue delay" for your entity
- Approve mitigation plans and documented decisions where no remediation is needed
- Confirm the disclosure procedure with your national authority
Only an independent assessor or competent authority issues any compliance conclusion.
Are open-source tools enough to meet point 6.10?
Open-source tools can cover the technical parts of point 6.10, but they do not decide compliance on their own. Wazuh can correlate endpoint software inventories with vulnerability data, Fleet can match installed software on enrolled hosts against several advisory sources, Greenbone Community Edition schedules and records network vulnerability scans, and DefectDojo imports, deduplicates and tracks findings from many scanner formats. Gaps remain. You must confirm that each source covers your operating systems, network devices and cloud services, that feeds are kept current in an offline or online setup, and that the disclosure and mitigation workflows are documented outside the tools. Test coverage against a known inventory before relying on the output as evidence.
How does point 6.10 differ from point 6.5 security testing and 6.6 patch management?
Point 6.10 is about knowing which technical vulnerabilities exist, evaluating exposure and managing them, including monitoring external vulnerability information and running scans at planned intervals. Point 6.5 covers a security testing policy with scope, frequency, methodology and findings driven by the risk assessment, so it asks for deliberate tests such as penetration tests. Point 6.6 covers applying tested, integrity-checked patches within a reasonable time and documenting exceptions where patching would cause more harm. In practice, 6.10 produces the vulnerability register that feeds 6.5 test planning and 6.6 patch queues. Keep the three sets of records linked so an assessor can trace a finding from detection to test or patch to closure.
What should we confirm with our national authority about the disclosure policy?
Point 6.10 requires a vulnerability disclosure procedure aligned with the applicable national coordinated vulnerability disclosure policy. NIS2 Article 12 requires each Member State to designate a CSIRT as coordinator for coordinated vulnerability disclosure, so the first question is which CSIRT or authority coordinates disclosure in your country and where its published policy sits. Confirm the reporting channel, the expected timelines the policy sets for vendors and reporters, the contact details for your security team, whether your sector regulator adds requirements, and how your procedure handles vulnerabilities found in suppliers' products. Record the answers and the date you confirmed them as evidence.
How DeployOpen prepares vulnerability handling evidence
DeployOpen starts with a written scope that names the systems, endpoints, network segments and supplier channels in which vulnerability information will be collected and managed. The scope document should also state who in the organization owns each step: who receives vendor and CSIRT notices, who approves a mitigation plan, who signs off a documented decision that a finding needs no remediation, and who owns the disclosure procedure under point 6.10.2(e). Deployment follows that scope. Self-hosted components such as Wazuh for endpoint vulnerability detection, Fleet for enrolled hosts, Greenbone Community Edition for network scanning and DefectDojo for consolidating findings run inside the client's own cloud accounts, data centers or air-gapped networks, so scan results and asset data never leave the environment. Confirm each product's current capabilities and supported platforms against its own documentation before the scope is signed.
The evidence set is designed around what an assessor will ask to see. DeployOpen configures scanner settings, scan schedules and report exports, sets up DefectDojo deduplication so that repeated findings are tracked once, and defines the severity method used for CVSS-based ratings. It also builds the records that show critical findings were addressed without undue delay and that mitigation plans or justified exceptions were approved. The organization keeps ownership of these records and of the decisions behind them. Where the organization wants an outside view of its own exposure, security testing is available as a separate, optional engagement with its own written scope, rules of engagement and deliverables, and it is priced and timed independently of the evidence work. An independent auditor or assessor reviews the evidence and issues any report or certificate. DeployOpen does not issue audit reports, attestations or certifications.
Before agreeing the scope, ask the implementation partner to confirm three things in writing: the list of systems that scanners will reach and the credentials they will use, the retention period for scan results and reports, and the handover package that the internal team will own after deployment. Ask for an illustrative evidence pack showing one critical finding followed from detection to closure, so you can check whether the records would satisfy your own assessor. Fees, durations and support terms should appear in the quote as line items tied to that scope, not as a general allowance.
