Graylog for ISO 27001 logging and monitoring

Which ISO 27001 logging and monitoring controls Graylog helps with

If you are preparing an ISMS for certification, Graylog can give you the central log store and review records that the logging and monitoring controls expect, but it does not make you compliant on its own. The controls that matter most are Annex A 8.15 Logging, Annex A 8.16 Monitoring activities and Annex A 8.17 Clock synchronization, with A.5.28 Collection of evidence supporting them. Graylog configuration supports each of these. The certification decision belongs to an accredited certification body, because ISO does not certify organizations itself.

A.8.15 is the 2022 edition's merged version of three 2013 controls: A.12.4.1 Event logging, A.12.4.2 Protection of log information and A.12.4.3 Administrator and operator logs. If your existing evidence was mapped to the 2013 numbers, update your statement of applicability and control mapping so each 2013 reference points to the new control. Graylog maps naturally to the merged control: inputs and streams collect events, index retention and access roles protect them, and dashboards and event definitions support analysis. Confirm the exact wording of each control with the standard itself, and check with your certification body how it expects the mapping to be presented.

Graylog does not satisfy any control by itself. Auditors sample the records your processes produce: which sources were configured, who can read and change log data, how alerts were triaged and closed, and whether clocks were synchronized across sources. Decide early which events are in scope, who owns each review, and how review outcomes are recorded. Ask your certification body which evidence it expects for an ISMS of your size and risk profile, and confirm the configuration and retention periods against your own risk assessment before the audit starts.

Mapping A.8.15, A.8.16 and A.8.17 to Graylog capabilities and configuration

This table pairs each relevant ISO/IEC 27001:2022 Annex A control with the Graylog capability that supports it and the configuration an assessor will expect to see. Requirement wording is paraphrased, so read the control text in the standard itself before relying on any row. Use it as a checklist: each row names the setting you must be able to show, not just that the feature exists.

Requirement (paraphrased)	Graylog capability	Configuration needed
A.8.15 Logging: produce logs of activities, exceptions, faults and other relevant events	Inputs (syslog, GELF, Beats) receive events; streams route them by source and type	Define one input per log source class, enable them on the server nodes, and document which systems send to which input and why
A.8.15 Logging: store logs for a defined period	Index sets with rotation by message count, size or time, and retention that deletes the oldest indices	Set rotation and retention per index set to match the period in your logging policy, and record the values as the approved setting
A.8.15 Logging: protect log information from tampering and unauthorized access	Role-based access on streams and index sets; Data Node or OpenSearch storage managed separately from user access	Restrict admin roles, limit who can change retention or delete indices, and confirm the storage backend is not writable by ordinary users
A.8.15 Logging: analyze logs for relevant events	Search, dashboards and pipelines that parse and enrich fields for review	Build saved searches and dashboards for administrator actions, authentication failures and faults, and assign an owner for each review
A.8.16 Monitoring: detect anomalous behavior	Event definitions for real-time and historical conditions; correlation and anomaly features depend on edition	Create event definitions for defined anomaly patterns; confirm which detection features your Graylog edition includes before promising them
A.8.16 Monitoring: evaluate potential incidents	Notifications to email, Slack or PagerDuty from event definitions	Configure notification targets, priorities and a triage record that shows who received each alert and what was done
A.8.17 Clock synchronization: consistent time across systems	Timestamps on ingested messages are only as accurate as the sending host and Graylog nodes	Run a time synchronization service on every Graylog, MongoDB and Data Node host and on each log source; record the reference source and check it routinely
A.5.28 Collection of evidence: preserve records usable in investigations	Archived and retained indices, plus search exports for case files	Define how and when evidence is exported, who approves it, and where copies are kept with their integrity recorded

How logs move from source to reviewed record in Graylog

A log becomes ISO 27001 evidence only when it can be traced from the system that produced it to a search, dashboard or event definition that someone reviews. In Graylog, that path runs through inputs such as syslog, GELF and Beats, then through streams and processing pipelines that route each message, then into index sets that hold it under rotation and retention settings, and finally into the search, dashboard and event definitions your monitoring relies on. Each stage is a place where a record can be lost, misfiled or left out of review, so the design should be documented stage by stage and tested with a known test event.

Administrator activity needs deliberate routing. Privileged actions on hypervisors, directory services, databases, firewalls, Kubernetes and the Graylog server itself do not arrive in a shared stream by default. Decide which sources emit administrator and operator events, confirm each input receives them, and send them to a stream with its own index set and retention. Confirm with each vendor which audit settings must be enabled on the source, since Graylog can only store what the source emits. Keep the Graylog administrator actions in scope too, because those are the entries an auditor will ask about first.

Survival of logs during failure depends on the message journal and the cluster layout. The journal buffers messages on disk between input and indexing, so its size and SSD storage determine how much data a Graylog node can hold if the search backend slows or stops. Graylog's system architecture guidance advises sizing the journal at 3 to 5 times daily ingest on SSDs. The multi-node guide recommends three Graylog and MongoDB nodes, a MongoDB replica set and three Data Nodes on their own cluster behind a load balancer. Test a node loss and a Data Node outage during your ISO 27001 readiness work, then record what was retained and how the gap was detected.

What Graylog produces for an auditor to sample and how to keep it

An auditor testing A.8.15 and A.8.16 will ask for proof that logging was configured, retained, protected and reviewed, not just that Graylog is running. The cards below list the Graylog records that answer those questions and how to export, version and present them. Whether a given set is sufficient is the auditor's decision, so agree the evidence set with them before the sample is drawn.

Input and source inventory

Export the list of configured inputs (syslog, GELF, Beats and others) with their bind addresses, ports, types and assigned nodes, and record which source systems send to each one. This is the baseline an auditor uses to check that in-scope systems produce logs at all. Export it through the Graylog API or System pages, store the output as a dated file in version control, and reconcile it against your asset inventory. Confirm which inputs your edition allows, since some require Enterprise.

Stream and pipeline configuration exports

Streams and processing pipelines decide where each log type goes and which parsing or enrichment applies. Export the stream rules and pipeline rule source as text, then commit them to a Git repository with a change record for every edit. Be ready to show that the configuration in effect matches what was approved, and that changes to routing went through review.

Index set retention settings

Retention in Graylog comes from index set rotation and deletion settings: rotation by message count, size or time, and deletion of the oldest indices. Export each index set configuration and record the retention you set against the retention period your policy requires. Keep a dated copy of each change, because an auditor will compare the retention shown on the day of the sample with the one your policy states.

Event definition records and notification history

Event definitions show which conditions Graylog watches for and who is notified. Export the definitions as configuration and keep notification history for the same period, so you can show that a defined condition fired and that someone received it. Confirm which notification channels your edition provides, because the supported destinations depend on the product and license in use.

Role and access configuration for log data

Auditors look for restricted access to log data and to the logging system itself. Export roles, permissions and stream-level sharing for each group, and export the authentication settings that tie users to your identity provider. Record who holds administrative rights over Graylog and review that list on a fixed cycle. Confirm that administrator actions are themselves recorded in a location your administrators cannot edit.

Documented review record for alerts

A.8.16 expects monitoring to detect anomalous behavior and support incident evaluation, so the review of alerts matters as much as the alerts. Keep a dated record for each review cycle: who reviewed, which event notifications and searches they examined, what they found, and what action followed. Store these records with the exports above so that a sampled alert can be traced from detection to a documented outcome.

Choosing a Graylog edition and search backend for ISO 27001 scope

Graylog Open is free with no volume limits and community support, and Graylog recommends Data Node as the search backend for new deployments. Data Node is Graylog's own storage layer, so the search, index management and retention settings sit within one vendor-documented stack. For an ISO 27001 scope, this option keeps the log store, retention rules and access paths on the path Graylog documents most directly, which simplifies the evidence you show an auditor.

Documented path: Graylog's installation guidance recommends Data Node, so your build and upgrade notes can follow the vendor's own sequence.
Cost profile: The software license is free, but you pay for infrastructure, operations time and any external support you buy.
Community support: Open has community support only, so your response times depend on your own team and the public community.
Licensing limits: Graylog Open is licensed under SSPL-1.0, which is not an OSI-approved license. Have legal review it against your policy.
Feature gaps: Archive restore, correlation and compliance packs sit in paid editions, so confirm whether your control design needs them.

Confirm current licensing terms with Graylog before you commit, because the pricing page and license may change.

Configuring Graylog for A.8.15 and A.8.16 in order

This sequence takes Graylog from an asset-based logging scope to a documented review cycle, so each logging and monitoring decision traces back to a system the ISMS already tracks and can be shown to an auditor.

Define the logging scope from the asset register
The ISMS owner and the platform team list the systems that process, store or transmit in-scope information, then mark which of them record activities, exceptions, faults and administrator actions. Each asset class gets a named log source, an owner and a stated reason for collection. The step is done when every in-scope asset has an entry in the register that points to its log source, and the gaps are logged as open items with an owner.
Deploy the multi-node Graylog layout
The platform team installs Graylog server nodes, MongoDB and the search backend on the layout Graylog documents for medium to large deployments, with MongoDB as a replica set, a separate Data Node cluster and a load balancer in front of the Graylog nodes. Follower nodes are set with is_leader to false. The step is done when the cluster reports healthy members, a test message sent through the load balancer is searchable, and a failover of one node leaves ingestion running. Confirm the supported MongoDB and Data Node versions against the compatibility matrix for the Graylog release you choose.
Set NTP and time zone on every log source
Administrators configure a time source on Graylog nodes and on every system that sends logs, and they standardize the time zone so timestamps from different sources can be ordered during an investigation. This supports the clock synchronization expectation in A.8.17, which is closely tied to A.8.15. The step is done when a sample of hosts from each asset class reports the same offset from the chosen time source, and the expected time zone is recorded in the logging standard. Ask the infrastructure team to confirm how the time source is protected and monitored in your environment.
Create inputs and streams per asset class
Engineers create inputs such as syslog, GELF or Beats for each asset class in the register, then use streams and processing pipelines to route events from administrative systems, security tools and application components into separate streams. Each stream maps to an owner and an index set. The step is done when test events from each source arrive in the correct stream, and the stream-to-asset mapping is saved in the logging standard so that reviewers can confirm coverage.
Set index retention to the defined period
The compliance owner states the retention period for each stream, and the platform team configures index rotation and retention on the matching index sets. Retention is set to delete the oldest indices only after that period has passed, and rotation thresholds are sized using the daily ingest and retention formula in the Graylog architecture guidance. The step is done when a test index set shows the configured rotation and retention values, and the retention settings are exported into the evidence folder with the approval record.
Restrict access to log data by role
Administrators create Graylog roles that limit who can search, view and export each stream, and they separate the people who administer Graylog from the people who review its events. Authentication is connected to the directory the organization already uses, using the options available for the edition in use. The step is done when a test account from each role can see only its permitted streams, and the access matrix is approved and stored with the ISMS records. Confirm which identity integrations your edition supports before you commit to a design.
Build event definitions for admin and failure events
Engineers write event definitions for privileged account use, configuration changes to Graylog and sources, and failures such as stopped log forwarding or ingestion gaps. Notifications route to the on-call or security queue, and each definition has a named owner and priority. The step is done when a controlled test event triggers each definition, the notification reaches the right channel, and the test result is recorded. This is the monitoring activity behind A.8.16, which is intended to detect anomalous behavior and evaluate potential incidents.
Run and document the review cycle
The security operations lead sets a review schedule for the dashboards, triggered events and access list, and reviewers record what they examined, what they found and which events became incidents. Reviewers also check for gaps in log collection and any changes to retention or roles. The step is done when the first review record is signed, the findings are tracked to closure, and the review schedule is written into the ISMS procedures. The schedule itself should be set by your own risk assessment and confirmed with your auditor.

What Graylog does not cover for ISO 27001 and who has to close each gap

Graylog collects, stores and searches events, but it cannot decide what the organization must log, fix silent source systems, run the management system, or grant certification. Each card names the party that has to close the gap before an auditor samples the evidence.

Deciding which events are logged

Annex A 8.15 expects logs of relevant activities, exceptions and faults, but the list of relevant events is a risk and policy decision. The ISMS owner, with input from system owners and the risk assessment, must define the event types, retention periods and review responsibilities. Graylog only applies the decisions you configure in inputs, streams and event definitions. Check that every logging rule traces back to a documented requirement.

Source systems that emit weak audit events

Some applications, appliances and SaaS tools write little or no administrator activity, or write it only to local files that rotate away. Graylog cannot record what a source never emits. The platform owner should inventory each source, confirm which audit events it produces and enable them, and document any system where logging must be built, configured or accepted as a risk.

Management review and internal audit

Reviewing monitoring results, acting on recurring findings and checking that logging works are obligations of the ISMS, not of the log platform. The management team and the internal audit function must schedule reviews, sample Graylog evidence such as event definition history and triage records, and record decisions. Graylog can hold the data, but it does not decide whether the process is effective.

The certification decision

Only an accredited certification body can certify the ISMS, and ISO does not certify organizations. The certification body samples logging evidence during its audit and decides the outcome. Your team prepares the evidence and runs the process, but no Graylog configuration, report or dashboard substitutes for an audit. Confirm the certification body and its accreditation before planning the evidence pack.

SSPL terms for Graylog Open

Graylog Open is licensed under the Server Side Public License version 1, which is not an OSI-approved open source license. Legal and procurement teams must review whether the license terms fit how the organization offers and hosts the platform, particularly if logging services reach third parties. Obtain written legal review before the design is final, because the license affects commercial reuse and hosting choices.

Features that need a paid license

Some capabilities that help with monitoring, such as data lake archive restore, data tiering, correlation, investigations, compliance packs and prebuilt detection content, need Graylog Enterprise or Graylog Security. The budget owner and security lead must decide whether these are needed to meet the design, then confirm current edition terms with Graylog before relying on them in the control design.

Questions CISOs ask before hiring help with Graylog for ISO 27001

How much effort does a Graylog setup for ISO 27001 logging take?

The effort depends mostly on how many log sources you need to bring in, how many of them are administrator or security-relevant, and how much of the monitoring review you want built into Graylog rather than run by hand. A small set of Linux hosts, a firewall and an identity provider is a very different job from dozens of application, database and cloud sources with different formats. Other drivers include the number of teams who need search access, how many event definitions you need for alerting, whether the design includes a multi-node cluster, and how much existing evidence must be mapped to the control. Ask any partner for a quote built from a written list of sources, retention periods, access groups and alert use cases, not from a headcount guess.

Can our internal team build Graylog for ISO 27001 without outside help?

Often yes, if the team already runs Linux services, understands log formats and has time to test. The work splits into platform tasks (installing servers, MongoDB, the search backend and the load balancer), data tasks (inputs, streams and processing pipelines for each source) and control tasks (mapping events to A.8.15 and A.8.16, writing review procedures, and producing evidence). Teams usually struggle with the control tasks, because the auditor will ask why each source was chosen and how reviews are recorded, not only whether logs arrive. A useful test is whether someone on your team can explain the retention design, the protection of log data and the alert workflow without looking it up. If not, a fixed-scope engagement can cover the gap, with the written scope and deliverables agreed before work starts.

How long does a Graylog build for ISO 27001 logging usually take?

No duration has been established for this work, so confirm it against your own scope rather than a generic figure. The schedule is driven by the number of log sources to onboard, whether the platform is new or extends an existing Graylog deployment, the sizing and high availability design, and how many approvals and change windows your organization requires. Ask for a timeline in the written scope that separates platform build, source onboarding, alerting and review procedures, and evidence collection. Also ask which parts depend on your teams, such as access to source systems, time server details and sign-off on retention periods, because those dependencies often set the calendar more than the build itself.

What does our organization need to provide for a Graylog logging project?

The work needs decisions and access from your side before any build starts. You will need to name the systems in scope, the owners who approve log sources and retention periods, and the people who will review alerts. Technical inputs include hosting capacity in your cloud accounts, data centers or restricted networks, network paths from sources to Graylog, service accounts that can export logs or configure forwarding, and an authoritative time source for clock synchronization. You should also provide your existing policies on logging, access and incident handling, since the control design must match them. Agreeing these early reduces rework and makes the written scope easier to price and to check later.

Is Graylog Open enough for ISO 27001 logging, or do we need Enterprise or Security?

Graylog Open covers the core needs for collecting logs, routing them through streams and processing pipelines, searching, building dashboards, rotating indices and deleting old data by retention rules, and sending alert notifications. Graylog Open is free with community support and is licensed under the Server Side Public License version 1 (SSPL-1.0), which is not an OSI-approved open source license, so have your legal team review that license against your use. According to the Graylog pricing page, Graylog Enterprise starts at 15,000 US dollars per year and Graylog Security at 18,000 US dollars per year, each with a minimum of 10 GB per day or 100 Graylog Compute Units. Enterprise adds a data lake with archive restore, data tiering, a correlation engine and 24/7 support. Confirm with Graylog which edition covers any specific feature you plan to rely on, such as archive restore for your retention period.

What evidence will an ISO 27001 auditor ask for from our Graylog setup?

Auditors usually sample records rather than read the whole log store. Expect to show which sources are configured for logging, the logging scope and its justification, retention settings and how they were set, who can access log data and how that access is granted and reviewed, and proof that logs are protected from change or deletion. For A.8.16 they often ask for event definitions or alert rules, notification records, and records of reviews and follow-up on alerts. Clock synchronization evidence, related to A.8.17, shows the time source and how Graylog nodes and sources stay aligned. Administrator activity records matter as well. Good evidence is dated, traceable to an owner, and kept outside any single person's control. Ask the implementation partner to define these artifacts in the scope so you know what the Graylog setup will generate.

Does DeployOpen certify our ISO 27001 compliance with Graylog?

No. DeployOpen plans, implements, hardens and documents self-hosted platforms, and prepares systems, controls and evidence for compliance assessments, but it does not issue audit reports, attestations or certifications. ISO does not certify organizations either. Accredited certification bodies perform the assessment against ISO/IEC 27001:2022 and, under ISO/IEC 17021-1:2015 plus ISO/IEC 27006-1:2024, must apply that standard's requirements to their clients. Your certification body decides whether your logging and monitoring controls meet the requirements. Our role is to make the Graylog configuration, the procedures and the evidence ready for that review, and to state clearly which parts remain your responsibility.

What should we check before choosing a partner for Graylog logging work?

Check that the partner can explain the Annex A logging and monitoring controls in their own words and show how each source maps to the records an auditor samples. Ask how the scope is written, what is fixed, what is an ongoing retainer, and which items change the price. Confirm they will design for your Graylog edition and license terms, and that they cover the platform backends, MongoDB, the search layer and load balancing, not only input configuration. Ask for their approach to protecting log data, administrator activity and time synchronization. Finally, ask who on their team will maintain the setup after handover and what recurring support you would need, because monitoring must keep running after the project closes.

How the logging controls are kept working after the audit

Logging controls drift after the audit unless someone owns the recurring work. For A.8.15 and A.8.16, the evidence an auditor samples in a surveillance visit is only convincing if the Graylog deployment kept producing, storing and analyzing logs in the months between visits. Start by assigning an owner for index and storage health. Check the index set rotation and retention settings against the retention period your ISMS has documented, and watch disk use on Data Node or OpenSearch so that retention deletion does not quietly shorten the history you promised. Confirm that the message journal sits on storage sized for your daily ingest, since a full journal is one of the fastest ways to lose log continuity.

Coverage also changes whenever a new system is added. Each time a host, application, identity provider or cloud account starts sending logs, check that its events reach a stream that event definitions actually watch, and that the definitions still match the events that matter for that system. Record the date of each review, who performed it, which definitions changed and why. Upgrades need the same discipline. Before moving to a new Graylog minor or major release, confirm the MongoDB and OpenSearch or Data Node versions against the Graylog compatibility matrix, and test parsing and pipeline rules, because a version change can alter how fields are processed. Confirm the current prerequisites with the Graylog documentation at the time of the change.

Finally, treat review outcomes as records in their own right. A surveillance audit in each calendar year of a three-year certification cycle will ask what was reviewed, what was found and what was done about it. Keep a dated log of storage checks, coverage reviews, upgrade tests, alert triage and any gap in log collection, with the ticket or event reference that closes each item. Ask your certification body which evidence format it expects, since the ISMS sets the required depth, not DeployOpen or Graylog.

How DeployOpen scopes, builds and documents Graylog logging for ISO 27001

DeployOpen plans, implements, hardens, documents and supports self-hosted Graylog inside your own infrastructure, so the logging and monitoring records for Annex A 8.15 and 8.16 sit where your auditors and operators can reach them. We prepare the systems, controls and evidence for your assessment, while independent auditors and certification bodies make the certification decision.

How we scope

Map the systems, applications and identity sources that fall inside your ISMS and must send logs to Graylog.
Agree which event types, administrator actions and clock sources are covered, written as a fixed scope before work starts.
Define retention, access restrictions and review responsibilities for each log source, with the owners named in the document.

How we build

Deploy Graylog server nodes, MongoDB and Data Node or self-managed OpenSearch in your cloud accounts, data centers or air-gapped networks.
Configure inputs, streams, processing pipelines and index rotation so logs are protected and retained as the scope specifies.
Build event definitions and dashboards for monitoring activity, then test alert delivery and confirm time synchronization across sources.

How we hand over

Document the configuration, data flows, retention settings and review procedure in a form your internal team can maintain.
Provide evidence packs that show which log sources were onboarded, how access is restricted and how alerts were tested.
Run a handover session with the operators and reviewers who will work the system after the engagement closes.

How we support

Offer ongoing support, upgrades and continuous testing as a retainer, planned against the Graylog versions you run.
Review new log sources and changes to scope against the written ISMS requirements before they go live.
Confirm with your certification body and auditor which records they expect, since final assessment decisions rest with them.

Graylog for ISO 27001 logging and monitoring controls