Graylog for SaaS and technology companies

Customers usually expect authentication events, administrative actions, access to customer data and changes to security settings to be logged, with enough context to show who did what and when. Graylog ingests these over inputs such as syslog, GELF and Beats, and routes them through streams and processing pipelines so that each source lands in a defined place. Your answer should list the log sources you actually collect from your application, cloud accounts and infrastructure, not a generic claim. Confirm with your engineering team which fields are captured and whether any personal data appears in messages before you describe the scope.

Your answer should name the infrastructure where Graylog runs and where its log storage sits. In a self-hosted deployment, Graylog server nodes keep configuration and metadata in MongoDB, while log data sits in Graylog Data Node or self-managed OpenSearch. Describe the region, the cloud account or data center, and who operates it. If customers have residency requirements, a self-hosted setup lets you keep log data where you specify, but you must confirm the backup and archive locations too, since those copies also count as stored data.

Access to log search should be limited by role, and the answer should describe those roles in your own terms. Graylog Open supports Active Directory and LDAP authentication and trusted header authentication, while Graylog Enterprise adds Okta, generic OpenID Connect and SAML single sign-on. Describe how staff sign in, which roles can view which index sets or streams, and whether access to sensitive logs is reviewed. Confirm your authentication edition before you claim SSO, because the features available depend on the license you run.

State the retention period for each log category, since customers often ask for different periods for audit and security data. In Graylog, retention is set per index set through rotation and retention settings, and the index model sets how indices are rotated by message count, size or time. Your answer should give your committed periods and point to the policy that governs them. Do not promise a period that your index set settings do not enforce. If you archive older data elsewhere, explain where that archive lives and how long it persists.

Retention in Graylog deletes the oldest indices once the configured limit is reached, so deletion happens in whole index units rather than per record. Explain this clearly, because a customer may ask whether a single event can be removed on request. Describe your process for deletion on customer request, backup expiry and decommissioning, and confirm which copies, including snapshots and archives, follow the same schedule. Have engineering verify that deletion has actually run on a test index set before you describe it as operating.

A SOC 2 report is generally restricted in use, so most providers share it only under a non-disclosure agreement and only with parties who have a legitimate need. A SOC 3 report covers the same Trust Services Criteria categories in less detail and is a general use report that can be freely distributed. Offer the SOC 3 for broad public distribution and share the SOC 2 under controlled terms. Note that SOC 2 examinations are performed by an independent CPA firm, and DeployOpen prepares systems and evidence but does not issue audit reports.

Auditors look for evidence that logging is configured, monitored and reviewed over the audit period, not only that a tool exists. Useful evidence includes stream and input configurations, retention settings, role and access lists, alert definitions and records of review. For a Type 2 report, the examination covers operating effectiveness over a period, so you need consistent records across that time. The AICPA's 2017 Trust Services Criteria define the control categories to map against, and the common criteria CC6 to CC9 cover access, system operations and change management. DeployOpen can prepare these systems, controls and evidence, but the independent auditor decides what they conclude.

The answer depends on your volume, staffing and required features, so compare total cost rather than license fees alone. Graylog Open is free with no volume limits and community support, while 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, according to the Graylog pricing page. Add infrastructure, storage sized from daily ingest times retention, and the staff time to run upgrades and backups. Ask any cloud SIEM vendor for a quote built on the same ingest and retention numbers, and confirm what each price includes.

It depends on your ingest volume, retention period and staff time, so no general answer is safe. Graylog Open has no license fee and no volume limit, but you pay for the infrastructure that runs it: server nodes, MongoDB, and Data Node or self-managed OpenSearch for storage. Paid editions are licensed on processed data, with Graylog Enterprise starting 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, according to the Graylog pricing page. Compare the full annual cost of your own cluster, including engineering time, against the cloud SIEM's quote at your actual daily volume and retention, and ask both vendors to price the same data.

Four factors move the cost most: daily ingest, retention days, the edition you need, and the people who run the platform. The Graylog architecture guidance sizes log storage as daily ingest times retention days times 120 percent, so doubling retention roughly doubles storage. The message journal needs 3 to 5 times daily ingest on SSDs, which adds fast disk. Editions matter because features such as data tiering, the correlation engine, SAML single sign-on and investigations sit in Enterprise or Security licenses. Ask any partner for a quote that lists each of these inputs as a separate line, with a clear split between one-time build work and recurring operations.

The duration depends on scope, not on a fixed number of days, and no supplied figure sets it. The work includes choosing the backend, building a multi-node layout, wiring inputs for your hosts and cloud services, setting index retention, and integrating identity. Graylog's multi-node guidance for medium to large deployments describes three Graylog and MongoDB nodes with MongoDB as a replica set, three Data Nodes on their own cluster, and a load balancer. Your timeline grows with the number of log sources, the number of customer-facing audit requirements to map, and the number of approvals needed. Request a written schedule tied to a fixed scope before work starts.

The build needs cloud account access, named log owners and a sign-off process. Cloud access covers a network path to the Graylog nodes, service accounts for log export, and permission to create the required infrastructure in your accounts. Log owners are the engineers who know which applications, cloud audit trails and identity systems produce events, and which fields hold sensitive data. Sign-off is needed for retention periods, role design for who can search sensitive logs, and alert destinations such as PagerDuty, Slack or email. Agree these inputs in the written scope so that delays are not billed as new work.

Yes, many teams can, provided they have the skills to run MongoDB, a search backend and Linux or container platforms, and someone owns the work after launch. The main risks are backend sizing, journal problems under load, and upgrades that change runtime or database prerequisites. Graylog supports installation from packages on Ubuntu, Red Hat, SUSE and Debian, or with Docker Compose, and recommends Data Node as the search backend. Assess your team against that list honestly, and consider whether a partner should build the cluster while your staff take over operations through a documented handover.

Upgrades, capacity checks, backups and index maintenance recur for as long as you run the platform. Compatibility is the first constraint: the Graylog compatibility matrix ties each Graylog release to supported MongoDB and OpenSearch versions, and Graylog 7.0 to 7.2 support MongoDB 7.x up to 8.2.x. Use of OpenSearch 1.x has been deprecated since Graylog 7.0 and will be removed in Graylog 8.0, so a backend migration may fall due during your operating life. Budget for a recurring review of these matrices, a test environment for each upgrade, and monitoring of the journal and cluster health.

Confirm this with your legal team before you build on Graylog Open, because it is not a standard open source license. Starting with Graylog 4.0, Graylog Open is licensed under the Server Side Public License version 1 (SSPL-1.0), which is not an OSI-approved open source license, replacing GPL v3 for earlier releases. The SSPL terms affect how you may offer Graylog as a service to others, which matters if your product exposes log tooling to customers. Ask counsel to review the license text in the Graylog repository and to confirm how it applies to your product and internal use.

Start with the sources that support access control and incident investigation, then add application logs as your monitoring matures. Priority sources usually include cloud control plane audit trails, identity provider sign-in events, administrative actions in production, and authentication events from your own application. Graylog ingests these through inputs such as syslog, GELF and Beats, and routes them through streams and processing pipelines. Agree the list with your security lead and the people who will review SOC 2 monitoring evidence, because each source adds parsing, retention and access decisions.