What Article 21(2)(f) asks you to prove about your security measures
Article 21(2)(f) requires policies and procedures to assess whether your cybersecurity risk-management measures actually work. Having a written policy is not enough. A compliance lead or CISO has to show that the controls behind each policy are implemented, kept running and producing the result the policy intends. Commission Implementing Regulation (EU) 2024/2690 turns this into a concrete set of decisions. You must decide which measures, processes and controls to monitor, which methods to use, when measurement happens and results are analyzed, and who does the measuring and who evaluates the results. The regulation also asks you to check that measures are maintained over time, not only installed once.
The regulation ties this measurement to two inputs: your risk assessment and any past significant incidents. Results must then feed the choice of risk treatment measures, and they must reach the management body together with the results of independent review. That reporting line matters, because the management body remains accountable for approving and overseeing the Article 21 measures. Confirm with your own legal and governance teams how management receives these results, how often, and in what form, and record the answer in the effectiveness policy itself.
In practice, effectiveness measurement is often the weakest part of a program. Metrics are missing for some controls, nobody owns the measurement of others, and the results never get compared with the risk register or with what went wrong in the last significant incident. A useful first step is to list every control your risk assessment relies on, name an owner for measuring each one, and check whether the data needed already exists in your tooling. Open-source platforms such as Wazuh and Fleet can produce some of that evidence from endpoints, and CISO Assistant can record the assessments and link them to the frameworks you report against, but each still needs a named owner and a defined review cycle.
Which systems, processes and teams fall under effectiveness measurement
Implementing Regulation 2024/2690 leaves the entity to decide what gets monitored, how, when and by whom. The decisions below set the size of that work, and each one changes which systems, suppliers and people the program has to cover.
Choosing which measures and controls to monitor
Not every control needs continuous measurement. Start from the Article 21 measures your entity has adopted and select the controls whose failure would most affect service delivery or incident exposure. For each selected control, record the measurement method and the evidence it produces. Ask whether each measure is implemented and maintained, not only whether a policy exists. A narrow list keeps the program maintainable, but it must still cover every Article 21(2) area the entity claims to manage.
Setting priorities from the risk assessment
The implementing regulation requires the effectiveness assessment to take the risk assessment into account. Controls that protect the highest-rated risks deserve more frequent and more detailed measurement than low-rated ones. Review the risk register before setting the measurement calendar, and document why a high-risk area is measured less often, if it ever is. When the risk picture changes, such as a new service or a new threat, the measurement plan should change with it.
Learning from past significant incidents
Past significant incidents show where controls failed in practice. The implementing regulation requires these to inform the effectiveness assessment. For each incident, identify the control that should have prevented or detected it and add a measurement for that control. Incidents from suppliers, near misses and tabletop exercise findings can also qualify. Keep a link between each incident record and the measurement change it triggered so an assessor can trace the reasoning.
Including asset groups in scope
Decide which asset groups fall inside the measurement boundary: production identity systems, endpoints, cloud accounts, network devices and backup infrastructure are common candidates. Each group needs a named owner and a documented list of members. Assets left out of the boundary are still exposed, so record the reason for every exclusion. A current asset inventory is the practical starting point, because a measurement cannot be run against a system the entity does not know it operates.
Including suppliers and managed services
Measurement often stops at the entity's own estate. Where a managed service provider, cloud provider or software supplier operates part of a control, decide whether to measure it directly, rely on contractual reporting, or use the supplier's independent assurance. Each option produces different evidence and different workload. Confirm in the supplier contract what information the provider will supply and how often, before the measurement plan depends on it.
Separating the teams that measure from those that evaluate
The implementing regulation asks the entity to decide who measures and who evaluates. Operations teams usually run the checks and collect the data. A separate function, such as the security or compliance team, should evaluate the results and decide whether a measure is effective. Where the same person runs and judges a check, document the arrangement and add an independent review. Management receives the evaluated results, not the raw data, so the split should be clear in the RACI.
How an assessor tests whether measures are effectively implemented
This table compares what an assessor checks for the Article 21(2)(f) effectiveness policy, the evidence they ask for, and the findings that most often come up. Read each row as a question the assessor will put to the organization, then check whether the evidence exists and is current. The main takeaway is that a measurement plan on paper does not satisfy the requirement unless results are analyzed and reach management.
| Test area | What the assessor checks | Evidence requested and common findings |
|---|---|---|
| Policy and scope | Whether a written effectiveness policy exists and names the measures, processes and controls to be monitored and measured (Annex point 7.2) | Policy document, list of measured controls, link to the risk assessment. Finding: policy exists but covers only a few tools |
| Metric definitions | Whether each metric states what is measured, the method, the data source and the target state (Annex point 7.2) | Metric register with definitions and owners. Finding: metrics named without thresholds or data sources |
| Measurement schedule | Whether the organization set when measurement happens and whether it runs as planned (Annex point 7.2) | Calendar, run logs, timestamps of scans or reviews. Finding: schedule documented but runs missing for whole periods |
| Roles for measuring and evaluating | Whether the people who measure are separate from, or clearly named relative to, the people who evaluate results (Annex point 7.2) | RACI or role descriptions, sign-off records. Finding: no named evaluator for a metric |
| Analysis of results | Whether measured results are analyzed against the risk assessment and past significant incidents (Annex points 7.1 and 7.2) | Analysis records, trend notes, root cause entries. Finding: metrics collected but never analyzed |
| Coverage of past incidents | Whether measurement targets the controls that failed in past significant incidents and the risks in the current assessment | Incident-to-control link, post-incident review actions. Finding: measurement does not cover the control that failed |
| Feed into risk treatment | Whether effectiveness results change risk treatment decisions, such as new controls or reprioritized remediation (Annex point 2.1.3) | Risk register updates, treatment plans, decision minutes. Finding: results recorded but no treatment decision follows |
| Reporting to management | Whether results reach the management body with independent review results included (Annex point 2.3.3) | Management reports, meeting minutes, board packs with the independent review. Finding: results never reach management |
Implementing an effectiveness assessment process step by step
This sequence turns Article 21(2)(f) from a policy statement into a repeatable cycle: measure the controls that matter, analyze results against incidents, act on what the results show, and put the outcome in front of the management body.
Select the controls and metrics to measure
Start from the risk assessment and the list of measures your entity has adopted under Article 21. Decide which measures, processes and controls will be monitored, prioritizing those that address the highest-rated risks and the systems that would cause the most harm if they failed. For each one, write down the question it answers, such as whether a configuration is applied or whether access reviews happen on schedule, and the metric or yes/no test that answers it. The output is a measurement register that names each control, its metric, its owner and the risk it supports. Confirm that every risk rated high in the risk assessment has at least one measured control behind it.
Define methods, frequency and data sources
For each entry in the measurement register, decide how the measurement is taken: automated scanning, configuration queries, log review, sampling of records, tabletop exercise results or interviews. Set how often each measurement runs and when the results are analyzed. Note where the evidence comes from and how it is kept unchanged, so an assessor can repeat the measurement. Where a control cannot be measured automatically, record the manual method and the reviewer. The output is a documented methodology that states what is measured, how, when and where the evidence is stored. Ask your implementation partner or tool owner to confirm which data sources each tool can export for audit.
Assign who measures and who evaluates
Separate the people who run a measurement from the people who judge the result wherever your size and structure allow. Name a measurer for each control and an evaluator who reviews the outcome and decides whether the control is effectively implemented and maintained. Record the reporting line so that exceptions reach the security lead and, through them, the management body. The output is a role assignment table included in the effectiveness policy. Confirm that the people named have the access and skills to perform their part, and that the assignments are approved as part of the Article 21 governance.
Run measurements and record raw results
Execute the measurements as the methodology describes, on the schedule set in the previous step. Automated tools such as configuration assessment scanners or endpoint policy queries produce pass or fail results per device, and manual checks produce signed records. Keep the raw output, the date, the scope covered and any measurement that could not be completed. Do not edit results to improve them. The output is a dated set of raw results per control, stored with the evidence. Confirm that the scope of each run matches the asset inventory, because a measurement that skips systems will overstate effectiveness.
Analyze results against risk and past incidents
Compare the results with the risk assessment and with significant incidents recorded in the period. The implementing regulation asks entities to take both into account, so for each failed or partly met control, determine whether the gap relates to a risk that has materialized, to an incident that exposed the control, or to a trend across several runs. Record the root cause where known and the affected systems. The output is an analysis note per control that states the result, its link to risk and incidents, and the recommended action. Confirm that every significant incident in the period has been checked against the measured controls.
Feed results into risk treatment decisions
Take each finding and decide the response: accept the residual risk with a recorded justification, mitigate by changing or adding a control, transfer part of the risk, or avoid the activity. Update the risk register and, where a control is changed, the measurement register so the next cycle tests the new design. The output is a risk treatment record for each finding with an owner and a status. Confirm that open findings are tracked to closure and that changes to controls are reflected in the policies they belong to.
Report to management and include independent review
Prepare a summary for the management body that shows the measured controls, the trend of results, significant gaps, the incidents that tested the controls and the risk treatment decisions taken. Under the implementing regulation, this report must reach the management body together with the results of independent review, so attach or reference the latest independent review of the measures. The output is a dated management report and a recorded decision or minutes showing that the body reviewed it. Confirm with your own governance and legal advisers which decisions the management body must formally approve.
Close the cycle and update the policy
Review whether the measurement register, methodology and role assignments still fit the current risk assessment, the systems in scope and any changes made during the cycle. Update the effectiveness policy and procedures where they no longer describe what happens, and set the date for the next run. The output is a revision history for the effectiveness policy and an updated measurement plan for the next cycle. Keep the records of every completed cycle, since an assessor will ask for evidence that the process has run more than once and that its results changed decisions.
Evidence that shows measures are working and stays current between audits
Article 21(2)(f) is only satisfied when the organization can show a recurring cycle of measurement, analysis, reporting and review, not a single report prepared for an inspection. The six artifacts below form that cycle, and each one should be produced by the normal operation of the program so it stays current between audits.
Effectiveness policy and procedure
This document names the measures, processes and controls to be monitored, the measurement methods, the frequency of measurement and analysis, and who measures and who evaluates. Check that it covers all Article 21 measures in scope, not only the technical ones, and that the owner has approved it through the management body. Review it on a fixed cycle and after any significant incident, and record each version with its approval date so an inspector can see what applied at any point.
Metric and measurement definitions
Each metric needs a written definition: what is counted, the data source, the calculation, the target or threshold, and the owner. For example, a metric on the share of endpoints with a failing configuration check needs a stated population and a scan source, so two people produce the same number. Store definitions under version control next to the policy, and log every change so trend lines remain comparable across periods.
Dated measurement results with owners
Raw results from scanners, configuration checks and access reviews should be exported on schedule with a timestamp, the scope covered and the named measurer. Automated tools reduce manual effort here: Wazuh Security Configuration Assessment compares monitored endpoints against YAML policies, and Fleet policies show which devices pass or fail each query. Confirm that exports are retained long enough to cover the period an assessor may review, and that failed checks carry a recorded decision or remediation ticket.
Analysis records linked to risk and incidents
The implementing regulation expects effectiveness to be judged against the risk assessment and past significant incidents. Each analysis record should cite the risk entries it tests, the incidents it considered, and the conclusion reached about whether a measure works. Link these records in the GRC tool, for example through CISO Assistant, where assessments and evidence can be tied to framework requirements, so an assessor can trace a measure from result to risk to decision without manual compilation.
Management reports and risk treatment decisions
Effectiveness results must reach the management body, which approves the outcome and the risk treatment choices that follow. The report should show trends, open gaps, decisions taken and the resources requested, and it should be generated from the same stored results rather than rebuilt by hand. Keep the approval minutes with the report. Ask your competent authority whether it expects a particular format or cadence, because ENISA's June 2025 guidance gives examples of evidence that you should check against your national rules.
Independent review records
Independent review, whether an internal audit function or an external assessor, provides the outside check on whether measurements are sound and results are reported accurately. Record the scope, the reviewer's independence, the findings, and the response to each finding with its due date. Only the independent reviewer issues an assessment report. An implementation partner can prepare the review inputs, but it cannot give the independent conclusion itself.
Open-source tools that produce effectiveness evidence
CISO Assistant is a governance, risk and compliance platform that records your controls, assessments and audits against a large library of frameworks, including NIS2. It does not test systems itself. Its value for effectiveness measurement is that it gives you one place to record what you decided to measure, who assessed it, what the result was and which framework requirement the result relates to, so that management reporting and risk treatment decisions can be traced. The project is licensed under AGPL-3.0-only.
- Assessment records: Store assessment results per control with dates, assessors and status, so you can show when a measure was last evaluated.
- Framework mapping: The project states it ships more than 200 frameworks and supports automatic mapping between them. Confirm the mappings for NIS2 against the ENISA guidance before relying on them.
- Audit trail for management: Use recorded results and open findings as the input for reports to the management body and for risk treatment decisions.
- Limits: The platform holds what your people enter. It does not verify that a configuration is in place unless you connect it to evidence from other tools.
- License: AGPL-3.0-only. Review the license terms with counsel if you plan to modify and offer the software to others.
Confirm with your own environment whether CISO Assistant's current features, hosting model and integrations meet your reporting needs, and whether recorded assessments alone satisfy your effectiveness policy.
Wazuh's Security Configuration Assessment (SCA) module scans monitored endpoints against YAML policies and reports which checks pass or fail. The policies are shipped mostly based on CIS benchmarks and can be extended with custom policies. Each check can look at files, directories, registry keys and running processes, and the module recommends remediation for failed checks. The project is licensed under GPL-2.0-only.
- Pass and fail results per endpoint: Produces machine-generated evidence that a configuration was checked at a given time, which supports the claim that a measure is implemented.
- Custom policies: Write YAML checks for settings specific to your environment, such as internal hardening baselines.
- Remediation guidance: Failed checks include recommended fixes, which helps link findings to corrective action.
- Limits: Checks reflect the policy content. A passing result on a benchmark does not prove that the control matches your risk assessment. Coverage depends on which endpoints are enrolled.
- License: GPL-2.0-only. Confirm how the license applies to your distribution and internal use.
Confirm with your own environment which operating systems and policies you need, how results will be retained for supervisors, and whether these scan results on their own satisfy the policy you have documented.
Fleet policies are yes or no questions asked of devices as osquery queries. The policies page shows which devices in each fleet are passing or failing each policy. This gives you a current, device-level view of specific conditions, such as whether disk encryption is enabled or a supported OS version is installed. The project is licensed under MIT.
- Pass and fail by device: Shows which devices meet each condition, which is useful for tracking remediation over time.
- Targeted questions: Each policy tests one condition you define, so you can align policies with specific measures in your risk assessment.
- Remediation tracking: Failing devices give you a worklist and a record of when a gap was closed.
- Limits: A policy answers only the question you wrote. It does not test whether the measure is effective against an attack, and it reflects only devices that report in.
- License: MIT, which permits broad use with the license notice kept intact.
Confirm with your own environment which conditions you need to test, how often results are sampled, and how you will show that failing devices were handled, since policy results alone may not satisfy the effectiveness requirement.
What measuring control effectiveness costs in money and effort
This table lists the cost components of measuring whether Article 21 measures work, who is paid for each, whether it is one-time or recurring, what drives it up or down, and what to ask for in a quote. No prices or durations are given because none are supported by researched facts, so use the table to structure vendor and partner quotes against your own scope.
| Cost component | Who is paid | One-time or recurring | What drives it, and what to ask for in a quote |
|---|---|---|---|
| Tooling or licenses | Software vendor or cloud provider | Recurring for commercial tools, one-time setup | Number of endpoints and systems in scope. Self-hosted open-source tools such as CISO Assistant (AGPL-3.0-only), Wazuh (GPL-2.0-only) and Fleet (MIT) remove license fees, but hosting, storage and staff time remain. Ask for the total cost of ownership, including infrastructure. |
| Engineering time to define metrics and automate checks | Internal engineers or an implementation partner | One-time, with periodic revision | Number of controls and the depth of automation. Ask the partner to list each measured control, the method, the data source and the owner, and to state which checks run automatically. |
| Configuration of security assessment and policy checks | Internal engineers or an implementation partner | One-time, then recurring tuning | Number of custom policies needed beyond vendor baselines, such as CIS-based Wazuh policies or Fleet osquery policies. Ask who maintains policies after handover and how false results are reviewed. |
| Recurring evidence upkeep | Internal compliance or security staff | Recurring | Frequency of measurement, number of owners and whether results are stored in a tool or spreadsheets. Ask how evidence is collected, dated, retained and linked to the risk register. |
| Management and independent review inputs | Internal audit function or an external reviewer | Recurring | Whether the review is internal, external or both, and how often results go to the management body. Article 21(2)(f) results must reach management together with independent review results, so ask who prepares those reports. |
| External testing that checks effectiveness | Testing firm or implementation partner | Recurring, scheduled by scope | Scope of systems tested, the testing type and the number of test cycles per year. Ask for a fixed scope, written deliverables and a retest approach. |
| Auditor or supervisor sampling effort | Internal staff who produce samples, auditor for testing | Recurring with each assessment | Sample size and the number of periods the auditor covers. Clear, dated records reduce the time staff spend answering requests. Ask the auditor for the sampling method before fieldwork starts. |
| Remediation of gaps found by measurement | Internal engineering or operations teams | Recurring as findings arise | Volume and severity of findings and the speed of the fix process. Ask the partner how measurement results are linked to remediation tickets and risk treatment decisions. |
Where organizations fall short on effectiveness assessment
Most organizations that run security checks still cannot show that their Article 21 measures work. The gaps below share one root cause: measurement is treated as a reporting exercise rather than a decision input. Each card names a gap and a concrete way to close it, so the assessment produces results that management can act on.
Measuring activity instead of outcomes
Teams often report how many scans ran, how many tickets closed or how many training sessions were held. Article 21(2)(f) is about whether the measures actually work, so these counts prove activity, not effectiveness. To check this, ask for each metric what decision it would change if the value moved. Replace at least one activity count per measure with an outcome, such as the share of internet-facing hosts with no open critical misconfigurations at the last scan.
Metrics with no named owner
A metric that belongs to a team rarely gets reviewed by anyone. Under the implementing regulation, the policy must say who measures and who evaluates, and those roles should be different people where possible. For each metric, record the measuring owner, the evaluating owner, the collection frequency and the date of the last review. A metric without all four fields should not appear in the management report.
Results not checked against past incidents
Effectiveness assessment must take into account the risk assessment and past significant incidents. Many programs run the same tests every year and never compare them with what actually went wrong. Keep a register that maps each significant incident to the measure that failed or was bypassed, then add a test or metric that would have detected that failure. Illustrative example: if a phishing incident succeeded through an unmonitored mailbox rule, the next assessment should check mailbox rule monitoring directly.
No link to risk treatment decisions
Assessment results should drive which risk treatment measures are chosen next, but in many organizations they sit in a dashboard with no decision attached. Hold a short review after each assessment cycle where each finding is recorded as accepted, mitigated, transferred or escalated, with the reason. Keep the link visible in the risk register so an assessor can trace a failed test to a funded corrective action and a follow-up test.
Management never sees the results
Article 20 places approval and oversight of the Article 21 measures with the management body, and the implementing regulation expects effectiveness results to reach management. Where results stop at the security team, the board cannot oversee them and cannot be shown to have done so. Confirm that a summary of metrics, open findings and trends goes to the management body on a set schedule, and keep the minutes that show it was discussed and what was decided.
No independent review of the assessment
When the same team designs the metrics, runs the tests and grades the results, the assessment can miss its own blind spots. The implementing regulation pairs effectiveness results with independent review results when reporting to management. Assign a separate reviewer, such as internal audit or an external assessor, to sample the evidence, challenge the metric definitions and test a subset of controls directly. Record the reviewer's findings alongside the internal results.
Who owns effectiveness measurement, who helps, and who must stay independent
The entity owns its cybersecurity risk-management measures, and that includes deciding how their effectiveness is measured. Under Implementing Regulation (EU) 2024/2690, the entity must decide which measures, processes and controls are monitored, the methods used, when measurement happens and results are analyzed, and who measures and who evaluates. Those decisions belong to the organization even when tools and people from outside do the work. The management body approves the measurement program and reviews the results that come out of it.
- Program decisions: Set the scope of measured controls, the metrics for each, the measurement frequency and the owners who measure and evaluate.
- Management review: Present effectiveness results to the management body, with the independent review results, so that decisions on risk treatment are documented.
- Action on findings: Assign remediation owners and deadlines for failing controls, and record why any finding was accepted without fixing it.
- Policy ownership: Maintain the effectiveness policy as a documented, approved and current policy that reflects the risk assessment and past significant incidents.
- Evidence retention: Keep the measurement outputs, reviews and decisions in a form a supervisor can inspect.
Before engaging any outside party, confirm internally who holds each of these decisions and who will sign off the measurement program.
An implementation partner can prepare the systems and evidence that make measurement possible. DeployOpen, for example, plans, implements, configures and documents self-hosted open-source platforms inside the client's own infrastructure, and it can set up the tooling that gathers and reports effectiveness data. The partner does not decide the organization's risk appetite, approve the program or determine whether controls are effective in an audit sense. Those judgments stay with the organization and, where applicable, with an independent assessor.
- Tooling setup: Deploy and configure configuration assessment and policy compliance tools in the client environment, such as a configuration checker with custom policies or a device query platform.
- Metric automation: Build the collection, dashboards and reporting that feed management reviews, so results are produced on the schedule the organization set.
- Testing support: Help plan and run technical testing that supports effectiveness checks, such as security testing of applications, APIs and infrastructure, and document the results.
- Documentation: Write runbooks, measurement procedures and evidence maps that show how each metric is produced.
- Limits of the role: Partner outputs are inputs to the organization's review. They are not audit reports or certificates.
When requesting a scope, ask the partner to state in writing which deliverables it prepares and which decisions remain with the client.
Independence is the point where an external party's role changes from helping to assessing. NIS2 creates no certificate of compliance. National competent authorities oversee compliance through inspections, security audits, security scans, information requests and administrative fines. Where an organization uses an independent review or an audit to support its own assessment, the reviewer must be separate from the people who designed and operated the measures. Only an independent auditor, assessor or certification body issues reports or certificates. DeployOpen does not issue audit reports, attestations or certifications.
- Separation of roles: The party that configured the monitoring should not be the only party that judges its results.
- Independent review input: Implementing Regulation 2024/2690 requires that independent review results are reported to management with effectiveness results.
- Scope of the review: Agree with the reviewer which measures, periods and evidence it will examine before fieldwork begins.
- Supervisory expectations: Confirm with the national competent authority which evidence it expects, since national transposition laws shape supervision.
- Reliance: Ask the reviewer which evidence it can rely on and which it will test directly.
Before hiring any reviewer, confirm its independence rules, its qualifications for this scope and whether it will issue a formal report.
Questions buyers ask about assessing measure effectiveness
How much effort does assessing the effectiveness of cybersecurity measures take?
The effort depends on how many measures, processes and controls you decide to monitor, how many systems sit in scope, and how often you measure. Article 21(2)(f) does not set a fixed workload. Implementing Regulation (EU) 2024/2690 expects you to choose what to monitor and measure, the methods, the timing and who performs and evaluates the work. A narrow scope with automated checks on a small estate needs far less effort than a multi-site environment with manual control testing. Ask any provider to break its quote into the initial design of the measurement programme, the tooling set-up, the first measurement cycle and the recurring reviews, because each part behaves differently over time.
Can we assess the effectiveness of our measures in-house?
Yes, in most organizations the routine measurement can be run in-house, provided the people doing it are independent enough from the controls they check. The regulation distinguishes who measures from who evaluates, so the same engineer should not both configure a control and sign off that it works. Typical in-house work includes running automated configuration checks, collecting results and tracking remediation. Outside help is usually most useful for designing the measurement method, testing whether your chosen indicators actually reflect risk, and preparing the evidence set before a supervisor asks for it. Confirm internally who will hold the evaluation role before deciding what to outsource.
What does management need to do for effectiveness assessment?
Management must own the outcome, not just receive a report. Implementing Regulation (EU) 2024/2690 requires that effectiveness results feed the choice of risk treatment measures and are reported to the management body together with the results of independent review. In practice this means management approves the scope and metrics, receives periodic summaries of failing controls and open remediation, and decides which residual risks to accept. Article 20 of NIS2 makes the management body responsible for approving and overseeing the Article 21 measures, so the board cannot delegate the decision to act on weak results. Build a reporting cadence and an escalation threshold into your governance records from the start.
Are open-source tools enough to measure control effectiveness?
Open-source tools can produce much of the technical evidence, but they do not decide what to measure or prove that your indicators are meaningful. Wazuh Security Configuration Assessment checks monitored endpoints against YAML policies, mostly based on CIS benchmarks, and can be extended with custom policies that examine files, directories, registry keys and running processes. Fleet policies ask yes or no questions of devices as osquery queries and show which devices pass or fail each one. CISO Assistant, licensed under AGPL-3.0-only, ships more than 200 frameworks, including NIS2, and can run audits and assessments with automatic mapping between frameworks. Together they cover technical checks and the governance record. Confirm each tool's current capabilities in its documentation before you rely on it for a specific control.
What will an assessor or supervisor ask for first?
Expect requests that test whether the process exists and is followed, not only whether a tool was installed. Typical first requests include the effectiveness policy, the list of monitored controls with the reason each was chosen, the measurement methods and schedule, recent results with the named people who measured and evaluated them, and records showing that results reached management and fed risk treatment decisions. The ENISA June 2025 technical guidance gives examples of evidence and treats the effectiveness policy as one of ten topic-specific policies to document. Prepare a short index that links each requirement to the artifact that proves it, so you can answer quickly.
Does NIS2 issue a certificate for effective cybersecurity measures?
No. NIS2 creates no certificate of compliance. National competent authorities oversee compliance through inspections, security audits, security scans, information requests and administrative fines, as set out in Articles 32 to 34. Any certification you hold under another scheme is a separate matter and does not replace the supervisor's review of your effectiveness assessment. Ask your national authority which evidence it expects, and treat any provider offering a NIS2 certificate with caution, because only an independent auditor or certification body can issue a report or certificate and the directive itself does not provide one.
How do we decide which controls to measure first?
Start from your risk assessment and your past significant incidents, which Implementing Regulation (EU) 2024/2690 names as inputs to the effectiveness policy. Measure first the controls that protect the systems whose failure would cause the most harm, and the controls that failed in previous incidents or audits. Document the reason for each choice, because a reviewer will test whether the selection follows from your risk picture rather than from convenience. Review the list after every significant change to your environment, new service or incident. Illustrative example: an organization whose last incident involved stolen administrator credentials would reasonably measure privileged access controls before endpoint hardening, and would record that choice with its supporting analysis.
How DeployOpen scopes and prepares effectiveness evidence
DeployOpen is a Chainscore Labs company that plans and implements self-hosted open-source platforms inside the client's own infrastructure. For Article 21(2)(f), we prepare the systems, measurement routines and records that let the organization show whether its risk-management measures work, while the organization keeps ownership of its controls and management decisions.
How we scope
- Agree in writing which measures, processes and controls the effectiveness policy will monitor and measure.
- Record the measurement methods, the measurement frequency and the people who measure and who evaluate the results.
- Confirm which past significant incidents and risk assessment outputs will feed the measurement scope.
How we build
- Configure open-source tools such as CISO Assistant, Wazuh and Fleet to produce recurring measurement data for in-scope systems.
- Set up compliance assessments and policy checks that map results to the measures they test, after confirming each mapping with the client.
- Test that dashboards, reports and alerts reproduce the results accurately before the client relies on them.
How we hand over
- Deliver the effectiveness policy, procedures and measurement records in formats the client's management body can review.
- Document how effectiveness results flow into risk treatment decisions and management reporting.
- Provide runbooks so the client's own staff can run measurements, review failures and keep records after handover.
How we support
- Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.
- Ongoing support, upgrades and continuous testing are available as a retainer if the client wants help between assessments.
- Independent auditors, assessors and national authorities decide conformity. DeployOpen prepares evidence for their review.
