What Annex I Part I (2)(h) requires for availability of essential functions
Point (2)(h) of Annex I Part I requires the product itself to protect the availability of its essential and basic functions, including after an incident, through resilience and mitigation measures against denial-of-service attacks. A manufacturer preparing a product for the EU market must be able to show that the product keeps its core functions running under attack and can return to them after a failure, not only that it has an uptime target on paper. The requirement sits inside the manufacturer's cybersecurity risk assessment, so the risk assessment must explain which functions count as essential and why the chosen measures fit the risks found.
The requirement is about the product's own resilience. Point (2)(i) addresses a different question: whether the product, or devices connected to it, degrades the availability of services that other devices and networks depend on. A product can meet (2)(h) and still fail (2)(i), for example by flooding a shared upstream service during a retry storm. Article 14(5)(a) makes the link to incident reporting explicit: an incident is treated as severe, and so reportable through the single reporting platform, where it affects or can affect the product's ability to protect the availability of sensitive or important data or functions. An outage of an essential function caused by an attack is therefore a potential reporting event, not just an operational problem.
The hard parts are usually two. First, defining essential functions: teams must list the functions whose loss matters to users and to the intended purpose, separate them from basic functions, and record that list in the risk assessment so an assessor can trace each measure back to it. Second, proving rather than describing. Recovery claims need a tested restore path with recorded recovery behavior, and denial-of-service resilience needs load and rate-limit tests against the product's own interfaces. Ask your test provider to confirm which scenarios they will run, what load profile they use and how results are recorded, and confirm with your conformity assessment body which evidence it expects.
Which functions, components and teams fall under point (2)(h)
Point (2)(h) is only as wide as the scope the manufacturer sets for it. The decisions below determine which functions must stay available, which interfaces and dependencies can disrupt them, and who answers for each one. Start with the product's version history, because it decides whether the requirement reaches the product at all.
Version history and substantial modification
Products placed on the market before 11 December 2027 fall under the regulation only when they are substantially modified from that date. Before scoping availability, record each released version, its market placement date and every change that could count as substantial. A release that alters the availability design of a product already on the market may bring that version into scope, so confirm the treatment with counsel or the market surveillance authority where the answer is unclear.
Essential and basic functions
The risk assessment should list which functions the product must keep running, such as authentication, data ingestion, sync or the control of connected hardware, and which are basic functions that can degrade gracefully. Record the classification and the reason for it, because the availability design, the recovery targets and the evidence all follow from that list. Functions that are not classified are the ones most often left unprotected.
Exposed interfaces open to denial of service
Enumerate every network listener, API endpoint, management port, message queue and public web route the product exposes. Each one is a path for a denial-of-service attempt that could exhaust connections, memory or compute. Rate limits, connection caps and filtering rules should be mapped to these interfaces, and any interface that cannot be protected should be justified in the assessment.
Cloud and hosted dependencies
Identify each managed database, identity provider, message broker, content delivery network, DNS provider or third-party API the product needs to function. An outage in one of these can take the product's essential functions down even when the product itself is healthy. For each dependency, document its availability commitments as stated by the provider, the failover path and who monitors it. Confirm these terms directly with each provider.
Ownership across engineering and operations
Availability is shared work. Engineering owns the design and the resilience features, operations owns capacity, deployment and failover runbooks, security owns denial-of-service detection and response, and support owns the customer-facing picture during an event. Write down a named owner for each essential function and each control, so that an assessor can trace a requirement to the person accountable for it.
Incident reporting thresholds
Article 14(5)(a) treats an incident as severe where it affects or can affect a product's ability to protect the availability of sensitive or important data or functions. Decide in advance which availability degradations would meet that threshold, who evaluates them and how quickly the decision is made. Those thresholds should reflect the essential functions identified in the risk assessment, and they belong in the incident response plan.
How an assessor tests availability and DoS resilience
This table sets out the checks an assessor is likely to run against point (2)(h), the evidence each check should produce, and the findings that usually appear when a manufacturer has not closed the gap. Read each row as a question the assessor will ask, then check whether your own records answer it before the assessment starts.
| Test area | Evidence the assessor expects | Common finding |
|---|---|---|
| Essential function list against the risk assessment | A register of essential and basic functions that traces each function to the risk assessment entry that justified it | Functions named in product documentation but missing from the risk assessment, or the reverse |
| Load and DoS testing of exposed interfaces | Test plan, tool and configuration, traffic profiles, results and the release version tested | A DoS test run once before launch and never repeated after later releases changed the interfaces |
| Behavior under resource exhaustion | Records showing how the product degrades when CPU, memory, connections or queues run out, and whether essential functions keep running | Essential functions share a queue with non-essential work, so a flood of low-priority requests stops them |
| Recovery and restart after a fault or incident | Documented recovery procedures, restart test results, recovery time targets set by the manufacturer and backup restore evidence | An essential function with no recovery procedure, or a restore that was never tested on the shipped configuration |
| Documented mitigation settings | Configuration baselines for rate limits, connection limits, timeouts and resource limits, with the reason each value was chosen | Rate limits exist in code but no baseline records their values, so a later change removes them unnoticed |
| Monitoring of availability signals | Alert rules and logs that show degraded availability of essential functions, and who receives the alert | Metrics are collected but no alert covers the essential functions, so degradation is found by users first |
| Incident handling for availability events | Runbooks linking an availability incident to the Article 14 severity assessment and the reporting decision | No defined link between an availability outage and the decision whether it is a severe incident under Article 14 |
How to implement point (2)(h) step by step
This sequence turns the availability requirement into working resilience measures, monitoring and tested recovery, each closed by a documented artifact the manufacturer can hand to a market surveillance authority or notified body. It runs from the risk assessment through to technical documentation.
Confirm the essential and basic function list
Start from the cybersecurity risk assessment and extract the list of the product's essential and basic functions, the ones whose loss would affect users or dependent systems. The product security lead owns the list, with product management and engineering confirming each entry. Each function gets a short definition of what 'available' means for it, such as a response time or a state the product must stay in. The step closes when the list is approved and version-controlled alongside the risk assessment.
Map dependencies and single points of failure
For each listed function, trace the components, services, data stores, certificates, network paths and third-party cloud services it relies on. Mark every element whose failure stops the function and every element that has no fallback. Engineering produces a dependency diagram and a table of single points of failure, including those inherited from open-source components and hosting providers. The step closes when reviewers agree the map covers every function on the list.
Design resilience and mitigation measures per function
For each single point of failure, decide the resilience measure: redundancy, graceful degradation, failover, state recovery or a defined safe mode. Record the chosen measure, the residual risk and the reason it was preferred, because the risk assessment drives the choice. Where a function cannot be made redundant, the design documents how it fails safely and how users are told. The step closes with a design record linked to each function and each risk entry.
Protect exposed interfaces with limits and isolation
Identify the network-facing interfaces and apply denial-of-service mitigations proportionate to the risk: rate limiting, request filtering, connection limits and resource isolation so one client or workload cannot exhaust shared capacity. Open-source components such as a web application firewall, a stateful packet filter or a reverse proxy can enforce some of these rules, but each rule set must be tested against the product's real traffic. Engineers confirm the configuration is stored as code and reviewed. The step closes with a configuration baseline and a list of the limits applied per interface.
Build availability monitoring and alerting
Define the metrics and logs that show whether each essential function is available and degraded, such as request success rates, queue depth, saturation and health checks. Metrics collection, dashboards and alert rules are configured so that loss or degradation of a function raises an alert to the operations team with a documented runbook. Alert thresholds come from the function definitions in the first step, not from defaults. The step closes when alerts fire in a test environment and the runbook is attached to each alert.
Test recovery and denial-of-service behavior
Run planned tests that simulate loss of each single point of failure and a denial-of-service load against exposed interfaces, then measure whether each essential function stays available or recovers within the limits defined earlier. Testing can be done by the manufacturer's own team or by an independent security testing provider, and the test plan, scope and rules of engagement are agreed in writing beforehand. Failed tests return to design. The step closes with a test report listing the scenario, the observed behavior and the decision taken for each result.
Record results in technical documentation
Consolidate the function list, dependency map, resilience designs, configuration baselines, monitoring definitions, runbooks and test reports into the technical documentation for the product, and link each item to the point (2)(h) requirement and to the relevant risk assessment entries. The product security lead signs off the record and it is updated whenever the product or its risk assessment changes during the support period. The step closes when an assessor can trace a function from the risk assessment through its design, configuration, monitoring and test evidence.
Evidence that passes an availability assessment
An assessor testing point (2)(h) looks for a chain of evidence: the functions you decided to protect, the tests that show they stay up under stress and after failure, the limits you configured, and the record of what happened in production. Each artifact below should trace back to the risk assessment and be refreshed as the product changes, not rebuilt before each review.
Approved essential function list
A dated register of the product's essential and basic functions, each linked to the risk assessment entry that justified treating it as essential. It should name the dependencies each function needs, such as databases, queues, identity services and network paths. Keep it current by reviewing it whenever a release adds a function or changes a dependency, and record the reviewer and date on each change.
Denial-of-service test reports
Load, stress and denial-of-service test reports that state the test date, the tested product version and the configuration under test. The report should show what degraded first, at what request rate, and how the product recovered. Rerun the relevant tests on each release that touches the request path, and retain older reports so an assessor can see the trend.
Recovery and restart test records
Records from tests that kill processes, fail a node or restore from backup, then measure whether essential functions return and in what state. Assessors look for evidence that the product restarts into a safe configuration and does not silently lose queued work. Repeat these tests after changes to deployment templates, service dependencies or backup tooling.
Rate and resource limit configuration
Documented limits on request rates, connections, memory, storage and concurrency, each with the configuration key or file where it is set. Store the configuration in version control so every change has an author and a reason. Review the limits after capacity changes and after each denial-of-service test, since a limit that was never exercised offers little protection.
Monitoring rules and alert history
Alert rules that detect loss of availability, such as rising error rates, saturated queues, failed health checks or traffic spikes at the edge, together with the history of alerts fired and acknowledged. Metrics and alerting tools such as Prometheus and Grafana can hold this record, provided retention covers the support period. Review alert thresholds whenever configuration or traffic patterns change.
Availability incident records
Tickets and post-incident reviews for every event that interrupted an essential function, showing detection time, the mitigation applied, the restoration time and the root cause. Check each record against the severity criteria in Article 14, since an incident that affects availability of essential functions can be reportable. Update the risk assessment and test plan with the lessons from each review.
Which self-hosted open-source tools support availability evidence
Availability evidence begins with measurement, and two tools in this stack supply it. Prometheus (Apache-2.0) collects metrics from instrumented jobs over HTTP using a pull model and stores them as time series identified by metric name and labels. Queried with PromQL, that history shows how essential functions behaved over time, including the period around an outage, which is the trend record an assessor will ask for. The Prometheus overview explains the model. Grafana Alerting (AGPL-3.0-only) builds alert rules from queries across multiple data sources and covers metrics and logs in one view, so an alert and the signals behind it can be reviewed together. Its AGPL-3.0-only license needs review with counsel before you modify or distribute it.
Two tools address the attack side of availability. Coraza (Apache-2.0) is a web application firewall compatible with ModSecurity SecLang rulesets and the OWASP Core Rule Set. It defends against attacks such as SQL injection, cross-site scripting and code injection, and it integrates with Caddy, HAProxy, Traefik and Nginx. Its rulesets target application-layer attacks, so confirm whether they cover the denial-of-service scenarios your risk assessment identifies. OPNsense (BSD-2-Clause) is a stateful packet filter whose rules pass, block or reject traffic by source, destination, port and protocol. Aliases group address ranges, and logging each rule match gives you configuration and log records that show network exposure is controlled. Its rules documentation describes these options. Export the rule set and its logs at each release so the evidence matches the deployed configuration.
These tools produce or support evidence. They do not make a product compliant with point (2)(h). The manufacturer still decides which resilience and denial-of-service mitigation measures the product needs, based on its cybersecurity risk assessment, and it still documents how each measure is tested. Before you rely on this stack, confirm three things in your own environment: the version and license of each component, whether the metrics and logs cover every essential function the product exposes, and whether rate limits, filtering and failover were tested under load with the results recorded. An implementation partner can configure, test and document these tools, but the organization owns the controls and the conclusion, and only an independent assessor issues a report.
What meeting point (2)(h) costs in money and effort
This table lists the cost components of meeting point (2)(h) and who is paid for each, whether it is one-time or recurring, and what pushes it up or down. Use it to structure a written quote, since no price or duration for this work is published in the regulation or its guidance. The main takeaway is that most of the recurring cost comes from keeping resilience evidence current on every release, not from the initial design.
| Cost component | Who is paid | One-time or recurring | What drives it up or down |
|---|---|---|---|
| Resilience design for essential functions | Internal engineering, or an implementation partner on a fixed scope | One-time, with revisions when the design changes | Up: many essential functions and dependencies. Down: a short, agreed list of essential and basic functions |
| DoS mitigation design and configuration | Internal platform or security engineering, plus any partner doing the build | One-time, then recurring on rule changes | Up: number of exposed external interfaces and internet-facing services. Down: reducing exposed interfaces before design starts |
| Monitoring and filtering tooling | Licenses if commercial. Self-hosted open-source tools carry hosting and staff time instead | Recurring (hosting, upkeep, upgrades, staff time) | Up: data volume and number of monitored services. Down: reusing self-hosted open-source monitoring, alerting and filtering components |
| Load and DoS testing | Internal QA, or an outside tester on a written scope | One-time per test campaign, repeated after major changes | Up: more functions under test and more release trains. Down: testing only the functions named in the essential list |
| Evidence upkeep on each release | Internal product and compliance staff | Recurring for the support period | Up: release frequency and manual evidence collection. Down: automated test output and configuration versioned with the code |
| External penetration or resilience testing | Independent testing firm, paid per written scope | Recurring, usually on a planned cycle | Up: scope breadth and number of targets. Down: a fixed scope that matches the risk assessment |
| Auditor or assessor sampling time | Independent auditor or certification body | Recurring at each assessment cycle | Up: missing or inconsistent records and many release samples. Down: a documented, reproducible evidence trail per release |
Who owns availability work, who helps and where the auditor stops
Your organization owns the product and the conformity claim, so the availability decisions sit with your product, security and engineering leads. The essential function list is the starting point: someone accountable must name which functions must stay available, which basic functions must keep working after an incident, and what degraded operation is acceptable. That list feeds the Article 13(2) risk assessment, which is where the reasoning for point (2)(h) is recorded.
- Essential function list: Product management and the security lead agree the functions in scope and record why each one matters to users.
- Resilience design: Architecture owners decide how the product keeps essential functions running under load, after a component fails and during a denial-of-service attack.
- Release testing: Engineering runs availability and load checks against each release and keeps the results with the technical documentation.
- Incident response linkage: Your PSIRT or incident team decides when an availability failure is severe under Article 14 and who notifies the CSIRT.
Check that each of these owners is named in writing and that the list is reviewed whenever the product changes substantially.
An implementation partner such as DeployOpen can help prepare the systems and evidence that show availability controls are in place. Partner work is delivered inside your own infrastructure and scoped in writing before it starts, so the deliverables, systems in scope and test boundaries are agreed in advance. The partner does not decide what your essential functions are or sign off on the outcome.
- System preparation: Configure the hosting, load balancing and failover patterns that your architecture team has chosen for the product.
- Monitoring and filtering: Set up metrics, alerting and web application or network filtering so that availability degradation is visible and attacks can be mitigated.
- Availability and DoS testing: Run structured tests against agreed scenarios and report the results with reproduction steps.
- Evidence documentation: Record configurations, test outputs and remediation tickets in a form your team and an auditor can follow.
Before engaging, ask for the written scope, the named deliverables and who on your side reviews each output.
Independent auditors and certification bodies test the claim that your product meets the requirement and issue any conformity outcome. Where a notified body is required, that role sits with a body notified by a Member State and listed in the Commission's NANDO system. The line is firm: an implementation partner prepares evidence, and only an independent body issues a conformity outcome or certificate.
- Independent testing: The assessor may run its own availability or DoS tests rather than rely on your test reports alone.
- Evidence review: The assessor checks that the risk assessment, the essential function list and the test records agree with each other.
- Sampling and traceability: The assessor traces a sample of releases from design decisions to test results.
- Outcome decision: Only the independent body decides whether the requirement is met and whether any conformity route is complete.
Ask the body early which evidence it expects and whether its approach to point (2)(h) matches your product class.
Some availability work is commonly outsourced and some should stay with your organization. Outsourced work is usually hands-on configuration, test execution and documentation support. Work that stays in-house is the set of decisions that define your product's obligations, because those decisions carry your accountability.
- Usually outsourced: Infrastructure hardening, filtering rule setup, load and DoS test execution and evidence packaging.
- Should stay in-house: Choosing the essential function list, accepting residual availability risk and approving releases.
- Shared work: Writing the test plan, which should be drafted by your team and reviewed by the partner.
- Recurring work: Retesting after each substantial change and reviewing the list each support period.
When requesting a quote, ask which tasks are one-time setup and which recur, and confirm who keeps the final decision record.
Questions buyers ask about point (2)(h)
How much effort does point (2)(h) add to each release cycle?
For most products, the ongoing effort is less about the requirement itself and more about keeping availability decisions current with each change. Each release that alters network exposure, dependencies, scaling behavior or error handling can affect the resilience measures already documented, so teams need a review step, updated monitoring thresholds and a repeatable test run. The main cost drivers are the number of externally reachable services, how often the architecture changes, and whether DoS tests are automated in the pipeline or run by hand. Ask any partner to break the effort into one-time design work and recurring release checks, and to state which of those checks they will run and which your engineers keep.
Can an in-house team meet point (2)(h) without outside help?
Yes, an in-house team can meet point (2)(h) if it has engineers who understand the product's architecture, can run load and DoS tests, and can build monitoring and alerting. Outside help is most useful where the team lacks independent testing capacity, needs a second view on the resilience design, or must prepare evidence that an assessor will accept. The organization remains responsible for its controls in every case. An implementation partner can prepare systems, monitoring and test evidence, but only an independent assessor or notified body issues conformity outcomes. Confirm in writing which parts of the work your staff own before engaging anyone.
What does the product owner and operations team need to provide?
Point (2)(h) work depends on decisions only the product owner and operations staff can make, so both need time in the design and release process. Typically the product owner defines which functions are essential and basic, and how far the product must keep working during and after an attack. Operations staff provide traffic baselines, capacity limits, recovery procedures and access to the environments where tests run. Expect to supply:
- A list of essential and basic functions, agreed with the risk assessment
- Current traffic patterns, scaling limits and known bottlenecks
- Runbooks for degraded operation and recovery after an incident
- Access to staging environments that resemble production
How long does it take to produce availability evidence?
No researched figure for implementation duration is available for point (2)(h), so treat any timeline as unconfirmed until it is written into a scope. The time depends on how many essential functions the risk assessment identifies, how much of the resilience design already exists, how mature the monitoring stack is, and how long test cycles take in your environment. Ask a partner for a phased plan that separates design, implementation, testing and evidence collection, and for the dependencies on your team's availability. For the regulation's own dates, confirm the applicable deadlines against the Regulation (EU) 2024/2847 text on EUR-Lex and your national market surveillance authority's guidance.
Does availability evidence overlap with Article 14 incident reporting?
Yes, they overlap in a specific way. Article 14(5)(a) treats an incident as severe, and so reportable, where it affects or can affect a product's ability to protect the availability of sensitive or important data or functions. Monitoring and alert records that show how the product detected and responded to a denial-of-service condition can therefore support both the point (2)(h) evidence and the reporting assessment. They do not replace reporting. Your incident process still needs to decide whether an event is reportable, and the reporting duty applies from 11 September 2026. Keep point (2)(h) records and reporting procedures linked but separately owned, and confirm the mapping with your legal and compliance leads.
What should a DoS test cover before its results count as evidence?
A DoS test should show how the product behaves under realistic attack conditions, not just whether it survives a single traffic spike. At minimum, it should cover the external interfaces in the risk assessment, the essential and basic functions the product must keep running, and the behavior of those functions during and after the attack. Record the test scope, tool versions, traffic profiles, pass criteria, monitoring data and recovery times, and retain them with the configuration under test. Illustrative example: a test that floods a login endpoint while checking whether a status function still responds would show more than a bandwidth test alone. Have an independent tester review the method so the results hold up under assessment.
How DeployOpen scopes and evidences availability for your product
DeployOpen works on availability as a fixed-scope engagement inside your own infrastructure. We help you define which essential and basic functions must stay available, then prepare the resilience, denial-of-service mitigation and monitoring evidence that supports your risk assessment, while your organization keeps ownership of the requirement and its decisions.
How we scope
- Agree in writing which essential and basic functions of the product fall under point (2)(h), and which are out of scope.
- Confirm the deployment context, including cloud accounts, data centers or air-gapped networks where the product runs.
- Record the availability decisions and their links to your Article 13(2) cybersecurity risk assessment before work starts.
How we build
- Configure rate limiting, web application filtering and edge protection against denial-of-service patterns for the product's exposed interfaces.
- Set up metrics and alert rules for service health, so degradation in essential functions is detected and routed to responders.
- Test failover, restart and recovery behavior of essential functions, and confirm the results against the agreed scope.
How we hand over
- Document configurations, alert definitions, test results and known limits so your engineers can reproduce and maintain them.
- Map each delivered control to the evidence an independent assessor would ask to see for point (2)(h).
- Provide the handover package in writing, with open items and owners listed for your team to close.
How we support
- Offer ongoing support, upgrades and continuous testing as a retainer, if your product needs them after handover.
- Review availability measures when the product changes, the risk assessment is updated or new threats are identified.
- Confirm with us in the quote which support tasks sit inside the fixed scope and which fall under a retainer.
