Graylog for NIS2 monitoring and logging

Graylog for NIS2 monitoring and logging: what the platform covers

If your organization is an in-scope entity under NIS2, you need to show that you monitor and log activity on your network and information systems, as point 3.2 of the Annex to Commission Implementing Regulation (EU) 2024/2690 requires. Graylog can support the collection, alarm, retention and redundancy parts of that obligation, but the regulation sets no fixed retention period, so the period you choose has to be justified and documented by you. DeployOpen plans, builds and documents a self-hosted Graylog deployment and prepares the systems and evidence for review, but we do not certify compliance and no auditor or certification body is involved in our work.

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 of Directive (EU) 2022/2555. Essential entities face ex ante supervision and important entities face ex post supervision, so the practical question is what you can show an authority on request: configured collection, working event definitions, retained logs and records of how alarms were handled. Confirm with your national competent authority, and with your own legal counsel, how the transposition law in your Member State applies to your entity and what it expects to see.

In practice, Graylog covers the platform side of that evidence: inputs that receive logs, streams and pipelines that route them, event definitions that raise alarms, index retention that keeps them, and a server and search cluster that can be made redundant. Its capabilities differ by edition. Graylog Open provides the core collection and alerting features under SSPL-1.0, while some features relevant to monitoring, such as correlation or certain SIEM content, depend on an Enterprise or Security license. Check these against the edition you plan to run before you commit to a design, because they determine which parts of point 3.2 you can meet with the open-source build alone.

Mapping NIS2 point 3.2 requirements to Graylog capabilities

This table maps each part of NIS2 Implementing Regulation 2024/2690 point 3.2 to the Graylog inputs, streams, pipelines, event definitions, index sets and architecture settings that would address it. Read the configuration column as the starting point for your own design, and the edition column to see which parts need an Enterprise or Security license on top of Graylog Open.

Point 3.2 requirement	Graylog configuration	Edition needed
3.2.3 log coverage (network traffic, accounts, privileged activity, security tools)	Define inputs for firewalls, domain controllers, Linux hosts, VPN and security tools (syslog, GELF or Beats). Route each source to a dedicated stream with pipeline rules that confirm required fields are present.	Graylog Open for common inputs; confirm per input type whether an Enterprise license applies
3.2.3 physical access and environmental events	Ingest access control and building or environmental system logs through syslog or a collector. Store them in their own index set so they can be searched and retained separately.	Graylog Open; confirm vendor-specific parsers in your environment
3.2.4 regular review and alarm thresholds	Build event definitions on saved searches with aggregation thresholds for failed logins, privilege changes and unusual trends. Send notifications to on-call channels with a named response owner.	Graylog Open for basic event definitions and notifications; correlation and advanced detection content need Enterprise or Security
3.2.4 automated alarms	Event definitions run in real time and on historical searches, triggering notifications without manual review of each log.	Graylog Open; confirm which notification types your edition includes
3.2.5 retention for a predefined period	Create index sets per log category with rotation and retention settings that match your documented period. Confirm retention with your legal and compliance owners, since the regulation sets no fixed period.	Graylog Open; archive restore and data tiering need Enterprise
3.2.5 protection from unauthorized access or change	Restrict index set, stream and dashboard access with roles. Limit who can edit pipelines and event definitions, and keep backend storage under separate access control.	Graylog Open for roles; confirm audit features in your edition
3.2.6 time synchronization and redundant logging	Synchronize all sources and Graylog nodes with trusted time sources. Run three Graylog and MongoDB nodes with a replica set, three Data Nodes, and a load balancer, with is_leader set to false on followers.	Graylog Open; multi-node setup follows Graylog's documented layout
3.2.6 independent availability monitoring	Monitor Graylog and its backends from a separate system that does not depend on the Graylog cluster. Alert on journal growth, node loss and missing input traffic.	Graylog Open for node health; the external monitor is your own tool

Which events to collect for point 3.2.3

Point 3.2.3 of the Annex to Implementing Regulation 2024/2690 lists the event categories logs should cover, but only where appropriate for your systems. Each category below maps to sources that reach Graylog through the inputs and collectors described on the integrations page.

Network traffic events

Firewall, VPN, proxy and DNS logs show which systems talk to which, and from where. In Graylog, send these over syslog or a collector into a dedicated stream so traffic from critical segments can be searched and alerted on separately. Check that devices forward both allowed and denied connections, since denied traffic is often the first sign of a scan or misconfiguration. Confirm the volume per device before sizing indices.

User creation and permission changes

Account creation, group membership changes and role assignments are the events that show who gained access and when. Collect them from your directory, identity provider and each administered application. In Graylog, route them to a stream and build an event definition that fires on any change outside an approved change window. Verify that the source logs the actor, the target account and the old and new permissions.

Access and authentication events

Successful and failed sign-ins, MFA challenges and session starts show whether the right people are using the systems. Pull these from identity providers, VPN concentrators and key applications. In Graylog, count failures per account and source address over a short window so that password spraying and credential stuffing raise alarms. Confirm that failed attempts are logged, not only successful ones.

Privileged activity

Administrator sessions, sudo or root commands, and changes made with elevated rights need their own review. Collect them from operating systems, hypervisors, cloud consoles and database servers. In Graylog, tag these events so they can be filtered and reviewed on their own dashboard. Ask each system owner which privileged actions they can log, because some platforms log elevation but not the commands run after it.

Critical configuration and backup file access

Changes to firewall rules, server configuration and backup catalogs, along with reads and writes to backup files, are central to resilience and to detecting tampering. Collect file integrity and configuration audit events from hosts and backup software. In Graylog, alert on modifications to backup repositories outside scheduled jobs. Check that the backup system itself writes its own logs to Graylog.

Security tool logs

Logs from endpoint protection, intrusion detection, vulnerability scanners and the monitoring tools themselves show whether security controls are working. Forward them from each tool to Graylog. Include alerts about stopped agents or disabled sensors, because a silent security tool is a gap in detection. Confirm that each tool supports remote forwarding, since some keep logs only on the local console.

Resource use events

CPU, memory, disk and service availability metrics reveal denial of service, runaway processes and cryptomining. Collect them from hosts, containers and key services. In Graylog, set thresholds on sustained high use or disk filling and tie them to the same alarm workflow as security events. Decide which thresholds are security signals and which are operational, so the response team is not flooded.

Physical and environmental events

Door access, badge readers, camera alerts, power failures, temperature and humidity warnings show threats to the hardware that hosts your systems. Ask facilities and data center operators which of these systems can export logs or send syslog. Where they cannot, record the gap in the risk assessment. In Graylog, route these events to a separate stream so facilities staff can review them without access to other log data.

How event definitions turn log review into alarm thresholds

Point 3.2.4 of the Annex to Implementing Regulation 2024/2690 asks for regular review of logs for unusual trends, with alarm thresholds that trigger an alarm, automatically where appropriate, followed by a timely, qualified response. In Graylog, the mechanism that performs this job is the event definition. An event definition runs a search against the log data, either in real time against new messages or against a historical window, and raises an event when a condition is met. For NIS2, the practical design task is to decide which conditions matter for the elements listed in point 3.2.3, such as repeated failed authentications, user creation or permission changes outside change windows, and access to backup or critical configuration files. Each of those conditions needs a search, an aggregation threshold (for example, a count of matching messages per grouping key within a time window), and a priority. Thresholds should be set against your own baseline, which you will need to establish during the first weeks of collection rather than assume.

Notifications are configured separately from the definition. Graylog Open's product page lists PagerDuty, Slack and email as notification destinations, so routing decisions should map each priority to a destination and a named on-call owner. Document who receives each alarm, what the expected acknowledgement and response steps are, and how a response is recorded. The regulation asks for a qualified response, so the runbook should name the role that triages each alarm and the criteria for escalation. Advanced correlation across multiple sources and the prebuilt detection content are not part of Graylog Open. Graylog's pricing page describes the correlation engine as part of Graylog Enterprise and detection content, risk scoring and investigations as part of Graylog Security, so confirm with Graylog which of these your design requires before you depend on them for alarm coverage.

Configuring Graylog for point 3.2 in sequence

This sequence turns the monitoring and logging duties of point 3.2 into a working Graylog configuration, from defining what is collected to proving that alarms reach a responder. Each step produces an artifact you can show to an assessor, such as a source inventory, index set settings, event definitions and test records.

Define in-scope systems and log categories
Start by listing the network and information systems that fall within your NIS2 scope, then map each one to the log categories point 3.2.3 expects, such as authentication events, user creation and permission changes, privileged activity, access to critical configuration and backup files, security tool logs, resource use, and physical access or environmental events where they apply. The security or compliance lead owns this list, with system owners confirming their sources. The step is complete when every in-scope system has a named owner and each required category is either assigned to a source or recorded as not applicable with a reason.
Deploy inputs and route sources into streams
Configure the Graylog inputs that receive logs from each source, such as syslog, GELF or Beats, and confirm that the sources send the categories listed in the previous step. Route messages into streams by system or category so that security-relevant events can be searched, alarmed and retained separately from routine application noise. The platform team performs this work, and the check is a test message from each source appearing in the expected stream, with the input status shown as running.
Set processing pipelines for consistent fields
Build processing pipelines that parse raw messages into consistent fields such as user, source address, event type and outcome, so that event definitions can match the same field across different systems. Keep pipeline rules documented and versioned, because a parsing change can silently alter what an alarm sees. The reviewer confirms by searching sample events from each source and checking that the expected fields are populated. Confirm the pipeline behavior with your Graylog version, since parsing changes are a known part of upgrade planning.
Create index sets matched to the retention period
Create index sets for security logs and set rotation and retention so they match the predefined period your entity has chosen under point 3.2.5. Graylog rotates indices by message count, size or time and deletes the oldest indices under the retention setting, so a retention value shorter than your policy will remove evidence on schedule without any warning. Record the chosen period, the rotation strategy and the owner who approves changes, then check the configured retention against the written policy. The check is a review record showing the index set settings next to the policy text. The regulation does not set a fixed period, so the value must come from your own risk assessment and any national requirements you confirm.
Build event definitions and notifications
Create event definitions that implement the alarm thresholds your monitoring design sets for unusual trends and high-risk events, such as repeated failed logins, privilege escalation or logging gaps. Where appropriate, configure the alarm to trigger automatically, and route notifications to the on-call channel that your response process uses. Note that the notification options and their edition requirements should be confirmed against your Graylog license, since some alerting features are tied to editions. The check is a saved list of event definitions with thresholds, owners and notification targets, each traceable to a line in the monitoring design.
Set time synchronization and monitor logging availability
Confirm that the Graylog nodes, the MongoDB and search backends, and the log sources all use synchronized time sources, which point 3.2.6 requires to the extent feasible. Set up a separate availability check for Graylog itself, run from a system outside the monitored environment, so that an outage of the logging platform is noticed even if it cannot report its own failure. Assign that check to the operations team and verify it by stopping a non-production node and confirming that the outage alert fires. Document the time source and the independent check as evidence.
Test alarms end to end and keep the records
Run controlled test events through each source and each event definition, then follow each alarm through notification, acknowledgment and the documented response. Record the test date, the event injected, the alarm raised, the person notified and the response taken, because ENISA's June 2025 guidance lists records of past alarms and configured thresholds as examples of evidence. Repeat the test after any pipeline, index or event definition change. The step closes when every event definition has at least one recorded end-to-end test and the records are filed where an assessor can sample them.

Evidence ENISA suggests and how Graylog produces it

ENISA's June 2025 guidance names kinds of evidence an assessor may ask to see for point 3.2. In Graylog, most of that evidence comes from a few objects: event definitions, search results, alert history and index settings. The cards below show what each artifact is, how to produce it and how to keep it in a dated, access-controlled archive.

SIEM records from Graylog

Graylog search results and dashboards are the SIEM-style records most teams will show first. Export saved searches and dashboard snapshots for the sources that carry the point 3.2.3 elements, and record the time range and stream each export covers. Check that the stream routing still sends each source to the index set you intend, because an export from a stream that silently stopped receiving events proves little. Confirm with your assessor whether they expect raw search output, dashboards or both.

EDR and XDR outputs

ENISA lists EDR or XDR tool output as evidence. Graylog does not replace those tools, but it can collect their alerts and telemetry through inputs such as syslog or GELF, so that endpoint detections sit next to server and identity logs in one search. Keep a record of which agents forward to Graylog, the input each one uses, and the date each was last confirmed as sending. Ask the EDR vendor which exports they can produce for an audit and whether those exports are kept outside the EDR console.

Log samples with 3.2.3 elements

Assessors often ask for a sample of logs showing that the required categories are actually collected, such as authentication, privileged activity, user and permission changes, and access to backup files. Build a dated sample per category from a real search, with timestamps, source hosts and message fields visible. Redact personal data before export, and document the redaction rule so the sample can be reproduced. A sample from a category with no matching messages should be recorded as a gap, not left out.

Configured alarm thresholds

The configured event definitions are the proof that point 3.2.4 alarm thresholds exist. Export each definition with its search query, aggregation conditions, time window, priority and notification target. Store the export under version control or with a change record, so you can show what the threshold was on a given date. Point out which definitions run automatically and which need a person to act on them, because the regulation expects automation where appropriate.

Records of past alarms

An alarm history shows that thresholds fired and that someone responded in a timely, qualified way. Export the triggered events for the review period, with their timestamps, status changes and the ticket or incident reference that recorded the response. Gaps matter as much as hits: an assessor will ask what happened in a quiet week. Confirm how long your Graylog deployment keeps event and notification records, because that retention may be shorter than the period you need to show.

Dated, access-controlled evidence archive

Evidence is only useful if it cannot be quietly altered. Store each export in a write-once or access-restricted location with a fixed naming scheme that includes the export date and the source. Keep the index retention settings in the same archive, since they show how long the raw logs existed. Limit who can read the archive, log access to it, and review that list on a schedule. Ask your auditor how they want exports hashed or signed before you start producing them.

Protecting logs and keeping them redundant

Point 3.2.5 of the Annex to Implementing Regulation 2024/2690 requires logs to be kept and backed up for a predefined period and protected from unauthorized access or changes, while point 3.2.6 requires monitoring and logging systems to be redundant and their availability to be monitored independently of the systems they watch. The regulation sets no retention period, so the number of days must come from your own written logging policy and any national rules that apply to you. Confirm that figure with your compliance lead before you size anything, because it drives storage cost more than any other setting.

For redundancy, Graylog's multi-node guide recommends three Graylog and MongoDB nodes with MongoDB running as a replica set, three Data Nodes in their own cluster, and a load balancer in front of the Graylog servers. Set is_leader to false on every follower Graylog node so only one node runs leader-only tasks. Size storage from daily ingest multiplied by retention days and by 120 percent, and give the message journal 3 to 5 times daily ingest on SSDs, so a backend outage does not lose events in transit. Test a node failure and a Data Node failure in a non-production environment and record the results as evidence.

Restrict who can read and change log data by assigning Graylog roles to named groups, limiting administrator rights to a small set of accounts, and tying sign-in to your central identity provider. Graylog Open supports Active Directory, LDAP and trusted header authentication, while Graylog Enterprise adds Okta, OpenID Connect and SAML single sign-on, so confirm which option your edition supports before you design the access model. Keep the Data Node and MongoDB backends off user networks, back up configuration and index snapshots on a schedule, and log administrative changes to retention and index settings so that any deletion of evidence is visible.

Questions buyers ask about Graylog and NIS2 logging

How much does it cost to run Graylog Open compared with Enterprise or Security?

Graylog Open is free to download and run, with no volume limits, but support is community support only. Graylog Enterprise starts at 15,000 US dollars per year and Graylog Security starts at 18,000 US dollars per year, according to the Graylog pricing page. Both paid editions have a minimum of 10 GB per day or 100 Graylog Compute Units, and they are licensed on processed data with no per-user or per-device fees. Your infrastructure costs (servers, storage, MongoDB, Data Node or OpenSearch, and backups) and any implementation services are separate and recur or arise regardless of edition. Confirm current pricing, minimums and what each tier includes directly with Graylog before budgeting, because the figures can change.

Do we need an Enterprise or Security license for NIS2 event alerting?

It depends on which features your design needs, so confirm this before you choose an edition. Graylog Open supports event definitions for alerting, with notifications to channels such as email, Slack and PagerDuty. Graylog Enterprise adds a correlation engine and 24/7 support, and Graylog Security adds investigations, anomaly detection and prebuilt detection content. Point 3.2.4 of the Annex to Implementing Regulation 2024/2690 expects alarm thresholds that trigger alarms, so map each required alarm to the edition that provides the feature. Also check whether inputs you need for network devices or cloud services require a paid license.

How long does a Graylog build for NIS2 logging take?

No fixed duration can be given here, because the timeline depends on the scope agreed in writing. The main drivers are the number of log sources and the input method for each, the number of event definitions and notifications, the size of the cluster needed for your daily ingest and retention, whether you need redundant Graylog and MongoDB nodes with a load balancer, and how many systems must be integrated with identity and time sources. Most engagements are fixed-scope, so ask for a written plan that lists deliverables, dependencies on your teams and acceptance checks before work starts.

What must our team supply before a Graylog build starts?

Your team needs to supply an inventory of the systems in scope and the event types each must produce, access to those systems and their network paths to the collectors, identity and directory details for authentication, and the retention period your risk assessment and national rules require. You should also provide the time sources your systems use, the alarm recipients and on-call process, the storage and hosting environment (cloud accounts, data centers or restricted networks), and the people who will review alerts. Where personal data appears in logs, decide the handling rules first, and involve legal counsel where transfers outside the EU could occur.

Can our internal team implement and run Graylog for NIS2 without a partner?

Many organizations with experienced platform, network and security engineers can do this in-house, and the Graylog documentation covers packages, Docker, multi-node layouts and index management. The work that usually takes the most effort is the design: mapping point 3.2.3 event types to real sources, writing event definitions that catch unusual trends without flooding responders, protecting log access, and producing evidence. Weigh your team's capacity against those tasks, the skills needed to operate MongoDB and the search backend, and the cost of an on-call rotation. A partner can take on a fixed scope while your team keeps ownership of operations.

Does using Graylog make our organization NIS2 compliant?

No. NIS2 creates no certificate of compliance, and Graylog is a tool that can support the monitoring and logging measures in point 3.2 of the Annex to Implementing Regulation 2024/2690. Compliance depends on your whole risk-management program, your classification as an essential or important entity, and how your national authority applies its transposition law. Authorities oversee compliance through inspections, audits, information requests and fines. DeployOpen prepares systems, controls and evidence for assessments but does not issue audit reports or certifications. Confirm your obligations with your national competent authority and qualified legal counsel.

What evidence should we keep to show our Graylog monitoring works?

ENISA's June 2025 technical guidance lists examples of evidence that include SIEM system records, EDR or XDR tool records, log samples containing the point 3.2.3 elements, configured alarm thresholds and records of past alarms. Keep the event definition configurations under change control, export representative log samples, and retain a record of how each alarm was triaged and answered. Ask your auditor or assessor which format they expect, because ENISA's guidance is non-binding and national authorities may set their own expectations.

Does the NIS2 proposal from January 2026 change what we need to build?

The Commission proposed targeted amendments to NIS2 on 20 January 2026 (COM(2026) 13), including a new small mid-cap category. The proposal still needs approval by the European Parliament and the Council, so it is not yet law. Design your logging to the rules in force today, and check the status of the proposal with your legal advisers and national authority before you finalize scope or contract terms.

What Graylog and this work do not cover

Graylog produces the event records, alarms and review trail that NIS2 monitoring depends on, but it does not set the retention period, the legal duties or the licensing terms around them. The cards below cover the gaps a CISO or compliance lead should resolve before treating a Graylog deployment as NIS2 evidence.

Retention period is your decision

Point 3.2.5 requires logs to be kept and backed up for a predefined period and protected from unauthorized access or changes, but the regulation sets no fixed number of days. Graylog enforces whatever you configure through index rotation and retention, so the period must come from your own risk assessment and any national transposition law. Document the chosen period and the reasoning, and confirm the backup copy is protected as well as the live index.

Graylog Open license limits

Graylog Open is licensed under SSPL-1.0, which is not an OSI-approved open source license, and earlier releases were under GPL v3. Before you build a regulated monitoring process on it, have legal review whether the license terms fit your own use and any hosted service you offer. Confirm the license obligations with your counsel and the license file in the repository rather than relying on a general summary.

Enterprise and Security feature gaps

Some detection and archive capabilities sit outside Graylog Open. Data tiering, archive restore and the correlation engine belong to Graylog Enterprise, while risk scoring, anomaly detection, investigations and compliance packs belong to Graylog Security. Map each control in your design to the edition that provides it, and confirm which features your chosen license includes before you promise automated alarms or long-term archive restore to an auditor.

Logs do not replace risk management

Logs show what happened on your systems, but they do not carry the duties in Article 21 for risk analysis, policies, supply chain security and business continuity, nor the reporting duties in Article 23 for significant incidents. A well-tuned event definition can flag a suspicious login, yet it cannot decide whether the event is significant or who must be notified and by when. Keep incident classification and reporting procedures as separate, tested processes that use Graylog records as input.

COM(2026) 13 is still a proposal

The Commission proposed targeted amendments to NIS2 on 20 January 2026 under COM(2026) 13, including a new small mid-cap category. The proposal still needs approval by the European Parliament and the Council, so the current obligations remain those of the directive and its transposition laws. Track the proposal's progress with your national authority and review your scoping and evidence design again if the amendments are adopted in a changed form.

Hosted log transfers fall under GDPR

If logs contain personal data and a hosted or managed service stores or accesses them outside the EEA, every transfer must meet GDPR Chapter V, including onward transfers and remote access from a third country. Graylog self-hosted in your own infrastructure avoids many of these questions, but support engineers, managed partners and cloud storage can still create transfers. Map where log data is stored, who can view it and under which law a provider could be compelled to disclose it, before you choose a hosting model.

Where the log data lives and who can access it

Logs collected for NIS2 point 3.2 often contain personal data: usernames, source IP addresses, email addresses in authentication and mail events, and identifiers in application records. That makes the Graylog deployment a personal data processing activity in its own right, so the first decision is where the Graylog server nodes, the MongoDB configuration store and the Data Node or OpenSearch indices physically run and which legal entity operates them. Self-hosting in cloud accounts or data centers the entity controls keeps storage under its own control, but it does not answer every question on its own. Confirm the regions where each component, including backups and snapshots, is stored, and confirm who holds administrative access to the hosts and hypervisors.

The European Data Protection Board's Guidelines 05/2021 treat remote access from a third country as a transfer, even when a support engineer only views data on a screen, and they treat storage in a cloud outside the EEA as a transfer as well. A Graylog deployment operated by an outside partner, or hosted by a provider with support staff abroad, therefore needs the access path mapped as well as the storage location. The same guidelines note that using an EU processor subject to third-country law is not itself a transfer, but complying with a third-country authority request would be. Before engaging any processor, assess whether that processor could be compelled to disclose log data held in the Union, and whether the protections in EDPB Recommendations 01/2020 could realistically address that exposure. This is a question to assess with counsel, not legal advice.

How essential and important entities approach the same logging duties

Essential and important entities are bound by the same risk-management obligations under Article 21 and the same reporting obligations under Article 23 of NIS2. For monitoring and logging, that means both must run procedures and tools that monitor and log activity on their network and information systems, with alarm thresholds, regular review and protected retention as set out in point 3.2 of the Annex to Implementing Regulation (EU) 2024/2690. The regulation does not create a lighter standard for important entities. The difference lies in how and when the national competent authority checks whether that work exists and functions.

Same technical scope: Both categories must cover the point 3.2.3 log elements where appropriate, including authentication, privileged activity and access to backup files.
Same review duty: Both must review logs regularly for unusual trends and respond to alarms in a timely, qualified way.
Same protection duty: Both must keep logs protected from unauthorized access or change and back them up for a predefined period.
Same reporting link: Detection quality feeds the timing of incident reporting under Article 23, so both need alarm records that show when an event was noticed.
Different supervision: Essential entities face ex ante supervision and important entities face ex post supervision under Articles 32 and 33.

Before designing anything, confirm with your national transposition law which category your organization falls into and which authority supervises it.

How DeployOpen scopes and delivers NIS2 logging and evidence work

DeployOpen plans, implements, hardens, documents and supports self-hosted Graylog inside your own infrastructure, including cloud accounts, data centers or air-gapped networks. For NIS2 monitoring and logging, we turn point 3.2 of Implementing Regulation 2024/2690 into a written scope, a working Graylog configuration and an evidence set your own team can maintain. DeployOpen prepares systems and records for assessment but does not issue certifications or attestations.

How we scope

Engagements are fixed-scope, with deliverables and timelines agreed in writing before work starts.
The written scope lists which log sources map to the point 3.2.3 event categories, and which are out of scope.
We agree the alarm thresholds, responders and response timelines your team must own before configuration begins.
Retention periods are set with your legal, compliance and risk owners, since the regulation sets no fixed period.

How we build

We deploy Graylog server nodes, MongoDB and the Data Node or OpenSearch backend in your environment, with redundancy designed in.
Event definitions are built and tested against replayed or sample log data, so alarms fire as the scope describes.
Time synchronization, index protection and access restrictions on log data are configured and checked against the scope.
A separate availability check for the logging platform is designed so failures in Graylog itself are noticed.

How we hand over

We document the source inventory, parsing rules, event definitions, retention settings and access model for your team.
Evidence samples are produced in the form ENISA lists, such as log samples, alarm thresholds and records of past alarms.
Runbooks cover alarm triage, response records, backup and restore of the logging stack, and routine review tasks.
Handover includes a walkthrough with the engineers and reviewers who will operate the deployment day to day.

How we support

Ongoing support, upgrades and continuous testing are available as retainers after handover.
Support can cover Graylog version upgrades, parsing and event definition changes as new log sources are added.
Periodic checks of log coverage, retention and alarm behavior can be scheduled under a retainer.
Questions about legal interpretation or national transposition should go to your counsel or competent authority.