What NIS2 patch management requires in practice
A supervisor or customer who asks how your patches are controlled wants to see a documented procedure that applies tested, integrity-checked security patches within a reasonable time, plus a written exception for any patch you decide not to apply because the harm of applying it would outweigh the cybersecurity benefit. Point 6.6 of the Annex to Implementing Regulation (EU) 2024/2690 asks for both halves, and the procedure must link to your change, vulnerability and risk management processes. The risk it addresses is simple: every known vulnerability left open on a production system is an entry point that attackers already know how to use. The difficulty is that the regulation sets no deadline in days. You must define what "reasonable" means for your environment, based on exposure, criticality and the availability of a vendor fix, and then show that you actually meet your own timeline.
In practice, confirm four things before an assessment. First, that each security patch has a recorded source and a check that it came from a trusted vendor channel, with the integrity check and its result kept with the change record. Second, that patches reach a pre-deployment test environment and that the results are retained. Third, that the patch deployment log records timestamps, the responsible staff and the affected systems, which ties back to your asset inventory. Fourth, that every patch not applied within your timeline has a dated exception with a risk acceptance signed by the accountable owner, and that any compensating measures are listed. Where a self-hosted tool such as DefectDojo imports scanner output and deduplicates findings, its records can show how a vulnerability moved from detection to closure. Confirm each tool's exact export and API capabilities in your own environment before relying on them.
Which systems and suppliers fall under patch management scope
Point 6.6 applies to the systems an entity runs, and the scope question is answered by inventory, ownership and contract terms rather than by job titles. The cards below cover the asset classes to include, how the inventory drives the patch list, and how vendor-managed and third-party systems change who applies a patch. Confirm with counsel and your national authority which of your entity types the regulation binds.
Servers and endpoints
Physical and virtual servers, workstations and laptops are the baseline of patch scope, including systems that are rarely rebooted or sit outside the domain. Confirm that every operating system build, hypervisor and management agent is covered by a patch source you trust. Check that remote and travelling endpoints receive patches on the same procedure as office machines, since point 6.6 asks for application within a reasonable time without exempting any device class.
Network devices and firmware
Routers, firewalls, switches, load balancers and wireless controllers carry firmware that is patched through vendor channels, often outside the operating system process. Include firmware and boot components in scope, because a patch that never reaches a perimeter device leaves the same exposure as an unpatched server. Record the firmware version of each device so that the patch status can be shown to an assessor.
Cloud workloads and container images
Virtual machines, managed database engines, serverless runtimes and base images for containers all contain software that needs patching, even when the cloud provider patches the underlying hardware. Separate what the provider maintains under the shared responsibility terms from what your team must update. Rebuild and redeploy container images when base layers change, and confirm that old images are not kept running after a fix is published.
Asset inventory as the scope source
A patch cannot be applied to a system nobody has recorded, so the asset inventory decides what is in scope. The inventory should list each system with its owner, operating version, location, and the components it depends on, and it should update when assets are added or retired. Point 12.4 on asset inventory covers this foundation, and a gap in it becomes a gap in patch coverage.
Vendor-managed and third-party systems
Software-as-a-service products, managed hosting and outsourced operations may be patched by a supplier, but the entity still needs evidence that the patches were applied within a reasonable time. Ask each supplier for patch commitments, notification channels and the dates of recent fixes, and write these into the contract. Where a supplier cannot show this, the residual risk and the additional measures must be recorded by the entity.
Confirming entity type and sector
Point 6.6 sits within the implementing regulation, which binds specific provider types such as DNS, cloud, data center, managed service and online platform providers. Other essential and important entities apply the Article 21 measures through national law, so confirm which rule set and national transposition law applies to your entity. Document the decision, because an assessor will ask how you determined the scope.
How an assessor tests patch management under point 6.6
This table walks through each element of point 6.6 and shows how an assessor would test it, which evidence to expect, and where organizations usually fall short. Read each row as a test question: if the evidence described in the middle column cannot be produced, the finding in the right column is the likely outcome. The main takeaway is that assessors test the records behind each decision, not only the existence of a patching policy.
| Element of point 6.6 | Test approach and evidence requested | Common findings |
|---|---|---|
| Procedure coherent with change, vulnerability and risk management | Assessor reads the patch procedure and traces one sample patch from vulnerability intake through risk rating, change request and deployment. Evidence: procedure, linked tickets and change approvals. | Patch procedure exists but is not linked to the change process, so emergency patches bypass records. |
| Application within a reasonable time | Assessor selects a sample of recent security patches and compares release dates with deployment dates against the entity's own documented target windows. Evidence: deployment logs with timestamps, responsible staff and affected systems. | No documented target windows, or logs lack timestamps, so the reasonable time cannot be demonstrated. |
| Pre-deployment testing | Assessor checks that sampled patches were tested before production use, including test environment scope and results. Evidence: pre-deployment test results linked to each change request. | Emergency patches applied to production with no test record and no retrospective review. |
| Trusted sources and integrity checks | Assessor asks how patches are obtained and verified, such as vendor channels, signature or checksum validation, and who performs the check. Evidence: vendor signature check records and source configuration. | Patches downloaded from unofficial mirrors or installed without recorded integrity verification. |
| Patch unavailable or not applied | Assessor looks for the additional measures taken while a patch is missing, such as compensating controls, and for documented acceptance of residual risk by a named owner. Evidence: risk register entries and compensating control records. | Unpatched systems with no compensating control record and no named risk owner. |
| Documented exception for deferral | Assessor requests the exception register and tests whether each deferral states the reasons, the cybersecurity benefit weighed against disadvantages, the approver and a review date. Evidence: signed exception records. | Undocumented deferrals discovered through scan results that contradict the patch records. |
| Consistency of records across tools | Assessor compares asset inventory, vulnerability scan results and patch logs for the same systems to confirm they agree. Evidence: inventory export, scan reports and deployment records covering the same period. | Scanner reports show systems missing from the asset list or patch logs that do not match the scan output. |
How to build a patching process that produces evidence
The sequence below turns patching from an ad hoc activity into a traceable chain, from knowing which assets exist to proving each patch was tested, approved, deployed and verified, or that a documented exception was justified. Each step names the record it leaves behind for an assessor or supervisor to inspect.
Confirm the asset inventory and classification
The operations or infrastructure team lists every system, application, firmware and network device that the patching process covers, with its owner, business function, data sensitivity and criticality rating. Patching cannot be shown to be timely if the entity cannot say what it runs. The output is a current inventory extract with a classification field for each asset, reviewed by the asset owner and linked to the patching scope. Confirm that the inventory is maintained against point 12.4 so that new or changed assets enter the patching queue automatically.
Collect patch intake from defined vulnerability sources
The security team records every security advisory, vendor bulletin, scanner finding and coordinated disclosure notice that affects an inventoried asset, with the source, publication date and affected product versions. Intake should come from named sources rather than individual memory, so the entity can show when it learned of a fix. The output is a ticket or register entry per advisory, opened in the change or vulnerability workflow with a unique reference. Confirm which sources the entity monitors and who is accountable for reviewing them.
Prioritize each patch against a documented reasonable-time standard
The security lead assesses each advisory against the entity's risk assessment, considering asset criticality, exposure, exploitation evidence and the compensating controls already in place. The entity then sets its own reasonable-time target for each priority level, because the regulation sets no fixed number of days. The output is a prioritization record stating the priority, the target date derived from the standard and the named owner. The standard itself should be approved by management and reviewed when the risk assessment changes.
Validate the patch in a test environment
Before any production use, the engineering team applies the patch to a non-production copy that matches the production configuration closely enough to reveal functional and security regressions. The team records what was tested, the test cases, the results and any defects found. The output is a pre-deployment test report signed off by the system owner. If the patch fails testing, the record moves to the exception path or back to the vendor, and the failure itself becomes evidence.
Verify source trust and package integrity
Before installation, the engineer confirms the patch came from the vendor's trusted channel and checks its integrity using the vendor's published hashes or signatures. Where the vendor provides a signature verification method, the check is performed against that method and the result is retained. The output is a verification record naming the source, the hash or signature check performed, the outcome and the person who performed it. Patches that cannot be verified do not move forward to change approval.
Approve the change before deployment
The change manager reviews the request, which links the advisory, the priority, the test results and the verification record, and approves or rejects the deployment window. Approval should include the business owner where service interruption is possible. The output is an approved change request with approver names, dates and any conditions attached. This record ties patching to the entity's wider change management process so that the approval trail can be produced on request.
Deploy the patch and log each action
The operations team applies the approved patch within the approved window and records each system affected, the time of deployment, the staff member responsible and the outcome. Automated deployment tools can generate these logs, but the entity should confirm that timestamps are accurate and that logs are retained under its monitoring policy. The output is a deployment log entry per system, linked to the change request. Any system that could not be patched is flagged immediately and routed to the exception path.
Verify the fix and document the exception path
After deployment, the security or operations team confirms the patch is in place, typically through a rescan or version check, and closes the advisory only when the result is recorded. Where a patch is not applied, the entity documents the reasons, shows that the disadvantages outweigh the cybersecurity benefits, and records the compensating measures and accepted residual risk, approved by an accountable manager and reviewed on a set cycle. The output is either a verification record or a substantiated exception record, which together show that every advisory reached a documented outcome.
Evidence that satisfies a patch management review
ENISA's June 2025 guidance lists concrete evidence for point 6.6, and a reviewer will look for records that connect each patch to a test, an approval, a deployment and an owner. The cards below cover the core artifacts, the exception trail and the routine that keeps them current between audits.
Patch deployment logs
Each deployment record should show a timestamp, the responsible staff member and the affected systems. A reviewer will sample a critical patch and trace it from release to installation on every host it touched. Check that logs come from the systems themselves or a central collector, not from a spreadsheet that someone edits after the fact. Confirm that the record names the asset identifiers from your inventory so the scope can be matched to the patch.
Pre-deployment test results
Point 6.6 requires patches to be tested before they reach production. Keep the test plan, the environment used, the results and the sign-off by the person who approved release. A test record that shows only a pass without a scope (which functions, which configurations) gives an assessor little to work with. Store results so they can be linked to the change that carried the patch.
Change requests with approvals
Patching should move through the same change process as other modifications, so each patch needs a change request with a stated risk assessment, a rollback plan and approval from the authorized owner. Ticketing systems such as GLPI can hold these records with their approval history. Confirm that emergency patches follow a documented fast path and that they are reviewed after the fact.
Vendor signature and integrity checks
ENISA's examples include checks that a patch came from a trusted source and is intact. Record the verification method, such as the vendor's published signature or checksum, the key or hash used, and who performed the check. Ask your vendors which signing keys they publish and how you are told when those keys change. A check that is undocumented cannot be shown to a reviewer, even if it was performed.
Exception records and residual risk acceptances
When a patch is not applied because the disadvantages outweigh the benefits, point 6.6.2 requires documented and substantiated reasons. Each exception should name the vulnerability, the affected systems, the compensating measures, the review date and the manager who accepted the residual risk. Record risk acceptances against the management body or the officer it has delegated to, so the decision is traceable to someone with authority.
Keeping evidence current between audits
Evidence assembled only before an assessment will show gaps. Set a recurring review that checks that every critical or high patch has a complete chain of records, that open exceptions have not passed their review dates, and that the asset inventory still matches the systems patched. Vulnerability tools such as Greenbone and DefectDojo can feed findings into this review, so the trail is built as work happens. Ask any implementation partner to define this routine in writing as part of the scope.
What meeting point 6.6 costs in money and effort
Tooling is the cost most organizations look at first, and it is also the one where self-hosted open-source platforms change the picture most. Point 6.6 does not require a specific product, but it does require procedures that track which patches exist, which systems they affect, and whether they were tested. Vulnerability scanners, findings aggregators and ticketing systems each carry a cost, whether that cost is a license, a subscription or the infrastructure needed to run them.
- License spend: Community editions of tools such as DefectDojo, Greenbone Community Edition, GLPI and Zammad remove per-seat or per-asset license fees, but you still pay for the servers, storage and backups that host them.
- Operating cost: Self-hosted tools need patching, upgrades, database maintenance and monitoring themselves, which is ongoing work for your platform team.
- Commercial add-ons: Some organizations keep a commercial scanner or support contract. Ask which features are included in the open-source edition and which require paid components.
- Integration work: Connecting scanners, ticketing and asset data is usually a one-time cost that recurs when tools change version.
Ask the partner to separate license cost, hosting cost and support cost in the quote, and to state which tools are assumed to be the customer's existing products.
Engineering time is usually the largest component. It covers the one-time build of the patch pipeline and the recurring work of testing and deploying patches. Point 6.6 requires patches to be tested before production use and to come from trusted sources with integrity checks, so each patch cycle includes steps that a quick update script would skip.
- One-time build: Designing the pipeline, setting up test environments that mirror production, and defining rollback steps.
- Recurring testing: Running patches against representative systems and recording results before production rollout.
- Deployment: Applying patches across the fleet, including maintenance windows and coordination with application owners.
- Integrity and source checks: Verifying vendor signatures or checksums and confirming that packages come from approved repositories.
- Exception analysis: Assessing cases where patching may cause more harm than good, which takes skilled review each time.
Ask how many patch cycles per month the quote assumes and whether testing covers all system types or only a sample.
Evidence is a recurring cost that many budgets miss. ENISA's June 2025 guidance lists examples of evidence for this area, including deployment logs with timestamps, responsible staff and affected systems, pre-deployment test results, change requests with approvals, and vendor signature checks. Producing these records is only useful if they are kept current, retrievable and linked to the systems they describe.
- Ticketing and change records: Each patch needs a ticket or change request with approvals. GLPI's Assistance module supports tickets, problems and changes following ITIL practices, and Zammad can hold ticket-based communication.
- Deployment logs: Logs must be kept with timestamps and staff identities, which depends on the logging design covered in the monitoring controls.
- Exception documentation: Each decision not to apply a patch needs written reasons and substantiation, reviewed on a schedule.
- Asset linkage: Evidence is only credible when it can be tied to a current asset inventory, which takes continuous upkeep.
Ask the partner how evidence is stored, how long it is retained, and who reviews it before an assessment.
Some costs fall outside your own teams. External testing, independent review and assessor effort each have a different purpose and a different payer. It is important to be exact about roles: an implementation partner can prepare systems, procedures and evidence, and penetration testers can test, but only an independent auditor, assessor or certification body issues reports or certificates. NIS2 itself creates no certificate of compliance, so the scope of any outside review depends on what your national authority, customers or contracts request.
- Pre-assessment review: An outside reviewer checks whether patch procedures and records would satisfy a supervisor or auditor. Fees depend on scope and sample size.
- Security testing: Testing of exposed systems can verify that patches were applied, but it is a separate engagement with its own scope.
- Assessor effort: Authorities or auditors will sample patch records, so the effort depends on how well evidence is organized.
- Re-testing: Findings from reviews may require follow-up work and another review.
Ask which outside reviews are included in the quote, who is responsible for each, and what the partner will not provide, such as formal reports or certificates.
Cost moves with the size and variety of your environment and with how many patches arrive. The number of systems, the mix of operating systems and applications, the number of vendors, and the number of change windows all push effort up. Standardized images, automated deployment and a current asset inventory push it down. No duration or price is given here, because the scope of each environment differs. The points below help you compare written quotes on a like-for-like basis.
- Fleet size and variety: More systems and more platforms mean more test cases and more deployment paths.
- Patch volume: The number of vendor advisories and the rate at which they arrive set the testing workload.
- Recurring versus one-time: Ask which items are setup work and which are monthly or per-cycle work.
- Ownership split: Confirm which tasks the customer keeps, such as approval of changes and exception decisions, which management must retain.
- Assumptions and exclusions: Ask for the assumed fleet size, patch cycles, tools in scope and evidence retention period.
Check that the quote states its scope in writing before work begins, names every tool it depends on, and separates implementation from ongoing support.
Which open-source tools produce patch management evidence
Four open-source tools can produce much of the evidence that point 6.6 asks for, but none of them satisfies the requirement on its own. The requirement is met by the organization's procedure and how it is run. The tools only record what happened. Start by deciding which system will be the single record for each patch cycle, then connect the others to it. Greenbone Community Edition (OpenVAS, AGPL-3.0-or-later) supplies the detection side. Its gvmd service stores scan results in PostgreSQL, manages users and permissions, and schedules scan tasks, and staff review results in the Greenbone Security Assistant web interface. Those stored results and scheduled scan records show which affected systems were found and when. DefectDojo (BSD-3-Clause) imports those findings, plus reports from other scanners, through its UI or API, and deduplicates them using per-tool hashcode fields. Confirm which import formats your scanners use, because deduplication only works reliably when those fields are populated.
GLPI (GPL-3.0-or-later) or Zammad (AGPL-3.0-only) should hold the change requests, approvals and exception records. GLPI's Assistance module covers tickets, problems and changes under ITIL practices, while Zammad is a ticketing system that centralizes requests from several channels. Use one of them to link each patch to its change request, approver and documented exception where a patch is not applied. Ask your team to confirm in its own environment that deployment logs with timestamps and responsible staff are kept, and that vendor signature checks are recorded. Neither the tools nor this page can confirm those controls, so test them on a sample patch before an assessor asks.
Who owns patching, who can help, and what the auditor checks
The organization owns the patching procedure, every risk decision to apply or defer a patch, and the sign-off on any documented exception. Point 6.6 places these duties on the entity itself, so no outside firm can accept them on its behalf. In practice, the security function and the operations or platform team share the work, with management approving the policy and the exception criteria.
- Procedure ownership: A named owner keeps the patch procedure current and aligned with the entity's change, vulnerability and risk management processes.
- Risk decisions: Staff assess each patch's urgency against the affected systems and record the decision to apply, test, defer or mitigate.
- Exception sign-off: When the disadvantages of a patch outweigh its benefits, an accountable manager approves the written justification and the additional measures and residual risk acceptance.
- Asset context: Owners confirm which systems are in scope, drawing on an accurate asset inventory, so deployment logs can name affected systems.
- Vendor and source checks: Staff confirm patches come from trusted sources and pass integrity checks before they reach production.
Before engaging any partner, confirm that your named owners can explain each exception in the register and that the approval trail is kept by your own tools.
An implementation partner such as DeployOpen can prepare the systems that make patching repeatable and provable. Its role is to build and integrate tooling, set up test pipelines and configure the collection of evidence, all inside the client's own infrastructure. The partner does not decide which patches to apply, does not accept risk on the client's behalf, and does not issue any report on the result.
- Tooling and integration: Configure ticketing, vulnerability findings and deployment records so each patch has a traceable change request and approval.
- Test pipelines: Build pre-production environments and test steps that the entity can use to record results before production deployment.
- Evidence collection: Set up logs with timestamps, responsible staff and affected systems, and keep them protected and retrievable.
- Documentation: Draft procedure templates and exception forms for the entity to review, approve and adopt.
- Scope boundaries: Agree in writing which tasks the partner performs, which the entity performs, and who keeps which credentials.
Ask any partner to state in its written scope which evidence it configures and which decisions remain with your staff.
An independent auditor, assessor or certification body, or the national competent authority, tests the patching process and judges whether it meets point 6.6. These parties sample records, interview staff, review exception justifications and check whether the evidence supports the entity's claims. They never prepare the evidence, configure the tooling or write the exception rationale, because doing so would remove the independence that makes their judgment useful.
- Sampling: The assessor selects patches and exceptions and traces each one back to its test results, approvals and deployment records.
- Reasonable time: The assessor judges whether application timing fits the entity's documented risk approach, since the regulation sets no fixed day count.
- Exception review: The assessor checks that disadvantages were substantiated and that additional measures and residual risks were accepted by appropriate staff.
- Vendor signature checks: The assessor looks for records showing how integrity and source were verified.
- Clear line: Any consultant who helped build the evidence should not also be the party that tests it.
Before hiring an assessor, confirm that its independence rules allow it to review systems your partner configured.
Where patch management programs usually fall short
Most patch programs fail on paperwork rather than on tooling: the reasonable-time standard is never written down, test and source checks are not recorded, and exceptions live in chat threads. The cards below cover five gaps that assessors commonly find under point 6.6 and the closure for each.
No defined reasonable-time standard
Point 6.6.1 requires patches within a reasonable time but sets no deadline in days, so the entity must define one. Without a documented standard, each team decides case by case and an assessor has nothing to test against. Set target windows by severity and asset class, approve them in the patch procedure, and check actual deployment dates against them each month.
Patches applied without test records
Point 6.6.1 requires patches to be tested before production use, yet many teams apply updates directly and cannot show that they did. Keep a pre-deployment test result for each patch, linked to the change request that approved it. Ticket tools such as GLPI can hold the change record, and the test output should be stored with it.
Missing source and integrity checks
Patches must come from trusted sources and be checked for integrity before installation. Many organizations trust the vendor website or a mirror without recording which checksum or signature was verified. Define approved download sources, verify signatures or hashes at intake, and log the verification result with the patch identifier so that a vendor signature check can be produced on request.
Exceptions recorded informally
Point 6.6.2 allows an entity to skip a security patch only when its disadvantages outweigh the cybersecurity benefits, and only if the reasons are documented and substantiated. Chat messages and verbal sign-offs do not meet that test. Use one exception form with the affected system, the residual risk, compensating measures, the approver and a review date, and track it in the same system as the change requests.
Inventory gaps leave assets unpatched
A patch process only covers the systems it knows about. Servers, network devices, appliances and cloud workloads added outside the change process often sit outside the scanning and patch cycle. Reconcile the asset inventory with vulnerability scan results each cycle, assign an owner to every asset, and report unmatched hosts as findings. Greenbone can schedule scans, but the asset list it scans must come from a maintained inventory.
Questions buyers ask about patch management under NIS2
Does NIS2 set a deadline in days for applying security patches?
No. Point 6.6.1 of the annex to Implementing Regulation (EU) 2024/2690 requires security patches to be applied within a reasonable time after they become available, and it does not translate that into a number of days. Your organization has to decide what reasonable means for each class of system, based on its risk assessment and the severity of the vulnerability. Write that decision down with its rationale, because a supervisor will ask how you reached it. Ask your auditor or supervisor early which internal targets they expect to see, since the regulation leaves that choice to you.
Can an organization skip a security patch under NIS2?
Yes, but only in a narrow case. Point 6.6.2 allows an entity to decide not to apply a security patch when the disadvantages of applying it outweigh the cybersecurity benefits. The entity must document the decision and substantiate the reasons. Where a patch is unavailable or not applied, point 6.6.1 also requires additional measures and the acceptance of residual risk. A decision without a written rationale, a named approver and a review date will not meet the requirement, even if the underlying judgment was sound.
What drives the cost and effort of patch management?
Most of the cost comes from recurring work rather than a one-time project. The main drivers are the number of systems and their diversity, how many vendors and release channels you depend on, how often patches arrive, the amount of testing needed before production, and how much change approval and evidence capture the process requires. Systems that cannot be restarted easily or that need vendor validation take longer to patch safely. Ask any provider to price these components separately: asset discovery, test environments, deployment tooling, change records, evidence collection and ongoing operation. The number of staff hours is the figure to compare, not the license fee alone.
Can we run NIS2 patch management in-house?
Many organizations can, provided they already have an accurate asset inventory, a tested change process and staff who can maintain test environments. The harder parts are usually keeping the inventory current, testing patches before production, and producing evidence that holds up later: deployment logs with timestamps, pre-deployment test results and approved change requests. If those capabilities are missing, an implementation partner can prepare the tooling and procedures in your own environment, but the organization still owns the decisions and the operation. DeployOpen plans and implements self-hosted open-source platforms in the client's infrastructure and prepares evidence for assessments. It does not issue audit reports or certifications.
What does patch management require from management and engineering?
Management must approve the risk-based approach, accept residual risk when a patch is not applied, and receive reporting on exceptions. Engineering must keep the asset inventory accurate, run tests before production, schedule deployments, and record each step. Concretely, plan for:
- A named owner for each system class and for each exception decision
- Test environments that mirror production closely enough to catch regressions
- Change requests that capture approvals before deployment
- Logs that show when a patch was applied, by whom and on which systems
Agree these roles in writing before the first patch cycle so that the evidence trail starts from day one.
How does an auditor or supervisor review patch management?
They look for a documented procedure, a risk-based basis for timing, and records that show the procedure was followed. ENISA's June 2025 technical guidance lists examples of evidence, including patch deployment logs with timestamps, responsible staff and affected systems, pre-deployment test results, change requests with approvals, and vendor signature checks. Reviewers will sample specific patches and trace each one from availability through testing, approval and deployment. For every exception, they will expect the documented reasons, the compensating measures and the accepted residual risk. Confirm with your assessor or national competent authority which evidence formats they accept. NIS2 creates no certificate, so the review is an inspection or audit by the authority, not a pass or fail stamp.
Which open-source tools produce patch management evidence?
No single tool covers the whole process, so most setups combine several. Greenbone Community Edition (OpenVAS) schedules vulnerability scans and stores results in PostgreSQL, which gives you a record of what was found and when. DefectDojo can import findings from more than 500 security tool report formats and deduplicates them, which helps track each vulnerability to its closure. GLPI's Assistance module supports tickets, problems and changes following ITIL practices, which can hold approvals and deployment records. Zammad can route requests and exceptions into a ticket system. Confirm that each tool fits your own asset data and approval workflow before relying on it, and check that the change and log records meet your evidence standard.
How DeployOpen prepares patch management for NIS2
DeployOpen starts patch management work with a written scope agreed before any build begins. For point 6.6, that scope names the systems in the client's asset inventory that receive patches, the vendors and sources each patch stream comes from, the owner of each decision, and the test environments that stand in for production. Engagements are fixed-scope, so deliverables and timelines are set out in writing first, and an outside auditor or certification body is the party that later judges whether the client's procedures meet the requirement. DeployOpen does not issue audit reports or certifications, and it does not decide whether a client's patch cadence is reasonable. Those judgments stay with the client's management and its assessor.
In the client's own cloud accounts, data centers or air-gapped networks, DeployOpen implements the self-hosted tooling that carries a patch from identification to closure. Vulnerability findings can be consolidated in DefectDojo, which imports reports from more than 500 tool formats and deduplicates them with per-tool hashcode fields, so each finding has one lifecycle. Change requests, approvals and exception records can be handled in GLPI's Assistance module, which follows ITIL practices for tickets, problems and changes. The team also builds the pre-deployment test pipeline and the signature and integrity checks on vendor packages. Which of these tools fits a given estate, and whether each capability works as the client needs, should be confirmed during scoping rather than assumed.
The evidence set is designed with the client's assessor in mind. ENISA's June 2025 guidance lists patch deployment logs with timestamps, responsible staff and affected systems, pre-deployment test results, approved change requests and vendor signature checks as examples, and DeployOpen maps each of these to a specific system and log source in the written scope. The documented exception process for patches that would do more harm than good is built as a formal record with the reasons, the compensating measures and the accepted residual risk, approved by a named role. Clients should ask for this evidence list in their quote and confirm with their supervisor or assessor that it matches what they expect. Ongoing support, upgrades and continuous testing are available as retainers once the initial build is accepted.
