OpenSearch for NIS2 monitoring and logging: what it covers and what it does not
Point 3.2 of the Annex to Implementing Regulation (EU) 2024/2690 asks operators to monitor and log activity on their network and information systems, review those logs, and keep them protected and backed up. OpenSearch can host the logs, access controls, audit trail and redundancy that the point asks for, but it does not choose the events, set the alarm thresholds or define the retention period. Those decisions stay with the operator, and the platform carries them out. Consider an illustrative cloud operator in scope: its security team must show an assessor which events it logs, what triggers an alarm, how long records are kept and who can change them. OpenSearch is where much of that evidence will sit.
The regulation applies directly to the entity categories it lists, which include cloud computing, data center, content delivery network, managed service and managed security service providers, online platforms and trust service providers. Other entities in NIS2 scope meet the same risk-management duties through their national transposition laws, because NIS2 is a directive and Member States adopt the detailed rules. Operators in either group should confirm which obligations their national authority applies to them. NIS2 creates no certificate of compliance. National competent authorities check compliance through inspections, security audits, security scans, information requests and administrative fines, as set out in Articles 32 to 34. Essential entities face ex ante supervision and important entities face ex post supervision, so the timing of scrutiny differs even though the duties are the same.
On the platform side, the OpenSearch Security plugin supplies much of the access and integrity layer. Role-based access control, document-level and field-level security, audit logs and TLS for node and client traffic let you limit who reads or changes log indices and record what they did. Single sign-on through SAML, OpenID Connect or LDAP ties those roles to your identity provider. For point 3.2.5, snapshot and restore gives you a backup route, and deciding where snapshots are written, and who can alter that location, is a design task you must complete. For point 3.2.6, run dedicated cluster manager nodes, keep replicas on separate nodes, enable shard allocation awareness, and watch the availability of the logging cluster from a path that does not depend on it. Confirm the exact settings for your OpenSearch version in its security documentation before you write them into a control.
The remaining work sits outside the product. The events in scope are the ones your risk assessment and threat model say could indicate an incident, so the log sources, parsers and event catalog are your responsibility, whether you build them with OpenSearch's ingestion tooling or other pipelines. Alarm thresholds under point 3.2.4 need baselines for unusual trends, and someone must review them regularly and act on what they raise. Point 3.2.5 sets no fixed retention period, so the number of days or months is a decision you must justify from your obligations and risk, and it should be written into a procedure. The ENISA technical implementation guidance of 26 June 2025 is non-binding but gives examples of evidence and maps them to ISO/IEC 27001:2022 and NIST CSF 2.0. Treat it as a checklist of what an assessor may ask to see, and check your national authority's requirements alongside it.
DeployOpen can plan the OpenSearch cluster, configure the security and retention settings, build the review procedures and assemble the evidence set, all in infrastructure you control. DeployOpen does not issue audit reports, attestations or certifications. Independent assessors or your national authority decide whether the controls meet the requirement. Before you request a quote, decide the event catalog, the alarm thresholds, the retention period and the owner of each review, and confirm which NIS2 entity category and national transposition law apply to you. The Commission's proposal to amend NIS2 (COM(2026) 13, proposed on 20 January 2026) was still pending in Commission pages updated through July 2026. It needs approval by the European Parliament and the Council, so the current text still governs your obligations.
Which NIS2 logging points map to which OpenSearch capabilities
This table maps the monitoring and logging points in the Annex to Implementing Regulation 2024/2690 to the OpenSearch capabilities that support them and the configuration each one needs. Read each row from left to right: the requirement, what it asks for, the OpenSearch feature that supports it, and the settings you must define. The main takeaway is that OpenSearch supplies the controls, but your organization must still decide and document the retention period, review procedure and alarm thresholds.
| Requirement | What it asks for | OpenSearch capability | Configuration needed |
|---|---|---|---|
| Point 3.2 (monitoring and logging) | Monitor and log activity on network and information systems to detect events that could be incidents, automated where feasible. | Audit logs from the Security plugin, with TLS on node and client traffic so logged activity is captured and transmitted securely. | Confirm the audit categories your version supports, enable them on each node, and route events into dedicated indices. |
| Point 3.2.4 (review and alarm thresholds) | Regular review for unusual trends, and alarm thresholds that trigger an alarm, automatically where appropriate. | Role-based access control restricts who can view, edit or act on review outputs. Confirm alerting features for your version first. | Define threshold rules per log source, assign named reviewers, and record each review and threshold change in a log kept outside the cluster. |
| Point 3.2.5 (retention and protection) | Keep and back up logs for a predefined period, protected from unauthorized access or changes. The regulation sets no fixed period. | Snapshot and restore to a registered repository, with document and field-level security and RBAC limiting read access to stored logs. | Set your retention period in your own policy, schedule snapshots, restrict repository write access, and test restores. Confirm immutability options with your storage provider. |
| Point 3.2.6 (redundant monitoring) | Redundant monitoring and logging, with availability monitored independently of the systems they monitor, to the extent feasible. | Dedicated cluster manager nodes, replicas on separate nodes and shard allocation awareness for availability. | Spread nodes across failure domains, set replica counts per index, and monitor cluster health from a separate system outside the cluster. |
Which events to log for NIS2 monitoring and logging
Identity events often provide the first evidence of misuse, so most teams route them into OpenSearch before anything else. The catalog should reflect what your entity actually runs, but authentication and authorization records are almost always in scope because they show who reached which system and when.
- Sign-in outcomes from the workforce identity provider, including SAML, OpenID Connect and LDAP directory binds
- Privilege changes such as role grants, group membership updates and administrator assignments in directory services
- Multi-factor events covering enrollment, resets and any bypass or fallback path
- Service account and API token activity for creation, use and revocation
- Lockouts and unusual sign-ins from unexpected locations or at hours outside your baseline
These sources can reach OpenSearch through OpenSearch's own ingestion tooling or through OpenTelemetry collectors where the identity platform supports export. Confirm with each identity owner which fields carry the user, source address and outcome, because alarm thresholds depend on those fields.
Network and infrastructure logs show how traffic moves between segments and whether hosts behave as expected. Firewalls, load balancers, DNS resolvers, hypervisors and operating systems generate high volumes, so teams usually agree on a filtered set before ingestion starts.
- Gateway and firewall decisions, especially denied flows and allowed flows into restricted zones
- DNS query records from resolvers that serve internal clients
- Host security events such as operating system logons, privilege escalation and service starts or stops
- Control plane events from hypervisors and clusters, including node joins, failures and evictions
- Configuration changes to security groups, routes and access control lists
Some devices forward natively over syslog, while others need an agent or an intermediate collector. Confirm with the network and infrastructure teams which sources forward directly and which need a collector, because that decision determines where events can be lost before they reach the cluster.
Applications and data stores hold the records that matter most in an incident investigation. The OpenSearch Security audit log covers the cluster's own access activity only, so every other application, database and object store needs its own collection path, and this is the part teams most often leave unplanned.
- Application authentication and authorization outcomes, including denied requests and calls to privileged functions
- Database administrative events such as logins, schema changes and bulk exports from sensitive tables
- Object storage access records for buckets that hold regulated or personal data
- Error patterns that suggest scanning, injection attempts or tampering with application data
- Deployment and configuration changes that alter how an application handles data
Application teams can emit these through logging frameworks instrumented with OpenTelemetry, and some database engines offer native audit facilities. Confirm with each application owner which events are already produced and at what level, because enabling more audit output can change performance and storage volume.
Administrative actions change what every other source can show, so they belong in the catalog even when they look routine. The OpenSearch Security audit log records access to the cluster itself, including administrative sessions, which makes cluster administration the natural starting point, but changes made in other platforms need their own collection.
- Cluster security events for authentication, index access and security configuration changes
- Identity and role changes inside OpenSearch, such as users, role mappings, tenants and TLS settings
- Changes to the monitoring stack itself, including pipelines, retention policies and alarm rules
- Privileged remote sessions and configuration management runs on hosts and network devices
- Backup and snapshot activity, including repository changes and restore operations
Before finalizing the list, confirm the catalog with your national competent authority or auditor, since the regulation leaves event types to the entity and their expectations may add detail. Also confirm that change tickets and deployment records can be correlated with these events, because that link is what makes an administrative event explainable during review.
How alarm thresholds and regular log review fit point 3.2.4
Point 3.2.4 of the Annex to Implementing Regulation 2024/2690 places two duties on the entity. The first is to review logs regularly for unusual trends. The second is to set alarm thresholds that trigger an alarm, automatically where appropriate. The duties support each other: a human review finds patterns that no one has written a rule for yet, while thresholds catch known conditions without waiting for someone to look. An OpenSearch deployment that only stores logs satisfies neither duty. The entity needs a defined set of events, a named owner for each, and a record showing that both controls ran.
Thresholds are a business and risk decision, and the entity must document them. The regulation does not give numeric values, so the entity decides which events matter, what level of activity counts as unusual for each system, and who is notified when a threshold is crossed. Those choices depend on how critical the system is, how much downtime the business can absorb, and what the entity has already observed in its own environment. Illustrative example: a failed-login threshold for an administrative interface may be set more tightly than one for a public web application, because a single unexpected administrative attempt carries a different level of risk. Record the rationale beside each threshold so that a later change has a traceable reason.
Do not assume that alerting is available in your release. OpenSearch ships minor versions roughly every eight weeks, and maintenance versions receive bug fixes and security patches but no new features. Alerting, notification and anomaly detection behavior can differ between the version and plugin set you run. Confirm in the documentation for that exact version which monitors, trigger types, notification channels and anomaly detectors it includes, and which ones need additional plugins. If a rule type you need is missing, decide which other tool will raise that alarm and document that path too. Test each alarm end to end, including confirmation that the notification reaches a person who can act on it.
Regular review is the evidence auditors will ask for first, so design the record before the first review. Name each reviewer and their role, and give each reviewer an OpenSearch Security role limited to the indices they review, so their access is controlled and can be logged. Set and document a review frequency for each log source, along with the dashboards, saved searches or queries used. Each review entry should state the date, the reviewer, what was checked, what was found, and what was escalated to incident handling, with the ticket reference. A review with no findings still needs an entry. Store the record where reviewers cannot edit their own entries.
Automation is required only where appropriate, so the entity must justify every alarm that stays manual. Keep a register with one line per alarm: the event it covers, the threshold and its rationale, whether it is automated or manual, the owner, and the date it was last reviewed. A manual alarm needs a stated reason, such as a low event volume where an automated alert would mostly produce noise, or an action that requires human judgment before anything happens. The regulation does not define appropriate, so compare the register with the examples of evidence in ENISA's non-binding technical guidance published on 26 June 2025, and confirm with your national competent authority how it reads this point. Build the register before configuring any alert.
What evidence OpenSearch produces for NIS2 logging audits
An authority or auditor will ask the entity to show how its logging and monitoring works, not only that a cluster exists. OpenSearch produces much of this material as configuration, logs and records, but the entity must keep, version and sign each artifact under its own governance.
Documented event catalog
A written list of the events the entity logs from each system, with the source, the fields kept and the owner of each source. It shows the auditor which activity under point 3.2 is covered and where gaps remain. Keep it under version control next to the index mappings and ingestion pipelines so it changes when sources change. Check that every catalog entry maps to a working ingestion path and that failed or missing sources raise a visible alert.
Cluster, index and TLS configuration exports
Scheduled exports of cluster settings, node roles, index templates, shard and replica settings, and TLS configuration for node and client traffic. Together they show that the logging platform is set up as documented and that transport encryption is enforced. Generate the exports from configuration as code where possible, store them with change records, and compare each export with the previous one. Unexplained drift between exports is a finding to investigate before an assessment begins.
Role and permission mappings
Exports of OpenSearch Security roles, role mappings and internal users, along with the backend mappings that link SAML, OpenID Connect, LDAP or Active Directory groups to those roles. They answer who can read logs, who can change retention or alerting, and which accounts hold administrator rights. Keep the files as configuration as code, record an approval for each access change, and reconcile mappings against the identity provider's group list at each review. The export shows the design, so dated access reviews signed by the entity still need to be kept alongside it.
Audit log settings and sample entries
The Security plugin audit log configuration, including which event categories are recorded, where audit records are written and how they are protected from modification. Include recent sample entries that show failed logins, privilege changes and access to log indices, so the assessor can see the content of the records and not only the setting. Export the settings on a schedule, keep the samples with their timestamps, and monitor whether audit logging is disabled or redirected.
Retention, snapshot schedules and restore tests
Retention rules for each index pattern, snapshot policies with their schedule and repository, and the access controls on the snapshot repository. Point 3.2.5 requires logs to be kept and backed up for a predefined period, and the regulation sets no fixed period, so the entity must document its own and justify it. Restore test records matter as much as the schedule: record the date, the snapshot restored, who ran the test and whether the restored data was searchable.
Alarm rules, thresholds and review records
Alerting monitor definitions with their query, schedule, threshold and notification target, which support point 3.2.4 on alarms that trigger when logs show unusual trends. Each threshold needs a short rationale: the baseline it was set against, the event it is meant to catch and the owner who accepted it. Add dated periodic review records showing that logs were examined, which thresholds changed and what was escalated. Export monitor definitions with the configuration exports so the two stay consistent.
Keeping logs protected and retained for a predefined period
Point 3.2.5 requires logs to be kept and backed up for a predefined period and protected from unauthorized access or changes. The regulation sets no number, so the entity must choose its own retention period, record why it chose it, and check that choice against its other obligations. Start by writing down which log sources are covered, what each source is needed for (detecting incidents, investigating them, and showing evidence to the competent authority), and which sector rules, contracts, or internal policies set a minimum. Legal and compliance should review the written rationale and sign it off. In OpenSearch, the retention period is enforced by lifecycle policies on indices, so the approved period should map directly to a policy that someone can read and audit. Confirm the lifecycle feature and its behavior in the version you deploy.
The OpenSearch Security plugin provides the controls that limit who can read or change logs. Role-based access control, document-level and field-level security, and field masking let you give analysts access to the indices they need while hiding sensitive fields such as user identifiers from roles that do not need them. Audit logs record security-relevant activity, and TLS protects node and client traffic. Build a read-only role for most users and keep administrative roles to a small group. Separate the roles for deleting indices, changing retention or lifecycle policies, and editing security configuration, so that no single person can shorten retention and erase the trail. Test these separations by attempting each prohibited action with each role and recording the result as evidence.
Snapshot and restore is the backup method documented for OpenSearch, and it is the method to confirm for log retention. Confirm which repository types your version supports, where snapshots will be stored, and how repository credentials are restricted, since a user who can delete snapshots can defeat the backup. Align snapshot retention with the log retention period so that backups do not expire before the logs they protect. The evidence that matters is a restore test: restore a sample of indices into a separate cluster, check document counts and that searches return expected results, and record the date, scope, and outcome. Repeat the test on a planned schedule and after every version upgrade, and keep the results with the retention documentation.
The platform documentation reviewed for this section does not confirm tamper evidence or write-once storage for indices or snapshots. Do not assume either exists. If the regulator or your auditors will expect proof that historical logs were not altered, you need to verify the capability or design it separately. Ask the vendor or your storage provider whether object lock or an equivalent immutability mode is available for the snapshot repository, and how it interacts with lifecycle deletion. Other options include computing and storing hashes of exported log archives under separate custody, or forwarding copies to a store that only the logging team can write to. Then test it: attempt to modify or delete a protected record as an administrator, and confirm that the attempt is blocked or visible in the audit trail.
Designing redundant logging that stays available for NIS2 monitoring
Point 3.2.6 asks that monitoring and logging systems be redundant to the extent feasible. For an OpenSearch cluster, the documented starting points are dedicated cluster manager nodes, replicas placed on separate nodes, and shard allocation awareness so copies are spread across zones or racks. Each one protects against a different failure, and none of them is a substitute for a tested backup under the retention requirements in point 3.2.5.
- Dedicated cluster manager nodes: Keep cluster manager duties off data nodes so that heavy indexing or search load does not destabilize cluster state. Size the count so a quorum survives the loss of one node or one zone.
- Replicas on separate nodes: Set the replica count per index based on how much log data you can afford to lose during a node failure and on the disk and compute headroom you have.
- Shard allocation awareness: Tag nodes with their zone or rack so the cluster will not place a primary and its replica in the same failure domain.
- Capacity headroom: A cluster that runs near its disk watermarks cannot re-replicate after a failure. Plan storage for the state after a node loss, not only for normal operation.
- Feasibility record: If a zone or a third site is not available in your infrastructure, document that limit and the compensating controls, such as a snapshot schedule and a tested restore.
Check the cluster against a planned node or zone failure during acceptance testing, and confirm the resulting shard states and recovery time with your own sizing.
Monitoring fails silently when the path that carries logs into OpenSearch fails, so the ingestion path needs redundancy as much as the cluster does. Whether you can add a second collector, a buffer or a second delivery route depends on the log pipeline you already run. Confirm each option with the pipeline vendor or project before you commit to a design.
- Local buffering: Agents and collectors that can queue events on disk let logs survive a short outage of the cluster. Confirm the queue size, the overflow behavior and whether the buffer is encrypted at rest.
- Multiple collectors: Running two collectors that read the same sources can remove a single point of failure, but you must confirm how duplicates are handled and whether the pipeline supports this pattern.
- Message queue in front of the cluster: A durable queue can decouple sources from indexing. Its own availability then becomes part of the 3.2.6 assessment.
- Source coverage: Confirm which sources can fail over and which cannot, such as appliances that only send to one syslog target.
- Delivery acknowledgements: Test whether a failed delivery is retried and whether the sender records the gap, because silent loss is the failure mode auditors will ask about.
Test the path by stopping the cluster for a defined window and checking that events arrive afterward without unexplained gaps.
Point 3.2.6 requires that the availability of monitoring and logging systems be monitored independently of the systems they monitor. In practice, something outside the logging cluster and outside its ingestion path must check that OpenSearch responds, that the ingestion endpoints accept events and that alerts are delivered. A monitor hosted on the same cluster, or one that reads from it, cannot report that the cluster has stopped.
- Separate operation: Run the monitor on a separate host, network segment or hosted service, with its own credentials and its own administrators, so one compromise or misconfiguration does not silence both.
- Checks to run: Cluster health endpoint reachability, ingestion endpoint responses, the age of the newest event in key indices and the status of the collectors.
- Alert path: The alert must reach people who are not dependent on the same outage, through a channel that does not rely on OpenSearch Dashboards.
- Dead man's switch: Expect a heartbeat from the pipeline, and alert when it stops, so that a silent collector is also detected.
- Documentation: Record the monitor's owner, its failure behavior and the decision that places it outside the logging system.
Confirm during testing that the monitor fires when the cluster is stopped and when the ingestion path is blocked, and that the alert reaches the on-call contact.
The regulation does not define a single redundancy design. It asks for redundancy to the extent feasible, which means your organization must judge what is feasible for its size, its infrastructure and its risk, and show how that judgment was reached. Auditors and national competent authorities will look for the reasoning as well as the controls.
- Feasibility assessment: For each element (cluster roles, replicas, zones, collectors, buffering, monitoring), record whether it is implemented, why it is not feasible if it is not, and what replaces it.
- Approval and review: Name the person who accepted each limit, and review the record when the architecture or the threat picture changes.
- Link to risk management: Tie accepted limits to the risk assessment under the Article 21 measures so the reasoning is traceable.
- Evidence: Keep configuration exports, the test results from failover and monitor tests, and the monitor's alert history.
- Regulatory watch: The Commission has proposed amendments to NIS2 that are not yet adopted, so confirm the current requirements with your national authority before finalizing the record.
Ask your compliance lead or an independent assessor to review the feasibility record against the ENISA technical guidance on Implementing Regulation 2024/2690 before it is relied upon.
What OpenSearch does not cover for NIS2 point 3.2
OpenSearch can collect, store and restrict access to logs, but point 3.2 of the Annex to Implementing Regulation 2024/2690 also depends on decisions that no software makes for you. The cards below list the gaps the entity owns, who usually owns each one and what to confirm before an assessment. National transposition rules and the competent authority's assessment also sit outside the platform, so confirm them early.
Event catalog tied to risk assessment
The entity decides which events must be logged and why each one matters. OpenSearch ingests the sources you connect, but it cannot tell you which failed logins, privileged actions or configuration changes could signal an incident in your environment. Map each event type to a risk in your Article 21 risk assessment, and confirm that every critical system has at least one source feeding the cluster. Review the catalog whenever systems or threats change.
Alarm thresholds and response procedures
Point 3.2.4 expects logs to be reviewed for unusual trends, with alarms that trigger where appropriate. The alerting you configure on the cluster can fire on a query, but the thresholds, the owner of each alarm and the steps that follow are operational decisions the entity must set and test. Document who receives an alert outside working hours, what they do first and when an alert becomes an incident record. Confirm the thresholds with the team that will answer them.
Retention period and legal hold rules
Point 3.2.5 requires logs to be kept and backed up for a predefined period, but the regulation sets no fixed length. The entity must choose the period for each log type, record the reason and align it with national law, contracts and any open investigation. Legal hold rules decide when normal deletion stops for specific data. Confirm with legal counsel who can place or release a hold, and how index lifecycle settings enforce both the period and the hold.
Tamper resistance beyond access controls
Point 3.2.5 asks for protection against unauthorized changes. Role-based access control and audit logs help, but on their own they do not prove that stored records were never altered. Administrators with cluster-level rights need separate controls, so decide whether a second copy goes to separate storage, whether snapshots are held under a different credential and how deletions are detected. Confirm each mechanism in your deployment and test it with a planned change before relying on it.
Independent review and sign-off
Point 3.2.4 expects regular log review, and the entity must show who reviewed the logs, how often and with what outcome. The reviewers should not be the same people who administer the cluster or the systems being watched. Define the reviewer roles, the review cadence, the sign-off record and the escalation path. Confirm that management accepts this review model, and keep the signed records with the evidence you provide to the competent authority.
Incident reporting timelines under Article 23
Article 23 sets its own reporting obligations for significant incidents, and those timelines are separate from point 3.2. OpenSearch can show when an event was detected and what it contains, but it does not decide whether an event is significant or send a notice to a national authority. Confirm with your competent authority which notices apply, who makes the decision and which log fields each report needs. Build the reporting workflow before an incident occurs, so the logs can answer the questions the notice requires.
Setup sequence for NIS2 monitoring and logging on OpenSearch
This sequence takes an organization from applicability questions to a monitoring and logging setup it can show to a supervisor. Each step closes with a named artifact, so the evidence is produced during the build. The order matters because the event catalog and alarm thresholds decide what the cluster must collect, alert on and keep.
Confirm applicability and entity category
Legal or compliance leads confirm whether the organization is in scope of NIS2 through its national transposition law, then record whether it is classed as essential or important. The classification changes how supervision works, while the monitoring and logging point in Implementing Regulation 2024/2690 applies to the in-scope entity either way. Confirm the sector and classification with the national competent authority before building anything, because scope drives every later step. The output is an applicability memo signed by the accountable executive, citing the national law and the relevant sector annex.
Build the event catalog from the risk assessment
Security engineers and the risk owner list the events that could indicate an incident on each in-scope system, such as failed and unusual authentication, privileged actions, configuration changes and changes to logging settings themselves. Each event is tied to a risk scenario from the risk assessment and to a named log source. Point 3.2 asks for procedures and tools that detect events that could be incidents, so the catalog is the basis for later automation. The output is an event catalog with one row per event, its owner, its source and its detection intent, approved by the CISO.
Set alarm thresholds, review duties and retention
The monitoring owner converts catalog entries into alarm thresholds and states which alarms fire automatically and which go to a person. The same owner assigns who reviews logs for unusual trends, how often reviews happen and how each review is recorded. Retention comes next: the regulation requires logs to be kept and backed up for a predefined period but sets no fixed length, so the period comes from the entity's own policy, legal duties and risk assessment. The protection model covers restricted delete rights, separate administrator access and backups stored apart from the cluster. The outputs are a threshold register, a review roster and a retention and protection standard.
Deploy the cluster with redundancy
The platform team installs OpenSearch using a method the organization's standards already support, then assigns node roles so that cluster manager nodes run as dedicated nodes separate from data nodes. Replicas are placed on separate nodes, and shard allocation awareness keeps copies in different failure domains such as racks, zones or sites, as the cluster documentation recommends. The team checks that the layout meets the availability target set in the risk assessment and sizes node count and storage against the retention volume. The output is a cluster build record with node roles, allocation awareness settings and a diagram of failure domains.
Configure access, TLS and audit logging
The security team connects the Security plugin to the organization's identity provider, then defines role-based access so analysts see only the indices they need. Document-level and field-level security, or field masking, applies where logs contain personal data. TLS covers node-to-node and client traffic, and audit logging records administrative and access activity so that changes to the log store are visible. The team confirms that default credentials are removed and that administrator certificates are held by named custodians. The outputs are a role and role-mapping export, a TLS configuration record and the audit logging configuration, all of which an auditor can read from the cluster.
Connect ingestion sources and alerting
Each source in the event catalog is connected through an agreed pipeline, and the team checks that every catalog entry produces events in the index assigned to it. Alerting rules are loaded from the threshold register, tested with events raised for that purpose, and routed to the named reviewers. A separate availability monitor runs outside the logging cluster on infrastructure that does not depend on it, and it alerts when the cluster, the ingestion path or the alerting path stops. The outputs are a source inventory with coverage status, an alert rule register and test records showing that each alert fired and reached a reviewer.
Run restore, failover and monitor independence tests
The platform team restores a backup of the indices into a separate environment and compares document counts and retention metadata with the source. In a controlled test, one node or zone is stopped to confirm the cluster stays available and that alerts still fire. The team then stops the monitored cluster to confirm the independent availability monitor reports the outage. Failed checks are logged with a corrective action and retested before sign-off. The output is a signed test report for each test, showing date, scope, results and remediation, which supports the redundancy and independent availability point, 3.2.6.
Assemble the evidence pack and review schedule
The compliance lead gathers the artifacts from the earlier steps into one evidence pack with an index, version history and a named owner for each item. The pack maps each part of point 3.2 to the artifact that covers it and flags items that depend on people, such as review sign-off. A review schedule sets who re-checks the event catalog, thresholds, roles, retention settings and test results, and it defines which cluster changes trigger an update. NIS2 creates no certificate of compliance, so the pack is evidence that the competent authority's inspectors will examine. The outputs are the evidence pack index and the review calendar.
Questions buyers ask before hiring help for NIS2 logging on OpenSearch
What drives the cost of NIS2 logging work on OpenSearch?
The main drivers are the number of log sources in scope, the number of OpenSearch clusters, how long logs are kept, how much redundancy the design needs, the alerting build and the evidence work. Each source needs parsing, field mapping and a decision on which events it must contribute under the monitoring and logging point in the Annex to Implementing Regulation 2024/2690. More clusters mean more configuration, certificates, access roles and upgrade paths to manage. Retention and redundancy design, including separate storage for protected logs and independent availability monitoring, adds infrastructure and testing. Alerting is often the largest unknown because each alarm threshold has to be defined, tested and tied to a response owner. Evidence preparation, meaning procedures, configuration exports and review records, scales with the number of systems it covers. Ask any quote to price each driver on its own line.
Is NIS2 logging work a one-time project or a recurring cost?
It has both parts. The initial design and build is one-time work: scoping sources, configuring OpenSearch, building retention and redundancy, defining alarm thresholds and preparing the first evidence set. Recurring work follows from the regulation's expectation that logs are reviewed regularly for unusual trends and that retention and protection keep working over time. Typical recurring items include reviewing alarm thresholds, applying OpenSearch maintenance releases, testing restores from backups, checking that access controls still match the team and updating evidence after changes. OpenSearch targets a new minor version about every eight weeks, and maintenance versions receive bug fixes and security patches, so the upgrade cycle needs a named owner. The recurring duties can stay in house or be covered by a retainer. Ask for a quote that separates the one-time and recurring lines.
How long does a NIS2 logging engagement on OpenSearch take?
Duration depends on scope, so a timeline is only meaningful when it comes from a written scope. The main drivers are the number of sources and clusters, whether an OpenSearch deployment already exists or must be built, how many systems the retention and redundancy design must cover, how many alarm thresholds need agreement from business and security teams, and how quickly the client provides owners and approvals. Evidence preparation takes longer when controls are undocumented and moves faster when configuration is already versioned. Upgrading or migrating an existing cluster adds a separate planning and testing phase. Ask for a timeline that lists each phase, the client inputs each phase depends on and the review points where scope can be confirmed. Be cautious with any single figure offered before the scope is agreed.
What do we need to provide before NIS2 logging work starts?
Before work starts, the team needs four inputs: an asset inventory, a risk assessment, named owners and access to the environments. The asset inventory lists systems, log sources and the networks they sit on, which makes the scope of sources clear. The risk assessment shows which events matter most and supports decisions on alarm thresholds and retention periods. Named owners are needed for the OpenSearch platform, for each log source, for alarm response and for approving retention decisions, because the regulation sets no fixed retention period and the organization must choose one. Access to environments means read access to current configuration, a test or staging cluster and the ability to deploy into the infrastructure you control. Gaps in these inputs usually appear as delays in the scope and as open items in the evidence list.
Can an internal team set up NIS2 logging on OpenSearch alone?
Yes, for a small scope with clear ownership, an internal team can build it alone. A small scope usually means a single cluster, a limited set of log sources and one team that already runs OpenSearch or a comparable platform. The hard parts are the event catalog and the review duties. The event catalog must define which events are logged, why each could indicate an incident and how each maps to the monitoring point in Annex point 3.2, which takes security judgment as well as configuration. Review duties require someone to look at logs regularly for unusual trends, tune alarm thresholds and record the outcome, and that work continues after the build ends. Teams without these skills, or without a named reviewer, often bring in a partner for the design phase. A written scope shows which parts stay in house and which are delegated.
What should a quote for NIS2 logging on OpenSearch include?
A quote should follow from a written scope agreed before work starts. It should list the in-scope log sources and clusters, the design decisions covered, including retention, redundancy and independent availability monitoring, and the alerting build with the thresholds to be defined. Deliverables should name each configuration, procedure and test result handed over at the end. The evidence list should show which records will exist, such as configuration exports, procedures, alarm test results and restore test records, and who owns each one. Exclusions matter as much as inclusions, so the quote should state which sources, clusters, upgrades, retention operations and client-side tasks are not covered. Ask for one-time and recurring items on separate lines and for the client inputs the price assumes. DeployOpen does not publish a price list, so the written quote is the figure to compare.
Can a partner make our OpenSearch logging NIS2 compliant?
No. A partner can prepare the systems, controls and evidence, but it cannot make an organization compliant or certify it. DeployOpen plans, implements, hardens and documents self-hosted platforms in infrastructure the client controls, and it prepares systems and evidence for compliance assessments. It does not issue audit reports, attestations or certifications. NIS2 creates no certificate of compliance. National competent authorities oversee compliance through inspections, security audits, security scans, information requests and administrative fines, and national transposition laws shape how those powers apply. The authority or an independent auditor decides the outcome. Ask any partner to show which controls and evidence it will prepare and which decisions stay with the organization's management and regulators.
How DeployOpen scopes and delivers NIS2 logging configuration and evidence
DeployOpen plans, implements, hardens, documents and supports self-hosted open-source platforms inside the client's own infrastructure. For OpenSearch used as NIS2 monitoring and logging, we start from the entity's own systems and the Annex points it must meet, then build the logging pipeline, alarms, protected retention and redundancy in environments the client controls.
How we scope
- Inventory the systems in scope and the activity each must log to detect events that could be incidents
- Map log sources, alarm thresholds and review duties to the Annex points on monitoring, logging and protection
- Agree retention periods with the client, since the regulation sets none, and record the basis for each choice
- Define the written scope, deliverables and timelines before work starts, as most engagements are fixed-scope
How we build
- Deploy OpenSearch with dedicated cluster manager nodes and replicas on separate nodes for availability
- Configure access control, TLS and audit logging so stored logs are protected from unauthorized access or change
- Build ingestion pipelines and alarm rules that trigger alerts, automatically where the client chooses
- Test alarm firing, log integrity and recovery from snapshot restores in a staging environment before cutover
How we hand over
- Deliver configuration, architecture notes and runbooks for the logging pipeline and its alarm rules
- Provide a mapping of each implemented control to the relevant Annex points, prepared as evidence for the client's assessors
- Document backup schedules, retention settings and how independent monitoring of the logging platform is set up
- Train operators on reviewing trends, responding to alarms and handling access requests
How we support
- Offer ongoing support, upgrades and continuous testing as a retainer after handover
- Plan OpenSearch upgrades around the release and maintenance policy, confirming current versions with the project before each change
- Review alarm thresholds and log sources as the client's systems and the regulation's implementing guidance evolve
- Confirm with the client's legal or compliance team how national transposition laws apply to their entity
