What Article 21(2)(e) asks for and why it is hard in practice
Article 21(2)(e) asks an essential or important entity to secure its network and information systems across their whole life cycle: when it acquires them, when it develops or customizes them, when it changes them and when it maintains them in operation. The point also covers vulnerability handling and disclosure, meaning the entity must find, track, fix and communicate weaknesses in the systems it depends on. Implementing Regulation (EU) 2024/2690 sets the detail for the providers it covers, and its Annex section 6 splits the measure into ten areas: acquisition of ICT services or products, secure development life cycle, configuration management, change management, security testing, patch management, network security, network segmentation, protection against malicious software, and vulnerability handling and disclosure. Confirm with your national competent authority which parts of the Annex it expects a non-covered entity to apply, since the regulation is written for specific service types.
The hard part is consistency. The entity's security rules have to hold when a supplier writes a product, when an internal team builds a feature, when a platform engineer changes a firewall rule and when an operations team applies an emergency fix at night. Each group often works in its own tool and under its own habits, so a rule that exists on paper may not be enforced in the pipeline. A useful first check is to trace one recent change, from the purchase or code commit through testing and release to the production record, and ask whether each step left evidence that a reviewer could follow.
Ownership is the second difficulty. Procurement, development, IT operations and security each hold part of the chain, and gaps tend to appear at the handoffs, such as a vendor patch that nobody scheduled or a test copy that still holds production personal data. Decide early who approves security requirements for acquisitions, who signs off on changes and who owns the vulnerability register, and write those decisions down. Teams that prepare for this measure often start by listing which of the ten areas already have a documented procedure, a named owner and recorded evidence, and which exist only as practice.
Which systems, teams and suppliers fall under secure acquisition and maintenance
Article 21(2)(e) follows the entity's network and information systems, not the org chart, so the scope question is which assets, code and suppliers touch those systems. The cards below cover the scoping decisions that change the work most, from in-house code and bought products to test data and legacy systems.
In-house applications and internal code
Applications your teams write, configure or extend are the clearest case for the development life cycle requirements in Implementing Regulation 2024/2690. Check whether every internal application that supports an essential or important service is in the register, who owns its backlog, and whether its specification, design and testing steps are written down. Scope should also cover scripts and internal tools that can change production data, since they are easy to leave out of reviews.
Purchased products and SaaS
Commercial software and SaaS services sit in scope because the entity still owns the security outcome of systems it runs. The acquisition requirements expect security requirements in the purchase, security updates for the product's lifetime or a replacement plan after end of support, and documented hardware and software components. Ask whether each contract states support end dates, update commitments and how delivered products are validated before go-live.
Infrastructure as code
Terraform, Ansible and similar definitions change production systems through the same pipeline as application code, so they belong in the development and change management scope. A misconfigured template can open a network path or weaken access controls across many systems at once. Confirm that templates are version controlled, reviewed before merge, scanned for insecure settings, and that drift between code and running systems is detected.
Third-party developers and integrators
External developers, integrators and managed service teams that write or change code for your systems fall under the same secure development expectations, even when they work in their own tooling. Your contracts and access arrangements should require them to follow your coding standards, testing steps and change approvals. Check who holds repository admin rights, how their access is revoked, and whether their releases pass through your review gates.
Legacy systems past vendor support
Systems that no longer receive vendor security updates are a recurring audit finding because the patch management and replacement expectations cannot be met as written. Scope these systems explicitly, record the compensating controls, network isolation and monitoring applied, and set a dated replacement or retirement decision owned by management. Ask whether the inventory shows end-of-support dates for operating systems, frameworks and embedded components.
Test environments holding production data
Staging and test systems often hold copies of production records, and the implementing regulation requires that test data be protected, sanitized or anonymized. Treat these environments as in scope with the same access control and logging you apply to production, unless the data has been replaced with masked or synthetic sets. Ask who can copy production data, how copies are tracked, and when they are deleted.
How the ten areas of section 6 fit together
The ten areas of section 6 of Implementing Regulation (EU) 2024/2690 are best read as one chain rather than ten independent checklists. The chain starts before any system exists: acquisition rules set the security requirements a product must meet, require security updates for its lifetime or a replacement after end of support, demand information on hardware and software components, and require validation of the delivered product against those requirements. If that gate is weak, every later control inherits the weakness, because the organization is patching or segmenting a component it never understood.
The next links are the build and the change. Secure development covers specification, design, coding, implementation and testing, and it extends to test data, which must be protected, sanitized or anonymized. Configuration management records how each system is set up, and change management then governs every release, modification and emergency change, with documentation and a risk-based decision on testing before anything goes live. Protected branches in GitLab Community Edition, which can block direct pushes and keep force pushes disabled, are one way to make the change path enforceable rather than a matter of habit. Confirm with your own engineering leads which change types bypass review in practice, because emergency changes are where the chain most often breaks.
The last links form a loop. Security testing and patch management feed the same backlog, and vulnerability handling and disclosure closes it by receiving reports from outside and routing them back into the change process. Network security, network segmentation and protection against malicious software limit what a flaw in one component can reach while the fix is pending. Ask one question to test the whole chain: for a critical vulnerability in a purchased product, can you name the owner, the approved change, the test evidence and the date it was closed? If any answer depends on memory, that is the gap to fix first.
How an assessor tests Article 21(2)(e)
This table sets out, for each of the ten areas under Article 21(2)(e), how an inspector or security auditor samples real changes and purchases, what evidence they request and where files commonly fall short. Read it as a pre-inspection checklist: the anchors in the implementing regulation's points 6.1.2, 6.2, 6.4.2 and 6.9.2 show what the assessor expects to see on file.
| Area (Annex section 6) | How the assessor tests it | Evidence requested | Common findings |
|---|---|---|---|
| Acquisition of ICT services or products (6.1.2) | Samples recent purchase files and contracts for ICT products and services, then checks security requirements were set before award. | Procurement files, security requirements, supplier contract clauses, validation records for delivered products. | Purchase files without security requirements; no check that delivered products met the stated requirements. |
| Secure development life cycle (6.2.1, 6.2.2) | Selects a sample of recent development work and traces specification, design, build and test for security activities. | Design notes, secure coding standards, threat considerations, test data handling procedures. | Production data copied into test environments without protection, sanitization or anonymization. |
| Configuration management (6.3) | Compares a sample of live systems against the documented baseline and asks who approves deviations. | Configuration baselines, hardening standards, configuration records, deviation approvals. | Systems in production that differ from the baseline with no recorded approval. |
| Change management (6.4.2) | Samples releases, modifications and emergency changes and follows each from request to closure. | Change tickets, risk assessments, test results, approvals, post-implementation review. | Emergency changes with no record, or records raised only after the change went live. |
| Security testing (6.5) | Checks that tests were planned, run before release and that findings were tracked to closure. | Test plans, scan reports, penetration test reports, remediation tracking. | Test results exist but high-risk findings are open with no owner or accepted-risk decision. |
| Patch management (6.6) | Compares patch dates against the entity's own timelines for a sample of critical components. | Patch policy, asset inventory, patch deployment logs, exception records. | Unsupported or end-of-life software in use with no documented exception or replacement plan. |
| Network security (6.7) | Reviews firewall rule sets and remote access configurations for a sample of systems and asks for the justification of each rule. | Rule sets, change history for rules, network diagrams, access review records. | Overly broad rules with no business justification or owner. |
| Network segmentation (6.8) | Tests whether a sample of zones are separated as documented, often by checking what can reach what. | Segmentation design, zone inventory, traffic rules, test results showing enforced separation. | Flat networks in practice, or documented zones that routing or rules do not enforce. |
| Protection against malicious software (6.9.2) | Checks deployment coverage on a sample of endpoints and servers and how detection software is kept current. | Coverage reports, update logs, alert handling records, detection tool configuration. | Endpoints or servers without protection, or signatures and rules months out of date. |
| Vulnerability handling and disclosure | Follows a sample of reported or discovered vulnerabilities from intake to fix and asks how external reports are received. | Vulnerability register, disclosure policy, triage records, fix verification, advisory records. | Reports received by email with no triage owner, no timelines and no record of closure. |
Implementing secure acquisition, development and maintenance in sequence
This sequence moves Article 21(2)(e) from supplier selection through development, change control, testing, patching, network controls and vulnerability handling, so each stage produces evidence that feeds the next. The order matters because later controls depend on the requirements and records set earlier.
Define acquisition security requirements and validate suppliers
Before buying or onboarding any ICT service or product, the organization writes security requirements into procurement, covering the security updates it expects over the product's lifetime or replacement after end of support, and asks for information on hardware and software components. Procurement and the security lead own this step. It is done when every delivered product is validated against those written requirements and the results are on file. Confirm the exact content of the acquisition requirements with the implementing regulation's Annex, point 6.1.2, before drafting your template.
Establish a secure development life cycle
For systems the organization builds or customizes, the development team documents how specification, design, development, implementation and testing are carried out, and applies secure coding principles at each stage. Test data must be protected, sanitized or anonymized so production personal or business data does not leak into non-production environments. The output is a written life cycle standard, a secure coding reference, and a test data rule that engineers can point to during reviews.
Set configuration and change management controls
Configuration baselines are defined for each system, and every release, modification and emergency change goes through a documented change process. Risk determines how much testing and assessment each change receives before it reaches production. Emergency changes are allowed but must still be recorded and reviewed after the fact. Open-source tools such as GitLab protected branches, which can block direct pushes and keep force pushes disabled, and GLPI's change management workflow can hold the record. The step closes when a sample of recent changes shows approval, testing and rollback notes.
Build security testing and patch management
Security testing is built into the delivery pipeline, with static analysis such as Semgrep Community Edition running on each repository to scan supported languages with community or custom rules. Results are triaged, and findings are tracked to closure. A patch management process then defines how security updates are assessed, scheduled and applied, with exceptions recorded. The output is pipeline scan reports, a patch register, and a list of open exceptions approved by the accountable owner.
Implement network security, segmentation and malware protection
Network controls are configured around the systems built in earlier steps, with segmentation separating development, test and production environments and restricting traffic to what each system needs. Protection against malicious and unauthorized software is deployed on endpoints and servers, and where appropriate, detection and response software is kept regularly updated. Infrastructure and security teams own this work. The check is a current network diagram, firewall or policy export, and malware protection coverage reports for in-scope systems.
Operate a vulnerability handling and disclosure process
The organization sets up intake for vulnerability reports from internal scanning, suppliers, researchers and customers, and assigns each report a severity, owner and remediation target agreed internally. Confirmed vulnerabilities feed back into the patch and change processes. A disclosure policy explains how the organization communicates with reporters and affected customers. The step is complete when a tracked case has moved from report to verified fix, with the record kept for the assessor. Ask your counsel or supervisor to confirm any disclosure obligations that apply to your sector.
Which evidence passes for each part of the life cycle
Acquisition evidence shows that security was considered before a product or ICT service entered the environment, and that the delivered item was checked against what was asked for. An assessor will usually start with a sample of recent purchases or onboarded components and trace each back to its requirements and validation record. ENISA's June 2025 guidance gives examples of the evidence a supervisor may expect here, and it is the best reference for the exact artifacts to prepare.
- Security requirements per procurement: a dated requirements statement for each significant acquisition, covering security functions, update commitments and integration constraints.
- Support and update commitments: vendor statements showing security updates for the product's expected life or a documented replacement plan after end of support.
- Component inventory: hardware and software bills of materials or equivalent lists supplied with each delivery.
- Delivery validation: signed acceptance tests or checklists showing the delivered product was checked against the stated requirements.
- Refresh cadence: a register of contract renewals and end-of-support dates, reviewed on a fixed schedule so expiring products are caught early.
Before an audit, sample three or four recent acquisitions and confirm each one can be traced from requirement to validation without relying on memory.
For systems built or customized in-house, the assessor looks for a documented secure development life cycle and proof that it was followed. Evidence should show each phase from specification through testing, that secure coding principles were applied, and that test data was handled so that real personal or confidential data did not leak into non-production environments. The records should come from the tools the teams already use, not from documents written for the audit.
- Life cycle standard: a written development procedure covering specification, design, development, implementation and testing.
- Review records: merge request approvals and design review notes showing security checks at defined points.
- Scan output: static analysis results from pipeline runs, with findings triaged and the disposition recorded.
- Test data rules: a procedure for masking, sanitizing or anonymizing data used in test environments, plus logs of data refreshes.
- Training and standards: records that developers were briefed on the secure coding standard adopted.
Keep pipeline histories and approval logs for the full period the supervisor may review, and confirm with your authority how long that period is.
Change evidence proves that releases, modifications and emergency changes were documented and, based on risk, tested and assessed before they reached production. Assessors commonly compare the change log with production deployment records to find changes that bypassed the process. Emergency changes are a frequent gap, so they need their own trail showing a retrospective review.
- Change tickets: each release or modification linked to a request, risk assessment and approver.
- Protected branch settings: exported configuration showing who can push or merge to protected branches, and that direct pushes and force pushes are restricted. The GitLab documentation on protected branches describes these controls.
- Test and assessment results: evidence of testing scaled to the change risk, attached to the ticket.
- Emergency change log: records with the reason, the approver and a post-implementation review.
- Configuration baselines: versioned configuration files that show what changed between releases.
Reconcile the change tickets against deployment logs each quarter so that gaps are found by you, not by the assessor.
Patch and scan evidence shows that the organization knows what is installed, what is vulnerable, and how quickly it acted. Assessors look for a current asset-to-patch linkage, the rules used to prioritize patches, and records that show the timing was followed. Security testing and malicious software protection also produce records here, because a scan that never ran is as much a gap as an unpatched system.
- Patch register: a list of patches applied per system with dates, the source and the approver.
- Prioritization rules: a written approach for ranking patches by severity and exposure, applied consistently.
- Scan schedules and results: pipeline or scheduled scan reports for code and infrastructure, with exceptions recorded.
- Endpoint protection status: reports showing regularly updated detection software is deployed and current, where appropriate for the environment.
- Exception approvals: documented, time-limited risk acceptances for patches that cannot be applied.
Run a monthly check that every production system appears in the patch register, because systems missing from the register are the most common finding.
Vulnerability handling and disclosure evidence shows that the organization receives reports, assesses them, fixes them and tells the right parties. The assessor will ask for a published or internal disclosure policy, a log of reports received, and proof that each was triaged and closed. The log should show time to decision and the outcome, not only the final status.
- Disclosure policy: a documented policy describing how external reporters can contact the organization and what they can expect.
- Vulnerability register: a ticketed record for each reported or discovered vulnerability, with severity, owner and fix status.
- Triage decisions: records of accepted, rejected or deferred reports with the reasoning.
- Advisories and notices: copies of customer or public notices issued after a fix.
- Coordination records: correspondence with vendors and other affected parties when a fault sits in a shared component.
Test the process once a year with a tabletop exercise, and keep the exercise report with the register so the evidence shows the process works as written.
What meeting Article 21(2)(e) costs in money and effort
This table lists the cost components of meeting Article 21(2)(e), who is paid for each, whether it is one-time or recurring, and what pushes it up or down. Read it as a checklist for building a quote, because the largest recurring costs usually come from release frequency and the number of systems in scope rather than from tooling licenses.
| Cost component | One-time or recurring | Who is paid | What drives it up or down |
|---|---|---|---|
| Tooling and licenses | Recurring | Software vendors or no one for open-source tools | Number of repositories and seats; self-hosted community editions remove license fees but not hosting or administration |
| Pipeline and access controls setup | One-time, then recurring upkeep | Internal engineers or an implementation partner | Number of branches, repositories and approval roles; complexity of protected branch rules and emergency change paths |
| Secure development process design | One-time | Internal engineering leads or an external consultant | Number of development teams and languages; whether a secure coding standard already exists |
| Change records and ticket workflow | Recurring | Internal change managers and developers | Release frequency and the number of emergency changes; how much testing evidence each change must carry |
| Security testing and code scanning | Recurring | Internal staff, tool hosting, or an external tester for periodic testing | Lines of code, languages scanned, scan frequency in CI/CD, and depth of external penetration testing |
| Vulnerability handling and disclosure process | One-time setup, recurring operation | Internal security and engineering staff, sometimes an outside response team | Size of the software estate, number of third-party components, and disclosure volume |
| Patch and update tracking for acquired products | Recurring | Internal IT operations and vendors | Number of products, vendor support lifecycles, and how often patches must be validated before rollout |
| Evidence upkeep and sampling readiness | Recurring | Internal compliance staff, plus advisors if used | Frequency of supervisory or audit requests, retention periods, and how well evidence is collected automatically |
Which open-source tools produce the evidence for each area
Source control is often the first place an assessor looks for change management and secure development evidence, because it records who changed what and when. GitLab Community Edition (MIT) offers protected branches, which let maintainers restrict which roles can push or merge to a branch. Used well, these settings show that production code only moves through reviewed merge requests and not through ad hoc pushes.
- Push restrictions: Setting push access to no one on a release branch blocks direct pushes, so every change must pass through a merge request.
- Merge roles: Limiting merge rights to named maintainers creates a record of who approved each release.
- Force pushes: Keeping force pushes disabled on protected branches preserves the commit history an assessor samples.
- Exported settings: Screenshots or configuration exports of branch protection rules show the control design at a given date.
- Merge request history: Review comments and approvals form the testing and assessment record for each change.
Confirm for your own GitLab version which protected branch settings are available on your tier, and whether approval rules and audit events are included in the edition you run.
Semgrep Community Edition (LGPL-2.1-only) scans source code for defects and insecure patterns and can run inside CI/CD pipelines so that each change is checked before it is deployed. Its supported languages include C/C++, C#, Go, Java, JavaScript, TypeScript, Python, Ruby, Rust, PHP, Kotlin, Swift and Terraform. This supports the security testing and secure development points of Article 21(2)(e), provided findings are triaged and tracked.
- Pipeline logs: Job output from each pipeline run records that scanning occurred for a given commit.
- Rule sets: Community or custom rules, versioned in the repository, show what the scanner was configured to detect.
- Infrastructure as code: Terraform scanning covers configuration that defines the production environment.
- Finding triage: Recorded decisions on each finding, including accepted risks and fixes, show that results were acted on.
- Coverage gaps: Languages not on the supported list need another method, which the record should state.
Confirm which rules, languages and pipeline integrations your Community Edition version supports, and whether any features you need are limited to a commercial license under the same tool.
GLPI (GPL-3.0-or-later) provides an Assistance module where users create, follow and process tickets, problems and changes following ITIL practices. For Article 21(2)(e), it is the record that links a requested change to its approval, testing and rollback decision. Emergency changes, which the implementing regulation expects to be documented, also need a traceable ticket.
- Change records: Each change ticket can hold the request, risk assessment, approver and implementation date.
- Problem records: Recurring defects or vulnerabilities can be tracked as problems until root cause and fix are confirmed.
- Emergency changes: A separate ticket path shows which changes bypassed normal approval and who authorized them.
- Planning and statistics: Reports on change volume and backlog support management review.
- Recurring tickets: Scheduled tickets can evidence periodic reviews such as patch cycles.
Confirm how your GLPI version models changes and problems, which approval workflow it supports, and whether the ticket fields you need can be enforced rather than only recommended.
Zammad (AGPL-3.0-only) is a web-based helpdesk that brings email, chat, telephone and social media messages into one ticket system. For vulnerability handling and disclosure, it can hold the inbound reports from researchers and customers, along with the outbound correspondence that acknowledges, updates and closes each case. That correspondence is often the evidence an assessor asks for when testing whether external reports are received and handled.
- Intake channel: A dedicated address for vulnerability reports keeps external reports in one queue.
- Case history: Every reply and internal note is retained with timestamps.
- Linked work: Teams can reference the GLPI change or problem ticket that fixes a reported issue.
- Disclosure timing: The case record shows when a report was acknowledged, triaged and closed.
- Access records: Role-based access limits who can read sensitive reports.
Confirm how your Zammad installation handles retention, access controls and any integration with your other ticketing system, and review the AGPL-3.0-only terms with counsel if you plan to modify the software and offer it to users over a network.
Where organizations usually fall short on secure maintenance
The gaps below cluster around the life cycle of a system: what is bought, how it is built and tested, how it is changed, how it is patched, and how outsiders report flaws. Each one is easy to miss because the work looks routine until an assessor asks for the record that proves it happened. The fixes are mostly process decisions that the organization owns, with tooling that generates the evidence.
No security requirements in purchase files
Procurement often buys software, hardware and managed services against functional requirements alone. Article 21(2)(e) expects security to be part of acquisition, and the implementing regulation asks that acquisition processes cover security requirements, security updates for the product's lifetime or replacement after end of support, and information on hardware and software components. To close the gap, add a standard security annex to every purchase template, require a software bill of materials and an end-of-support date in the bid, and record a validation step that checks the delivered product against those requirements before payment.
Production data copied into test environments
Teams often clone production databases to reproduce bugs or load-test releases, which moves personal and confidential data into systems with weaker access controls. The implementing regulation requires that test data be protected, sanitized and anonymized. Close the gap by banning raw production copies in non-production environments, generating synthetic or masked datasets through a documented pipeline, and checking test environments for leftover production records during each release review.
Emergency changes without after-the-fact records
Urgent fixes are frequently applied directly on production, with the ticket written days later or never. The implementing regulation covers emergency changes explicitly: they must be documented and, based on risk, tested and assessed before implementation. Close the gap by defining an emergency change path in the change procedure, requiring a ticket number before the change window opens, and holding a review within a fixed period after the fix to record testing, approval and rollback notes. A helpdesk or ITSM tool such as GLPI can hold the change record.
Unpatched end-of-support components
Systems keep running after their vendor stops issuing security updates, often because a legacy application depends on them or no owner tracks the support date. Patch management and the acquisition rules both point to the same fix: maintain an inventory with support end dates, assign an owner to each component, and set a replacement or isolation decision before support lapses. Where replacement is not possible, document the compensating controls, such as network segmentation and restricted access, and the risk acceptance signed by management.
Unreviewed code entering production
Code often reaches production through direct pushes, unreviewed merges or hotfix branches that bypass the normal pipeline. Secure development requires that specification, design, development, implementation and testing follow secure coding principles, and the evidence is a record of who approved each change. Close the gap by protecting main branches so that direct pushes and force pushes are blocked, requiring a reviewer other than the author, and running a static analysis scan such as Semgrep Community Edition in the pipeline so that findings are recorded before merge.
No channel for vulnerability reports
Security researchers, customers and partners who find a flaw often have no published way to report it, so reports land in sales inboxes or get posted publicly. Article 21(2)(e) explicitly includes vulnerability handling and disclosure. Close the gap by publishing a security contact and disclosure policy on the organization's website, routing reports to a monitored queue with a named triage owner, and recording each report through to a fix or documented risk decision. Confirm response expectations with legal and the product owners before publishing them.
Questions buyers ask about Article 21(2)(e) cost, effort and outsourcing
How much effort does Article 21(2)(e) take in-house?
Most of the effort sits in the engineering and change processes that already exist, not in writing new documents. Article 21(2)(e) covers ten areas in the implementing regulation: acquisition, secure development, configuration management, change management, security testing, patch management, network security, network segmentation, malicious software protection, and vulnerability handling and disclosure. The effort depends on how many systems you run, how many teams release software, and how much of that work is already recorded. Organizations with mature ticketing, code review and release records usually need to tie evidence together rather than create it. Organizations without them should expect the larger share of effort in building the processes first. No effort figure is given here because none was supplied; ask your advisor to estimate it from an inventory of your systems and release pipelines.
Is self-hosted open-source tooling enough to produce the evidence?
Open-source tools can produce much of the evidence, but they do not decide whether your process is adequate. For example, GitLab Community Edition provides protected branches that restrict who can push or merge and that keep force pushes disabled unless explicitly allowed. Semgrep Community Edition can scan code in many languages and run in CI/CD pipelines. GLPI's Assistance module can track changes following ITIL practices, and Zammad can hold vulnerability and customer-facing ticket trails. Each tool covers a slice of the ten areas. You still need written policies, risk-based decisions on what to test and when, and records that show validation of delivered products. Confirm each tool's features against your version and your environment before relying on it.
What does a partner do, and what does the auditor do?
A partner prepares the systems, controls and evidence, and the organization keeps ownership of its controls and decisions. DeployOpen, for example, plans, implements, configures, hardens and documents self-hosted platforms in your environment, and can run security testing. It does not issue audit reports, attestations or certifications. Supervision under NIS2 is carried out by national competent authorities, which inspect, scan, audit and request information, and NIS2 creates no certificate of compliance. Any independent assessment you commission for contractual or customer reasons is performed by a separate independent auditor or certification body. Ask each party in writing which deliverables they own.
What does the work need from management and engineering?
Management must approve the measures and accept the residual risk, and engineering must run the processes day to day. Under NIS2, the management body approves and oversees the Article 21 measures, so leadership needs to sign off on acquisition rules, change approval thresholds and the vulnerability disclosure process. Engineering leads must define secure development practices, test data handling and emergency change procedures, and must agree who can merge or deploy to production. Ask your partner to show which decisions require a named executive and which require an engineering owner, and set those owners before work starts.
What determines how long preparation takes?
Preparation length is driven by dependencies, not by a fixed duration. The main dependencies are the completeness of your system inventory, the state of your code review and release records, whether your suppliers will provide update commitments and component information, and how quickly management can approve policies. Long lead items include supplier contract changes and any tool migration that requires change windows. No timeline is given here because no researched duration was supplied; ask for a plan that lists each dependency and who controls it.
How should I scope a fixed-scope engagement for this measure?
Start by listing the in-scope systems, the teams that release them, and the ten Article 21(2)(e) areas you want covered. DeployOpen works mostly on fixed-scope engagements, where scope, deliverables and timelines are agreed in writing before work starts. A useful scope names each system, each repository or pipeline, each supplier that delivers software or services, and the evidence each deliverable will produce. Exclusions should be written down, such as systems owned by a third party. Ask for a quote that follows from this written scope, and check whether ongoing support or continuous testing is priced separately as a retainer.
What recurring costs should I plan for after the first implementation?
Recurring costs come from keeping the process running, not from the first build. These include tool upgrades, patch and vulnerability handling work, periodic security testing, supplier reassessment, and the review cycle for policies and change records. Some organizations also keep a retainer for support or continuous testing. The one-time costs are the initial design, configuration and documentation. Ask any provider to split its quote into one-time and recurring items so you can see the ongoing commitment before you sign.
How DeployOpen scopes and prepares evidence for this requirement
DeployOpen plans, implements and documents self-hosted open-source pipelines, change tooling and vulnerability workflows inside your own infrastructure, whether that is your cloud accounts, data center or air-gapped network. The work usually runs under a fixed-scope written agreement that names the systems in scope, the Implementation Regulation areas covered (acquisition, secure development, change management, testing, patching, segmentation, malicious software and vulnerability handling), the deliverables and the timeline before any work starts. DeployOpen prepares the systems, procedures and evidence that your organization will present to its national competent authority or an independent assessor. It does not issue audit reports, attestations or certifications, and it does not decide whether your controls are adequate. Your management body still owns the Article 21 measures and approves the decisions behind them.
In practice, scoping starts with an inventory of the code repositories, pipelines, ticketing tools and software suppliers that carry changes into production, followed by a decision on which of them are in scope for NIS2. The written scope should state who approves changes, which environments are protected and how exceptions are recorded. Ask any implementation partner to show, for each area, the configuration it will produce, the record it will generate and the person who signs off on it. Security testing of applications, APIs and infrastructure can be included as a separate fixed-scope engagement, so that test results feed the secure development and vulnerability handling evidence rather than sitting in an unrelated report.
Many organizations need support after the first delivery, because evidence must keep being produced as releases, dependencies and suppliers change. DeployOpen offers ongoing retainers for upgrades, continuous testing and support of the platforms it has implemented. Before signing, confirm with any provider what the retainer covers, how changes to the scope are priced and documented, and who in your organization keeps ownership of the repositories, runners and ticket queues after handover. Confirm with your national authority or sector regulator which evidence formats it accepts, since the expected level of detail can differ between Member States.
