Why financial services teams self-host Graylog for log evidence
A bank, insurer or payment firm that must show supervisors and assessors how it collects, retains and reviews logs needs more than a working search box. It needs a platform whose data location, retention settings and access history it can explain on request. Self-hosting Graylog keeps log data inside infrastructure the firm controls, which lets compliance and security teams answer where logs live, who can search them and how long they are kept without relying on a vendor's cloud region. DeployOpen plans, builds and documents that setup, but it prepares evidence only. Audit reports and attestations come from independent assessors such as a Qualified Security Assessor or the firm's external auditor.
Graylog Open gives the core pieces for this work. Inputs such as syslog, GELF and Beats bring events in, streams and processing pipelines route them, and index sets control storage. Retention in Graylog Open works through index rotation and deletion of the oldest indices, so the retention period, rotation thresholds and index set design should be written down before the first production log arrives. Confirm with your compliance team which retention periods your frameworks require, then set them in the index model and record the decision as a configuration baseline. Graylog Open also supports Active Directory, LDAP and trusted header authentication, so the access model can start from directory groups the firm already governs.
The licence and data volume change the plan. Graylog Open is licensed under the Server Side Public License version 1 (SSPL-1.0), which is not an OSI-approved open source license, so legal and procurement teams should review its terms before it becomes a control in a regulated estate. Graylog Enterprise and Graylog Security are licensed on processed data, with a stated minimum of 10 GB per day or 100 Graylog Compute Units, and the pricing page lists starting figures of 15,000 and 18,000 US dollars per year. Ask Graylog for a written quote for your daily volume, and check which features your evidence requirements depend on, such as Okta, SAML or OpenID Connect single sign-on, archive restore and compliance packs, because those need a paid edition.
Which financial services logging requirements shape the Graylog build
This table maps each supplied financial services requirement to what it means for Graylog indexes, access, retention and vendor contracts. Read each row as a design input to settle before the build starts, not as a compliance finding. The main takeaway is that log retention, access separation and data location are usually decided by these requirements rather than by Graylog defaults.
| Requirement | What it asks for | What it means for the Graylog build |
|---|---|---|
| PCI DSS v4.0.1 logging | Applies where cardholder data is stored, processed or transmitted, or where systems could affect that environment. Logs must be collected, protected and reviewed as part of the security program. | Create a dedicated index set for cardholder environment logs, restrict search to named roles, and confirm with your QSA how long logs must be retained online and in archive. |
| DORA Article 28(3) register of information | Requires a register covering all contractual arrangements for ICT services, including those supporting critical or important functions. | Record Graylog, MongoDB, the Data Node or OpenSearch backend, and any hosting or support provider as separate entries, each tied to the function its logs support. |
| DORA Article 28(8) exit strategy | Requires documented, tested exit strategies and transition plans for ICT services supporting critical or important functions. | Plan exports of index data and configuration (streams, pipelines, event definitions) in an open format so logs remain readable if you change platform or provider. |
| DORA Article 30(2) contract terms | Requires every ICT services contract to state where services are provided and data processed, with advance notice of changes, and to cover data return on termination. | Ask any Graylog support or hosting provider to name the locations where log data is stored and processed, and to commit to notice of changes and data return. Self-hosting in your own regions keeps this question simpler. |
| Swift Customer Security Controls Framework v2026 | Swift users have the controls independently assessed and attest compliance annually in the KYC-SA application. The framework has 32 controls, 26 mandatory and 6 advisory. | Confirm with your Swift assessor which logs they expect for the Swift environment, such as operator and administrator activity, and route those sources to a separate stream with alerting that matches your review duties. |
| SEC Release 33-8810 IT general controls | Names program development, program changes, computer operations and access to programs and data as example IT general control areas for SOX Section 404 assessments. | Capture change and administrative events from the systems in scope, keep Graylog configuration changes auditable, and tag evidence by control area so auditors can trace each one. |
| FTC Safeguards Rule, 16 CFR 314.4(c)(5) | Requires multi-factor authentication for any individual accessing any information system, unless the Qualified Individual approves an equivalent control in writing. | Enforce MFA on Graylog access through your identity provider. Graylog Open supports Active Directory, LDAP and trusted header authentication, while Okta, OpenID Connect and SAML single sign-on need Graylog Enterprise. Confirm the approach before you build. |
| Retention and review duties | Requirements such as the PCI DSS logging controls and SOX evidence expectations require logs to be kept and reviewed over set periods. The periods come from your assessors and regulators. | Size indexes as daily ingest times retention days times 120 percent per Graylog guidance, and decide online versus archived periods with your compliance team before creating index rotation rules. |
Which Graylog edition covers the controls you need
Start with the license, because it shapes every other decision. Graylog Open has been licensed under the Server Side Public License version 1 (SSPL-1.0) since Graylog 4.0, and that license is not approved by the Open Source Initiative. Graylog Open is free with no volume limits and community support, which is enough to centralize logs and build searches, dashboards and event definitions. For a bank or payment firm, though, the question is whether the controls your assessors expect are available in the edition you run. Graylog Open supports Active Directory and LDAP sign-in and trusted header authentication. Okta, generic OpenID Connect and SAML single sign-on are Enterprise features, so an organization that must federate workforce identity through SAML will need that license. Confirm the license terms with Graylog and with your legal team before you design around them.
The Enterprise edition adds the capabilities that usually matter most in a financial services review. Its data lake supports archive restore, which is central to long retention, and data tiering lets you place older logs on cheaper storage. The correlation engine supports multi-step detection rules, and 24/7 support is included. The Security edition builds on this with SIEM features: investigations that give analysts a managed workflow for case handling, compliance packs, and prebuilt threat detection content. Risk scoring and anomaly detection are also Security features. Map each control you must evidence, such as access review, incident investigation or retention of payment-related logs, to a specific edition and feature before you buy.
Pricing is published on Graylog's pricing page. Graylog Enterprise starts at 15,000 US dollars per year and Graylog Security starts at 18,000 US dollars per year, each with a minimum of 10 GB per day or 100 Graylog Compute Units. Licensing is based on processed data, with no per-user or per-device fees. Ask Graylog to confirm how the minimum applies to your daily volume, whether a Compute Unit commitment changes the calculation, and what happens if your ingest grows during the term. Also ask whether the security features you need are included at the tier you are quoting. Treat published figures as a starting point, because the current terms and any negotiated scope are set by Graylog at the time of purchase.
Graylog modules and settings that matter for banks, insurers and payment firms
Payment, core banking and identity systems rarely emit logs in one format, so the input choice is the first design decision. Syslog suits network devices, firewalls and many Linux services. GELF suits applications that can send structured messages directly. Beats-based collectors suit Windows and file-based sources. Map every source in the register of logging coverage before any input is created, because a missing source is harder to explain to an assessor than a slow one. Some inputs depend on an Enterprise license, so confirm edition needs for each source with the Graylog pricing and product pages.
- Source inventory: List each core banking, payment switch, identity provider and card gateway, with its owner and the log types it produces.
- Transport choice: Decide between UDP and TCP or TLS syslog for each source, since lossy transport can drop authentication events.
- Parsing ownership: Assign who maintains extractors or pipeline rules when a vendor changes its log format.
- Time synchronization: Confirm all sources use a common time source, so events from different systems line up during investigations.
- Edition check: Mark which inputs or sources need Graylog Enterprise or Graylog Security before purchase.
Before go-live, send a known test event from every source and confirm it appears with the expected fields in the correct index set.
Streams and processing pipelines decide which messages land where and who can see them. For payment firms, the key requirement is to keep logs from the cardholder data environment separate from general infrastructure logs, so that scope decisions and access rules are enforceable rather than documented only in policy. Routing rules should be written against source identifiers or network segments, then tested with sample messages. Pipelines can also remove or mask fields such as account numbers before messages are stored, but masking must be validated against real samples because a missed field is a data exposure.
- Scope streams: Create a dedicated stream for in-scope sources, with rules that match on a known source or segment rather than message text alone.
- Field masking: Use pipeline rules to redact primary account numbers and other sensitive values before storage, and test them against sample data.
- Stream ownership: Record who can edit each stream and pipeline, and keep those changes under change control.
- Routing tests: Keep a set of test messages for each stream so that rule changes can be regression-tested.
- Sensitive data review: Check whether application logs contain session tokens or personal data before routing them to shared streams.
Review stream and pipeline configuration against the scope definition for the payment environment at least once a year, and after any change to network segmentation.
Index sets control how long data is searchable and when it rotates out. Graylog Open rotates indices by message count, size or time and deletes the oldest indices under its retention setting, so each data class needs its own index set with a retention period chosen by the compliance owner. Storage sizing follows the documented formula of daily ingest multiplied by retention days and by 120 percent, and the message journal should be sized at 3 to 5 times daily ingest on SSDs. Long retention for regulated logs usually requires archiving or Enterprise data tiering, so decide early which records must remain searchable and which only need to be retrievable.
- Data classes: Separate payment, authentication, core banking and general infrastructure logs into distinct index sets.
- Rotation settings: Choose time-based or size-based rotation per index set, based on expected daily volume.
- Retention periods: Obtain each period in writing from the compliance and legal owners, rather than copying a default.
- Sizing: Apply the documented storage and journal formulas to projected ingest, and add headroom for growth.
- Archive path: Decide whether records past the searchable window go to an archive, and who can restore them.
Test retention by checking that old indices are removed or archived on schedule, and that an archived record can be restored within the time your audit or incident process requires.
Event definitions turn searches into alerts, either on live data or across historical data. For financial services, typical candidates include repeated failed logins to payment or core banking systems, administrative changes on card gateways, and unexpected traffic from cardholder segments. Graylog Open documents notifications to PagerDuty, Slack and email. Each alert should name an owner, a severity and an expected response, because an alert without a response path becomes noise. Alert thresholds need tuning on real traffic, and the tuning record itself is useful evidence of how monitoring was designed.
- Use-case list: Write down the events that matter for fraud, access and availability, with the source and condition for each.
- Thresholds: Set aggregation conditions from observed baselines, and record why each threshold was chosen.
- Notification routing: Send high-severity events to an on-call channel such as PagerDuty, and lower-severity events to Slack or email.
- Test alerts: Trigger each definition deliberately in a test environment and confirm that the right person receives it.
- Response records: Link each alert type to a runbook and to the ticket or case system used for review.
Confirm which alerting and correlation features your edition includes before designing around them, since advanced detection content depends on the Enterprise or Security license.
Access to logs is itself sensitive, because search results can reveal account activity, customer identifiers and internal network layout. 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. Roles should follow least privilege, with separate groups for security analysts, platform operators and auditors. Where the FTC Safeguards Rule applies, multi-factor authentication is required for any individual accessing an information system unless the Qualified Individual approves an equivalent control in writing, so confirm how MFA is enforced for Graylog logins through your identity provider.
- Identity source: Choose Active Directory, LDAP or an Enterprise SSO option based on the identity system the firm already runs.
- Role design: Define roles for read access to in-scope streams, administrative access and audit review, and grant them to groups rather than individuals.
- Stream permissions: Restrict payment and authentication streams to named roles, so general staff cannot search them.
- MFA enforcement: Confirm where multi-factor authentication is enforced, and document any written exception.
- Admin separation: Keep configuration administrators distinct from those who search logs, and review their activity regularly.
Review group membership and stream access on a fixed schedule, and check that administrative changes to roles appear in the audit trail.
How storage sizing and the message journal drive cost
Graylog storage cost follows from how much data you ingest and how long you keep it, plus the overhead that the search backend and the message journal add. Each card below is one input to that model, and each is something a partner should be asked to work through with your actual figures before a quote is written.
The published storage sizing rule
Graylog's architecture guidance advises sizing log storage as daily ingest multiplied by retention days, then multiplied by 120 percent. For a financial services firm, the retention input is usually set by the policy that covers transaction and access logs rather than by engineering preference, so the rule turns a retention decision directly into disk. Ask the partner to show the calculation with your real daily ingest and your confirmed retention period, not a rounded estimate.
Message journal sizing on SSDs
The message journal is the on-disk buffer between ingest and indexing, and Graylog's guidance places it at 3 to 5 times daily ingest on SSDs. A journal that is too small fills during a search backend slowdown or a node restart, which can stall ingestion of security-relevant events. Confirm the journal volume is separate from index storage and that the partner tests recovery under backpressure.
Retention length as the main driver
Retention is usually the largest multiplier in the storage model, so each extra month of online retention adds disk on every Graylog Data Node. Separate the periods your compliance owners require for online search from those that can be met with archives. Ask the partner to produce a table showing storage at each retention option so the retention decision is visible to risk and legal teams.
Ingest volume and source filtering
Daily ingest is the other multiplier, and it grows with the number of firewalls, payment gateways, identity systems and database audit feeds you connect. Filtering low-value events at the source or in processing pipelines can reduce what is stored, but dropping events that a control depends on creates a gap an auditor will find. Ask for a source-by-source volume inventory before sizing begins.
Replicas, nodes and search backend overhead
Storage that holds indexed data is not the only disk in use. The search backend's replica settings, the node count recommended for medium to large deployments, and the MongoDB footprint all add capacity that the sizing rule does not capture on its own. Confirm with the partner how replicas are set and what headroom is kept for merges, snapshots and rebuilds.
Archive and warm tier costs
Archives and warm tier snapshots move older data to cheaper storage, but they add their own cost in storage, restore time and operational steps. Restore time matters when an investigation or regulator request needs records from years back. Ask the partner to model archive capacity, restore procedure and who pays for the recurring storage, and whether Enterprise licensing is required for the features used.
What financial firms ask before hiring a Graylog partner
What drives the cost of a Graylog implementation for a bank or payment firm?
The main drivers are the written scope, the number and type of log sources, the daily data volume, and the edition you license. DeployOpen works on fixed scope agreed in writing before work starts, so the quote follows from the list of sources, parsing and dashboards, retention design, and the systems to harden and back up. Graylog licensing is a separate cost paid to Graylog. Graylog Open is free with no volume limits, while Graylog Enterprise starts at 15,000 US dollars per year and Graylog Security at 18,000 US dollars per year according to the Graylog pricing page, each with a minimum of 10 GB per day or 100 Graylog Compute Units. Ask the partner to separate one-time build work from recurring licence, infrastructure and support costs.
Does Graylog Open meet a financial firm's needs without a paid licence?
Graylog Open covers ingestion, streams, processing pipelines, search, dashboards, index rotation and retention, and event-based alerts with notifications to tools such as Slack, PagerDuty and email. Some capabilities that financial firms often ask about sit in the Enterprise or Security editions, including data lake archive restore, data tiering, the correlation engine, SAML and OpenID Connect single sign-on, and SIEM features such as investigations and compliance packs. Graylog Open is licensed under SSPL-1.0, which is not an OSI-approved open source license, so have legal and procurement review that license before adoption. Confirm each required feature against the current edition tables with the vendor.
How long does a Graylog project take for a regulated financial firm?
Duration depends on the number of log sources, how many need custom parsing, the retention and archiving design, the identity integration, and how quickly your change approval and security review process runs. Network access, firewall rules and access to the hosts that forward logs often take longer than the Graylog build itself. The sizing guidance in Graylog's architecture documentation also affects the plan, because storage needs daily ingest multiplied by retention days and 120 percent, and the message journal needs 3 to 5 times daily ingest on SSDs. Ask the partner for a timeline tied to the written scope and to a named list of sources.
What must our team provide before a Graylog partner starts work?
Expect to provide a list of log sources with owners, the retention rules that apply to each log type, network paths from the sources to the Graylog nodes, and access to your identity provider for Active Directory, LDAP or SSO setup. You also need a change approval route for production hosts, a named contact for security sign-off, and the target infrastructure, whether cloud accounts, data centers or an air-gapped network. Where data must stay in region, confirm the hosting location in writing before design begins. Missing inputs are the most common reason fixed-scope timelines slip.
Can our in-house team run Graylog after the partner leaves?
Yes, if your team has Linux, MongoDB, OpenSearch or Graylog Data Node, and load balancer skills, and can cover the operational duties. A production multi-node design uses three Graylog and MongoDB nodes with MongoDB as a replica set, three Data Nodes on their own cluster, and a load balancer, so someone must own patching, backups, capacity checks and upgrades. Graylog 7.0 to 7.2 have specific MongoDB and OpenSearch compatibility ranges, and OpenSearch 1.x use is deprecated since Graylog 7.0 and will be removed in Graylog 8.0. Ask the partner for a handover that includes runbooks and tested recovery steps.
What DORA contract and exit questions should we ask a Graylog partner?
Under DORA, a financial entity must keep a register of information on all ICT contractual arrangements (Article 28(3)), and each ICT services contract must state where services are provided and data processed, with advance notice of changes and data return on termination or insolvency (Article 30(2)). For services supporting critical or important functions, Article 28(8) expects documented, tested exit strategies and transition plans. Ask the partner to state its service locations, subcontractors, data return format, notice of changes and how your Graylog configuration and archives can be exported. DORA sets no certification scheme, so do not accept a certificate as proof of compliance.
What does a Graylog retainer cover after go-live?
A retainer covers ongoing support, upgrades and continuous testing, as agreed in writing. In practice, that can include monitoring the cluster, responding to journal and buffer problems, applying Graylog and backend upgrades with their documented breaking changes, reviewing retention and index set settings, and producing support bundles when incidents occur. Confirm in the written agreement which tasks are included, response expectations, which Graylog editions and licences are excluded, and how changes to log sources are scoped and billed. Compliance readiness work, such as evidence packs for an assessor, is separate from running the platform, and DeployOpen does not issue audit reports or attestations.
How a financial services Graylog rollout runs in phases
The sequence moves from defining which systems and retention rules apply to a handover that lets your own team run, test and upgrade the platform. Each phase closes with a written output that the next phase depends on.
Scope in-scope systems and retention rules
DeployOpen works with your compliance, security and application owners to list the systems whose logs fall under PCI DSS, DORA, Swift CSP or other obligations you carry, such as payment switches, core banking, identity providers and Swift connectivity hosts. For each source, the team records the log types, the retention period your rules require, who may search them and who reviews them. The step closes with a signed scope register that names every source, its owner and its retention basis.
Decide architecture and region placement
Architecture is set here: how many Graylog server nodes, MongoDB replica members and Data Node or OpenSearch nodes are needed, where they run, and how a load balancer fronts the servers. Data residency decisions, including which jurisdiction holds the log data and which administrators can reach it, are recorded alongside the sizing inputs. Storage sizing uses your daily ingest and retention figures against the sizing guidance in Graylog's architecture documentation. The output is an approved architecture diagram, a sizing worksheet and a residency statement your legal team has reviewed.
Install on the planned Graylog version
The installation uses the Graylog version chosen in the architecture phase, confirmed against the compatibility matrix for the MongoDB and search backend versions in use. Data Node is the recommended search backend, and OpenSearch 1.x is not a valid choice for new builds. Installation covers packages or Docker Compose on your hosts, follower nodes configured with is_leader set to false, and the load balancer in place. Completion is a cluster where every node reports healthy, the journal is sized for your ingest, and the install record names exact versions for later upgrade planning.
Onboard sources and build pipelines
Each in-scope source is connected through the inputs Graylog supports for it, such as syslog, GELF or Beats, and routed to the right streams. Processing pipelines normalize fields, drop noise that your retention rules do not require, and tag payment, Swift and identity events so they can be found quickly. Some inputs and features need an Enterprise or Security license, so that is confirmed per source before build. The step closes when every source in the scope register shows arriving messages, parsing tests pass on sample events and index sets match the retention plan.
Configure detection and alerting
Searches that matter to your obligations become event definitions, covering both real-time and historical conditions, with notifications sent to the on-call channel and ticketing path your security team uses. Examples include repeated failed logins to payment administration, changes to Swift environment hosts and privileged access outside change windows, labeled as illustrative. Each definition records its owner, priority and the response expected. The output is a tested rule set where each alert has been triggered on purpose and its notification confirmed.
Test access controls and evidence
Access is tested against the roles defined in scope: who can search which streams, who can change pipelines, and whether single sign-on or multi-factor requirements apply to every administrative login. The team then produces the evidence an assessor or internal auditor will ask for, such as retention settings, input configuration exports, alert test records and access reviews. Edition-specific authentication options, such as which single sign-on methods your license includes, are confirmed before testing. The step closes with a test log and an evidence index mapped to each in-scope requirement, which your assessor reviews. DeployOpen prepares this evidence but does not issue audit reports or attestations.
Hand over runbooks and an upgrade plan
Your operations team receives runbooks for daily checks, journal and buffer problems, backups, support bundles and capacity reviews, along with the access model and change procedure. An upgrade plan lists the target Graylog version, documented breaking changes, the MongoDB and search backend prerequisites and the test environment used to rehearse each change. Ownership of alerts, retention settings and evidence collection is assigned by name. The phase ends with a walkthrough where your team restores a backup and runs one scripted alert test without DeployOpen, and the handover is signed off.
What to ask a Graylog partner before signing
Put these questions in the written scope before any work starts. Start with the regulated sources: list every system that feeds the PCI DSS cardholder data environment, the Swift connector and payment gateway hosts, core banking and identity logs, and the cloud accounts that hold ICT services. Ask the partner to name the Graylog input type for each source (for example, syslog, GELF or Beats) and to state which ones need a Graylog Enterprise or Security license. Ask how each source's timestamps, parsing and stream routing will be tested before it counts as covered. Ask whether the scope includes the Swift Customer Security Controls Framework monitoring or only the log plumbing beneath it, because those are different deliverables.
Ask how log data stays in region. The contract should name the data center or cloud region for the Graylog server nodes, the MongoDB replica set, the Data Node or OpenSearch cluster, snapshot repositories and archives, and any backup copies. Under DORA Article 30(2), your ICT services contract must state where services are provided and data processed, so ask the partner to write those locations into the scope and to commit to advance notice before any change. Ask how the partner handles data return and exit: which export formats, how archived indices are restored, who holds the keys, and how long the partner keeps copies after termination. Ask for a documented exit plan, since DORA Article 28(8) expects tested exit strategies for ICT services that support critical or important functions.
Ask how upgrades to Graylog 7.x will be tested, and which versions are in scope. Confirm supported combinations of Graylog, MongoDB and Data Node or OpenSearch with the vendor, using the compatibility matrix as the starting point, because support for the backends changes between releases. Ask who runs the upgrade test in a non-production copy, who signs off on parsing and dashboard changes, and how rollback works. Finally, settle who owns the evidence packs for PCI DSS and DORA reviews, who keeps the control-to-evidence map current, and what is excluded, such as assessor fees, Qualified Security Assessor work, Attestation of Compliance preparation, Enterprise license fees and ongoing monitoring. Written exclusions prevent disputes at the first audit.
How DeployOpen scopes and delivers Graylog for regulated finance
DeployOpen plans, implements, hardens, documents and supports self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks, so log data stays where your residency rules require. For Graylog in financial services, the work is agreed in writing before it starts, and the deliverables are the evidence your auditors and supervisors will ask to see.
How we scope
- Map which in-scope systems, such as cardholder data environment hosts and identity platforms, send logs to Graylog and which retention periods apply to each.
- Record the sizing basis, including daily ingest, retention days and message journal capacity, so the written scope shows how storage was estimated.
- Agree in writing which compliance evidence, such as log review records and retention settings, DeployOpen will prepare and which the assessor must validate.
How we build
- Deploy Graylog server nodes, MongoDB as a replica set and Data Node or self-managed OpenSearch in your infrastructure, following the documented multi-node layout.
- Configure inputs, streams, processing pipelines, index sets and event definitions for the sources and alert paths agreed in the scope.
- Test log ingestion, search access, alert delivery and retention deletion against the acceptance criteria written into the scope before handover.
How we hand over
- Deliver runbooks for the build, access model, retention settings, backup and restore steps, and the procedure for changing log sources.
- Document the configuration as code or exported settings so your team can review changes and show how the logging controls were set up.
- Walk your security, operations and compliance staff through the evidence pack and confirm who owns each recurring review task after handover.
How we support
- Offer ongoing support, upgrades and monitoring as a retainer, covering Graylog version changes and the documented breaking changes that need planning.
- Plan periodic reviews of retention, access and alert content, with changes recorded so your assessor can trace each one.
- Support your own assessments by preparing evidence and answering technical questions, while the assessor, QSA or auditor issues any report or attestation.
