Migrate from Splunk to Graylog: what the move involves
A team weighing a Splunk renewal or pricing change and asking whether Graylog can carry its log management should know this first: the move is a re-platforming of ingestion, storage, search and alerting, not a file copy. It is usually run by a platform or security engineering team, often with an implementation partner, because every forwarder, index, saved search and alert has to be rebuilt in Graylog's model before anything is switched off. Historical data can be exported from Splunk for reference, but it does not turn into Graylog streams or index sets on its own. The architecture has more parts than a single Splunk instance. Graylog server nodes keep configuration and metadata in MongoDB, and log storage sits on either Graylog Data Node or self-managed OpenSearch. The compatibility matrix for Graylog 7.0 to 7.2 lists the supported MongoDB and OpenSearch ranges, so confirm those against the version you plan to deploy. Graylog Open is free to self-manage under the Server Side Public License, with no ingestion caps, but that license is not OSI-approved. Your legal team should review it alongside the SIEM-style features, which sit in paid tiers: Graylog Enterprise adds the data lake, the correlation engine and 24/7 support, and Graylog Security adds risk scoring, anomaly detection and prebuilt threat content. The effort and risk sit in three places: the inventory of Splunk inputs and forwarders, the translation of searches and alerts into streams, pipelines and event definitions, and the storage plan for the retention you must keep. Ask the implementation partner for a written inventory of every Splunk source, saved search and alert with an owner, and run Graylog in parallel until each detection produces the same results. Treat the Graylog Open versus Enterprise decision as a requirement question, because the correlation and SIEM features you rely on in Splunk determine which tier you need.
Which Splunk capabilities map cleanly to Graylog
This table maps each Splunk capability used in log management to its closest Graylog equivalent and marks it clean, needs rework or gap. Read the status column first, then the notes, to decide which parts of your current Splunk estate move directly and which need redesign. Most of the work sits in search translation, alert rewrites and any correlation logic that relies on Splunk apps.
| Splunk capability | Graylog equivalent | Status |
|---|---|---|
| Forwarding (universal and heavy forwarders) | Graylog Sidecar managing Beats or Fluent Bit, or syslog and GELF inputs | Needs rework: each forwarder config must be rebuilt as an input or collector |
| Indexes and index routing | Index sets with index rotation by message count, size or time | Needs rework: index layout and retention must be redesigned, not copied |
| Source and sourcetype routing | Streams and processing pipeline rules | Needs rework: confirm pipeline rule coverage for each sourcetype in your environment |
| Search and SPL | Graylog search query language, which is not SPL | Gap: SPL searches must be rewritten by hand and tested against the same data |
| Dashboards | Graylog dashboards built from widgets and saved searches | Needs rework: panels and drilldowns must be rebuilt and validated |
| Saved searches and scheduled alerts | Event definitions for real-time and historical monitoring | Needs rework: each alert needs its own event definition and notification |
| Correlation searches and risk scoring | Graylog Enterprise correlation engine or Graylog Security risk scoring | Gap in Graylog Open: requires a paid tier, so confirm the licensed scope |
| Splunk apps and add-ons | No direct equivalent; content must be rebuilt or sourced separately | Gap: review each installed app and its dependencies before planning |
| Role-based access | Graylog roles and permissions scoped to streams and dashboards | Needs rework: map Splunk roles and confirm access rules against your policy |
| Retention and archive | Index rotation and retention that deletes the oldest indices | Needs rework: size storage for ingest, retention and headroom before cutover |
Which data and integrations move, and which must be rebuilt
Splunk data does not move into Graylog as a bulk copy. Most teams keep historical events in Splunk for the overlap period, export only what investigations and audits need, and rebuild inputs, collectors, alerts and access controls on the Graylog side. The cards below separate the export paths, the ingestion rebuild and the alert and access work so each can be scoped and checked on its own.
Search result export paths
Splunk documents several ways to take search results out: Splunk Web, the CLI, the REST API, SDKs, the dump search command and data forwarding. Output formats include raw events, CSV, JSON, XML and PDF. Splunk describes the CLI as its most stable retrieval method, so teams with large extracts often script against it. Confirm the export volume and format each investigation or audit team needs before choosing a path, because a browser export is practical only for small result sets.
Historical data stays in Splunk
Re-ingesting years of events into Graylog is rarely worth the effort. A common approach keeps the Splunk indexes queryable through the overlap period, lets analysts search there for older cases, and sends only new events to Graylog. Decide which sources need a historical extract for compliance evidence and which can simply age out. Ask who owns Splunk access and licensing after cutover, since the old environment still has to be paid for and secured until its data expires.
Syslog, GELF and Beats inputs
Graylog Open ingests logs over inputs such as syslog, GELF and Beats. Each Splunk forwarder or source type must map to one of these inputs, with its parsing rebuilt in extractors or processing pipelines. Network devices usually fit syslog, applications that can emit structured output fit GELF, and Beats-compatible agents fit the Beats input. Test each source with sample events, since timestamp handling and field names often differ from the Splunk source type.
Graylog Sidecar for managed collectors
Graylog Sidecar manages log collectors such as Beats and NXLog from the Graylog server, so configuration changes do not require logging into each host. It replaces some of the central management Splunk forwarders get from the deployment server. Plan the host inventory, the collector configurations and who may change them before rollout. Confirm which collector versions your Graylog release supports, since the list changes across versions.
Event definition notifications
Graylog alerts come from event definitions, which can run in real time or over historical data. Notifications are documented for PagerDuty, Slack and email. Splunk alerts that paged an on-call rotation or posted to a channel need equivalent notifications configured and tested, including escalation paths. Check each destination's credentials and routing with a test event before you retire the Splunk alert, because a silent failure looks like no incident.
Users, roles and authentication settings
Splunk users, roles and their capabilities must be recreated as Graylog users and roles, and authentication must be set up for your directory. Review Graylog's user authentication documentation to decide how logins, sessions and any external identity source will work. Map each Splunk role to the least privileged Graylog role that covers the same searches and streams. Keep a written access matrix, because stream permissions in Graylog control what each team can see.
The cutover sequence from Splunk to Graylog
The sequence moves log sources from Splunk to Graylog one at a time, with each source proven in parallel before Splunk stops receiving it. The end state is a documented cutover record and an archived copy of the Splunk history the organization must keep.
Inventory sources, indexes and alert logic
Build a register of every log source, forwarder, index, saved search, dashboard and alert in Splunk, noting owner, daily volume, retention need and the systems that depend on each alert. Platform engineering and the security team usually own this work, with input from the teams that receive alert notifications. The step is complete when each source has a row in the register, each alert is marked as keep, retire or rewrite, and the owners have signed off the list.
Build the Graylog target and pilot one source
Deploy Graylog server nodes with MongoDB and Graylog Data Node or self-managed OpenSearch in the target environment, then create an index set and streams for the pilot source. Route one low-risk source, such as a firewall or Linux authentication log, through a Graylog input, using Graylog Sidecar or a syslog or Beats input depending on what the source supports. The output is a validated pilot: events arrive, parse correctly in the stream, and match a sample of the same events in Splunk field by field.
Run Splunk and Graylog in parallel
Duplicate or split each forwarder so Splunk and Graylog both receive the same events for the agreed period. Compare event counts, timestamps, field extraction and index rotation behavior between the two platforms, and record any gaps. Confirm the retention you plan for Graylog's index sets against the sizing guidance in Graylog's system architecture documentation before adding volume. The output is a parity checklist per source, signed by the operator who owns that source.
Translate alerts into event definitions
Rewrite each retained saved search and alert as a Graylog event definition, choosing real-time or historical scheduling and the notification channel for each one. Replay the same historical events through both platforms and confirm that each alert fires for the same conditions, and document any alert that Graylog Open cannot match. Where a detection depends on correlation or prebuilt threat content, confirm whether it needs Graylog Enterprise or Graylog Security before proceeding. The output is a validation record for each alert, with the alerts that are not yet covered listed as open items.
Cut over source by source
Move each source to Graylog only after its parity checklist and alert validation are complete, and switch the forwarder destination so Splunk stops receiving it. Keep a rollback path for each source until the owner accepts the change. Update runbooks, dashboards and on-call notifications for the source at the same time. The output is a cutover record per source that names the date, the owner, the rollback path and the approver.
Export archive and decommission Splunk
Before turning off Splunk, export the historical data and saved searches your retention policy requires, using the export methods Splunk documents for search results and data retrieval. Store the archive in a location that meets your records and access rules, and test that you can read it. Confirm with your auditors and legal team which records must remain available and for how long. The output is a verified archive, a decommissioning record and a sign-off that Splunk no longer receives production data.
Graylog Open or Enterprise: deciding which tier fits
Before you size a Graylog deployment, decide which tier you are licensing, because the choice shapes both the legal position and the feature set. Graylog Open is licensed under the Server Side Public License version 1 (SSPL-1.0), which Graylog adopted starting with Graylog 4.0 in 2020, replacing GPL v3 for earlier releases. SSPL-1.0 is not approved by the Open Source Initiative, so it should not be described as open source in your policies. For an internal log platform used by your own staff, the license is generally workable, but the SSPL has provisions for offering the software as a service to third parties that you should not interpret alone. Ask counsel to review whether your intended use, including any managed service you plan to offer to subsidiaries, customers or partners, falls within the terms.
Graylog Open is free to self-manage with no ingestion caps and community support, and it includes inputs such as syslog, GELF and Beats, streams, processing pipelines, search, dashboards and event definitions for alerts. Graylog Enterprise adds a data lake with archive restore, data tiering, a correlation engine and 24/7 support. Graylog Security adds SIEM features such as risk scoring, anomaly detection, investigations, compliance packs and prebuilt threat detection content. According to Graylog's published pricing, Enterprise starts at 15,000 US dollars per year and Security at 18,000 US dollars per year, each with a minimum of 10 GB per day or 100 Graylog Compute Units, licensed on processed data with no per-user or per-device fees. Confirm the current figures and the minimum volume basis on the Graylog pricing page before you build a budget.
Map your Splunk usage to tier features before you request a quote. If your Splunk estate relies mainly on search, dashboards and alerting, Graylog Open may cover the requirement, with the cost of your own staff, MongoDB and OpenSearch or Data Node operations. If you use Splunk Enterprise Security correlation, risk-based scoring or prebuilt detections, the correlation engine and SIEM content sit in paid tiers, so price them into the comparison. Ask the vendor for written confirmation of which features each tier includes, support terms, and how the minimum volume is measured against your current daily ingest.
How the migration differs by starting point
A small team running Splunk for application and infrastructure logs on one host usually has a narrow migration. Graylog can run on one server or through Docker Compose, with the Graylog server, MongoDB and a Data Node or self-managed OpenSearch in one place. The main work is replacing forwarders, recreating a few index sets and streams, and moving the handful of saved searches and alerts that people actually use. Because there is little cross-team coupling, cutover can often happen in one change window once logs reach Graylog reliably.
- Installation path: Choose the Debian or RPM package route on a supported Linux distribution, or Docker Compose for a containerized trial. Both are covered in the installation documentation.
- Single node role: There are no follower nodes to configure, so the
is_leadersetting does not apply to a one-server install. - Forwarder replacement: Point existing sources at syslog or Beats inputs, or use Graylog Sidecar where you want centrally managed collectors.
- Alert inventory: Recreate only the saved searches and alerts that are still used, as event definitions, and retire the rest.
- Retention: Size storage from daily ingest, retention days and the 120 percent guidance in the system architecture page, then confirm the Data Node disk layout.
Before cutover, confirm which Splunk alerts have an owner and an active notification path, because a single-node team often discovers those gaps only during the parallel run.
A medium or large deployment is a platform project. The reference layout in Graylog's multi-node guide uses three Graylog and MongoDB nodes, with MongoDB running as a replica set, three Data Nodes on their own cluster, and a load balancer in front of the Graylog servers. Work starts with capacity planning, network design and the failure behavior you need, and only then moves to inputs and content. Expect the migration to include load balancer health checks, certificates, backup of MongoDB and Data Node snapshots, and a tested restore before any production source is moved.
- Leader role: Only one Graylog node should act as the leader, so set
is_leaderto false on each follower in the server configuration. Confirm the setting on every follower after each change. - Separate clusters: Keep the three Data Nodes on their own cluster rather than co-locating them with Graylog servers, so search load and storage I/O do not compete.
- Journal and disk: Give the message journal 3 to 5 times daily ingest on SSDs, as the system architecture page advises.
- Input routing: Use the load balancer address as the syslog and Beats destination so senders do not need to know individual nodes.
- Version pinning: Check the compatibility matrix for the MongoDB and OpenSearch or Data Node versions tied to your target Graylog release.
Before go-live, ask your implementation partner for a written failover test that covers losing one Graylog node, one MongoDB member and one Data Node.
A team that uses Splunk for detection, not just log search, has the largest content task. Graylog Open provides event definitions for real-time and historical monitoring, and notifications to PagerDuty, Slack and email, but the correlation engine and SIEM features such as risk scoring, anomaly detection, investigations and prebuilt threat content sit in Graylog Enterprise and Graylog Security. Plan the migration by reviewing each correlation search for the feature it actually needs, then decide which tier covers it before rewriting anything.
- Feature gap review: List each correlation search and mark whether it needs a basic event definition, a pipeline rule, or a feature only available in a paid tier.
- Tier decision: Confirm with Graylog which features are included in Open, Enterprise and Security, and ask for written pricing against your daily volume, since the published minimums are 10 GB per day or 100 Graylog Compute Units.
- Rule translation: Rebuild SPL logic as stream rules and pipeline rules, then validate each against historical events.
- Parallel run: Keep Splunk alerts live while Graylog event definitions fire on the same data, and compare alert counts before retiring anything.
- Analyst workflow: Confirm that case handling and escalation match how the SOC works today.
Check whether any Splunk content depends on Enterprise Security objects, because those have no direct Graylog equivalent and need a separate design decision.
What drives the cost and duration of the move
This table lists the factors that set the size of a Splunk to Graylog move and the cost components that follow from them. Read each row as a question to answer in your own environment before asking for a written quote. The main takeaway is that source count, rule volume and retention matter more to effort than the license choice alone.
| Driver or cost component | Why it changes cost or effort | What to ask for or confirm |
|---|---|---|
| Number of sources and forwarders | Each universal forwarder replaced by a Graylog Sidecar, syslog or Beats input needs configuration, testing and a cutover window. | Inventory of sources by type, the input method chosen for each, and who owns each host during cutover. |
| Saved searches and alerts | Each Splunk alert must be rebuilt as a Graylog event definition, with notifications and thresholds checked against real data. | A count of alerts by severity, a mapping list to event definitions, and the test method for each one. |
| SPL complexity | Simple field searches translate quickly. Lookups, subsearches, transforming commands and macros need manual rework in Graylog's query language and pipeline rules. | Classification of searches as simple, moderate or complex, and whether the quote includes rewriting of complex ones. |
| Retention and ingest volume | Storage scales with daily ingest, retention days and index overhead. Graylog's system architecture guidance sizes storage as daily ingest times retention days times 120 percent, plus journal space. | Daily ingest per source group, required retention per log type, and the storage and journal sizing used in the proposal. |
| Data tier needs | Keeping older data searchable at lower cost may need data tiering or archive restore, which sit in paid Graylog tiers, not Graylog Open. | Which data must stay searchable, which can be archived, and whether the quote includes Enterprise or Security licensing. |
| Users, roles and authentication | Role design, stream permissions and directory integration take effort that grows with the number of teams and access levels. | Number of user groups, required role model, and the identity source to integrate. |
| Multi-node topology | Medium to large deployments need multiple Graylog and MongoDB nodes, a Data Node cluster and a load balancer, which adds build, hardening and patching work. | Node counts for each tier, high availability design, and the failover test plan. |
| Operations skills in MongoDB and OpenSearch or Data Node | Teams without these skills need training or outside support for backups, upgrades and index management. | Skills gap assessment, training scope, and whether run support is included or priced separately. |
| One-time work: design, pipelines, parallel run and training | Stream and index set design, pipeline rules, event definitions, a parallel run against Splunk and staff training are front-loaded. | Fixed-scope deliverables, acceptance criteria for detection parity, and the length of the parallel run agreed in writing. |
| Recurring work: compute, storage, support and tier licensing | Infrastructure runs every month. Graylog Enterprise or Security licensing is charged per processed data, with a stated minimum, and support tiers differ. | Monthly infrastructure estimate, the licensing basis and minimum, support hours, and the upgrade effort per Graylog release. |
Questions buyers ask before moving from Splunk to Graylog
Is Graylog Open enough to replace Splunk for our log management?
Graylog Open covers core log management: it ingests logs over inputs such as syslog, GELF and Beats, routes them through streams and processing pipelines, and provides search and dashboards. It also handles index rotation and retention. What it does not include is the correlation engine, data lake and archive restore, and the SIEM features such as risk scoring and anomaly detection, which sit in Graylog Enterprise and Graylog Security. Graylog Open is licensed under the Server Side Public License (SSPL-1.0), which is not an OSI-approved open source license, so have your legal team review that license against your use case. List every Splunk app and detection you rely on, then check each one against the tier that covers it.
What does a Graylog migration cost, and what recurs?
Your costs fall into four groups: infrastructure for Graylog server nodes, MongoDB and log storage, staff time to rebuild inputs, streams, pipelines and event definitions, the software license, and any paid support. Graylog Open carries no license fee. Graylog's pricing page lists Graylog Enterprise from 15,000 US dollars per year and Graylog Security from 18,000 US dollars per year, each with a minimum of 10 GB per day or 100 Graylog Compute Units, licensed on processed data. Storage and compute recur every month, while the rebuild work is one-time. Ask any quote to show hardware or cloud sizing, staff effort in days, and what happens when daily ingest grows.
How long does a Splunk to Graylog move usually take?
The duration depends mostly on how many sources, saved searches, alerts and dashboards you have, and on how many of them need rewriting rather than copying. Parallel running is the usual safe pattern: Splunk keeps receiving data while Graylog inputs and event definitions are proven against it. The Graylog multi-node guide recommends three Graylog and MongoDB nodes, three Data Nodes, and a load balancer for medium to large deployments, and that build adds time before any log source is switched. Confirm a timeline in writing against a fixed scope, because DeployOpen engagements are scoped and agreed in writing before work begins.
Can our team run the migration alone, and what skills does it need?
A team with Linux, networking and Splunk administration experience can often handle the basics, but the work has several specialist parts. These include sizing and installing the Graylog server nodes, MongoDB replica set and Data Node or OpenSearch cluster, writing processing pipelines in place of SPL transformations, rebuilding alert logic as event definitions, and planning index retention. Be honest about bench capacity during the parallel run, because your Splunk team must keep operating while the new stack is being proven. If those skills are thin, a fixed-scope engagement can cover the build, the rules and the handover.
What do we need to provide for the project to succeed?
You will need to provide an inventory of log sources, the saved searches, alerts and dashboards in use, the retention periods your policies require, and the daily ingest volume for each source. You also need named owners who can validate that detections still fire, access to Splunk admin exports, and a change window for switching forwarders. Network access to the new hosts, certificates, identity provider details for user authentication, and an agreed rollback plan are also required. Missing inventory is the most common reason estimates grow, so collect it before requesting a quote.
Will our SPL dashboards and saved searches work in Graylog?
Graylog uses its own query language and dashboards, so SPL searches and Splunk dashboards cannot be imported as they are. Each search needs to be rewritten, then checked against the same time range and events in both systems. Simple filters and field searches translate directly, while stats-heavy SPL, lookups and custom commands take more work. Saved searches become Graylog searches and dashboard widgets, and alerts become event definitions. Ask for a sample of your twenty most-used searches to be translated and validated before you commit to a full scope.
How is historical data handled during a Splunk to Graylog move?
Historical data does not move automatically into Graylog. Start by deciding how much history you need for investigations, audits and legal holds, then export that data from Splunk using its supported methods, such as search result export through Splunk Web, the CLI or the REST API. Once you choose the export format, plan how to load it, since Graylog stores data in indices that rotate by message count, size or time. Keep the Splunk archive available for records you do not import, and confirm retention rules with your compliance owner. Export volume and time should be confirmed with your scope and your Splunk environment.
What does Graylog's index model mean for our retention policy?
Graylog organizes stored messages into index sets, and each index set rotates indices by message count, size or time. Retention deletes the oldest indices once the limit you set is reached. You therefore plan retention by index set, not by a single global setting. Graylog's system architecture guidance advises sizing storage as daily ingest times retention days times 120 percent, and giving the message journal 3 to 5 times daily ingest on SSDs. Confirm those figures against your own volume, and check how your retention periods map to the Graylog tiers you choose.
What usually goes wrong and how to prevent it
Most Splunk to Graylog migrations fail quietly rather than loudly: fields disappear, alerts stay silent, or data ages out sooner than planned. The cards below cover the failure points that recur in log management moves, each paired with a check you can run before cutover.
Silent gaps in forwarded fields
Splunk forwarders often sent fields that no one documented, and Graylog inputs parse what they receive differently. A syslog or Beats input may drop, rename or flatten fields that searches and dashboards depend on. Before cutover, sample raw events from both platforms for each source type and compare field names and value formats. Use a field-by-field diff for every source type before retiring the forwarder, and keep Splunk receiving data until the diff is clean.
Event definitions never tested on history
Alerts translated from saved searches and scheduled alerts are often assumed to work because they saved without error. An event definition can run cleanly and still never match real traffic, especially when the search used a Splunk lookup or a field that now has a different name. Replay each rule against a known historical window and confirm it fires on events that should trigger it. Treat an alert that has never fired in testing as unverified, not as working.
Index rotation deleting data early
Graylog retention deletes the oldest indices once rotation limits are reached, so a rotation setting based on message count or size can remove days of data sooner than a time-based policy would. Teams that copy a Splunk retention period without checking the index set settings often find older events gone earlier than their compliance window requires. Confirm the rotation strategy, the retention strategy and the number of indices kept for each index set, and test the result by checking the oldest searchable event.
Under-sized message journal
The message journal buffers incoming messages on disk before they are indexed, so a journal that is too small loses headroom during indexer slowdowns or restarts. Graylog's architecture guidance sizes the journal at a multiple of daily ingest and recommends SSDs. Size it from measured peak ingest rather than average volume, place it on fast storage, and rehearse a node restart under load before production. Confirm the journal size with your Graylog architect before you finalize the server nodes.
Unsupported OpenSearch 1.x backends
Teams reusing an older OpenSearch 1.x cluster to avoid a new storage build can end up on a path Graylog has already marked for removal. Use of OpenSearch 1.x is deprecated since Graylog 7.0 and will be removed in Graylog 8.0. Check the compatibility matrix against your current Graylog and storage versions before you size hardware, and plan for Graylog Data Node or a supported OpenSearch range as the storage target.
SSPL licensing surprises
Graylog Open is licensed under the Server Side Public License, which is not an OSI-approved open source license. Legal and procurement teams that assumed Graylog was open source in the OSI sense can find this out late in a review. Read the license with counsel before offering Graylog as a service to other business units or customers, and record the decision in your architecture approval. Ask counsel whether the SSPL terms fit your intended internal and external use.
SIEM features assumed in Open
Correlation, risk scoring, anomaly detection, investigations and prebuilt threat content are not part of Graylog Open. Teams that replaced Splunk Enterprise Security content with event definitions may find that detections they relied on have no free equivalent. List every Splunk security feature in use, then map each one to Graylog Open, Enterprise or Security, or to a separate tool. Get a written tier comparison from Graylog before you commit the budget or retire the Splunk app.
How DeployOpen scopes and runs a Splunk to Graylog migration
DeployOpen is a Chainscore Labs company that plans, implements, integrates, hardens, backs up, documents and supports self-hosted open-source platforms inside the client's own infrastructure, whether that is a cloud account, a data center or an air-gapped network. For a Splunk to Graylog move, the work usually starts with a written scope that names the sources to be onboarded, the Graylog tier being deployed, the storage backend (Graylog Data Node or self-managed OpenSearch), the stream and index set layout, the event definitions that must match current Splunk alerts, and the retention periods your compliance owners require. The scope also records which Splunk saved searches and alerts are in and which are retired, because that list drives most of the effort. Deliverables and timelines are agreed in writing before any work begins, so the boundaries are visible to your security, compliance and procurement teams from the start.
There is no published DeployOpen price list. A quote follows from the written scope, and the inputs that move it are the number of forwarder replacements and input types, the count of Splunk alerts to translate and validate, the Graylog topology (single node or the multi-node layout described in Graylog's documentation), the Data Node or OpenSearch cluster that must be sized and hardened, the backup and restore design, and the documentation set you need for audit preparation. Ask any provider, including DeployOpen, to separate one-time work (design, migration, parallel running, cutover, initial hardening) from recurring work (upgrades, patching, retention reviews, ongoing testing and support). Ongoing support, upgrades and continuous testing are available as retainers, and a retainer should be scoped against your Graylog version path and your own change calendar. DeployOpen prepares systems, controls and evidence for compliance assessments but does not issue audit reports or certifications; your independent auditor makes that determination, so confirm with them early which evidence they expect.
