Graylog for PCI DSS requirement 10 log management

Meeting PCI DSS requirement 10 with Graylog: what the platform covers

Yes, a self-hosted Graylog deployment can carry the logging, retention, access restriction, daily review and time synchronization parts of PCI DSS requirement 10, but it does not do all of that work by default. Graylog provides the collection layer (inputs such as syslog, GELF and Beats), stream routing, processing pipelines, search, dashboards, index retention and event definitions for review. The parts that depend on your design are the ones auditors will test: which systems in the cardholder data environment actually send logs, whether the index sets keep at least 12 months with the most recent three months searchable, who holds read access to the logs, and whether the review workflow is automated rather than a person scrolling through dashboards. Those decisions belong in the design before the build starts, not after the first assessment.

DeployOpen plans, builds and documents this setup in infrastructure you control, and prepares the systems, configuration records and evidence that an assessment will look at. DeployOpen does not issue reports, attestations or certifications. Compliance is decided by your assessor, either a Qualified Security Assessor completing a Report on Compliance or your organization completing the applicable Self-Assessment Questionnaire with its Attestation of Compliance. The PCI Security Standards Council does not enforce PCI DSS itself. The individual payment brands decide which entities must validate and run any enforcement, so confirm with your acquirer or the relevant brand which validation route applies to your environment.

Before scoping the build, confirm three things with your assessor: which PCI DSS v4.0.1 requirements your environment must meet under the defined approach, whether any part will use the customized approach, and how your assessor wants retention and access evidence presented. Also confirm which Graylog edition you need. Several review and detection features sit on Graylog Enterprise or Graylog Security, so the license choice affects what the review workflow can automate. The sections on retention, alerting and access control in this guide show how each part is configured.

Mapping requirement 10 sub-requirements to Graylog capabilities and configuration

This table maps each PCI DSS requirement 10 sub-requirement in scope for this page to the Graylog capability that supports it, the settings to configure, and the controls that stay outside Graylog. Read each row as a design checklist, then confirm the scope and evidence expectations with your Qualified Security Assessor. Graylog supports these controls, but it cannot close logging gaps on endpoints or in applications that never send their events to it.

Requirement	Graylog capability	Configuration to set	Remains outside Graylog
10.2.1: audit logs enabled for system components and cardholder data	Inputs (syslog, GELF, Beats) receive events; streams route cardholder data environment sources to dedicated index sets	Enable audit logging on each source, point it at Graylog inputs, and create streams for CDE hosts, administrator activity and authentication events	Enabling audit policy on endpoints, databases and applications, and confirming which event types each source emits
10.3: read access limited, logs protected and backed up	Graylog roles and permissions restrict who can search or view streams; MongoDB and Data Node hold stored data	Grant search access by job need only, avoid shared admin accounts, restrict stream and index set permissions, and separate backups to a secure central location	File integrity monitoring or change detection on log files, backup media controls, and the access review process
10.4.1 and 10.4.1.1: daily review, automated mechanisms	Event definitions run real-time and historical checks; notifications route to email, Slack or PagerDuty in Graylog Open	Define event definitions for CDE log sources and critical security events, set notification targets, and keep a documented daily review dashboard	Assigning reviewers, recording review sign-off, and triaging alerts through your incident process
10.5.1: 12 months retention, last 3 months searchable	Index sets rotate by message count, size or time, and retention deletes the oldest indices	Size index sets so roughly three months stay searchable, and plan archived or snapshot storage for the remaining months of retention	Long-term archive media, restore testing and the storage budget for months four to twelve
10.6: time synchronization	Graylog timestamps depend on source clocks and the server host clock, so Graylog itself cannot correct drift	Point all CDE systems, Graylog nodes and MongoDB hosts at designated time servers, and monitor synchronization status	Configuring NTP or the time service on each host and proving synchronization in evidence
Platform availability for the log store	Graylog server nodes, MongoDB replica set and three Data Nodes form the cluster that stores the logs	Follow the multi-node layout: a load balancer, MongoDB as a replica set, and is_leader set to false on follower Graylog nodes	Infrastructure redundancy, power and network design, and capacity planning for your ingest volume

How Graylog collects the events 10.2.1 requires and keeps 12 months

Start by listing every component that stores, processes or transmits cardholder data, every critical system component and every component that performs a security function. Requirement 10.2.1 expects audit logs to be enabled across these components, so each one needs a documented path into Graylog. Hosts and servers usually send through agents or syslog, network devices send syslog, and applications may send GELF or write files that a Beats shipper forwards. Cloud services often export logs through their own APIs or forwarding services, which you should confirm before design.

Hosts and servers: Use syslog or Beats inputs, and confirm the agent captures administrator actions and log start and stop events.
Network devices: Configure syslog forwarding on firewalls, switches and load balancers that sit in or connect to the cardholder data environment.
Applications: Use GELF where the application can emit it, and record which application events map to individual access to cardholder data.
Cloud services: Confirm with each provider which audit streams can be exported and at what latency.
Inputs by edition: Confirm which inputs your Graylog edition supports, because some inputs need an Enterprise license.

Keep a source register that maps each component to its input, stream and owner, and check it against your in-scope system inventory.

Restricting log access and protecting audit logs under 10.3

Requirement 10.3 is less about collecting logs than about keeping them trustworthy and limited to the people who need them. The cards below cover the Graylog controls that restrict who can read audit data, how the storage backends are protected, how logs are backed up, and the integrity monitoring that Graylog does not supply on its own.

Role-based access to audit streams

Requirement 10.3 limits read access to audit logs to people with a job-related need. In Graylog, this means placing cardholder data environment logs in dedicated streams and index sets, then granting roles only to the search and dashboard permissions those staff need. Review every role on a fixed schedule, and confirm that administrators who can change stream routing or index settings are not the same people who review the logs. Test the restriction by logging in as a standard analyst and attempting to open another team's streams.

Graylog Open authentication options

Graylog Open supports Active Directory and LDAP authentication and trusted header authentication. Directory-backed sign-in lets your identity team disable access in one place when someone changes roles or leaves, which supports the removal of access that is no longer needed. Confirm that group membership maps to Graylog roles correctly, and that local administrator accounts are limited, documented and protected. Trusted header authentication depends on a reverse proxy that must strip client-supplied headers, so verify that configuration before relying on it.

Enterprise single sign-on options

Graylog Enterprise adds Okta, generic OpenID Connect and SAML single sign-on. These options let the organization's central identity provider enforce its own multi-factor policy and session lifetimes for everyone who reads cardholder data environment logs. Check whether your identity provider can deliver group claims that Graylog maps to roles, and decide how emergency access will work if the provider is unavailable. Enterprise licensing is a cost to include in the quote, since this option is not available in Graylog Open.

Protecting MongoDB and Data Node backends

Graylog keeps configuration and metadata in MongoDB and log data in Graylog Data Node or self-managed OpenSearch. Anyone with direct access to these backends can alter or delete events without leaving a Graylog audit trail, so network access should be limited to Graylog server nodes and administrators through segmented networks and firewall rules. Enable authentication and transport encryption on both backends, restrict file system permissions on data directories, and document who can reach them. Treat these hosts as part of the cardholder data environment where they hold its logs.

Prompt backup to central or hard-to-modify storage

Requirement 10.3 expects logs to be backed up promptly to a secure central server or to media that is hard to modify. In Graylog, the practical approach is to ship copies of the audit feed to a second, separately administered destination, such as write-once object storage or a syslog relay under a different team, in addition to Data Node snapshots. Ask your team to define how quickly a backup must occur, how backup integrity is checked and who can restore it. Test a restore before the assessment, because an untested backup is hard to defend.

File integrity monitoring on audit data

Requirement 10.3 also expects file integrity monitoring or change detection on audit logs, so that unauthorized changes are noticed. Graylog does not provide this capability on its own, so it must be built with host-level tools or purchased separately. Scope the monitoring to Data Node and MongoDB data directories, the Graylog configuration and any exported archive files, and send alerts to a team outside the log administrators. Confirm with your assessor how they expect the monitoring to be evidenced, including baseline records and alert handling.

Configuring Graylog for requirement 10 in sequence

This sequence takes a cardholder data environment from scope definition to a tested Graylog deployment that collects the required logs, keeps them for the retention period, restricts access, time-aligns every source and runs a daily review. Each step produces an artifact your assessor can inspect.

Confirm in-scope components and log sources
Your QSA or internal compliance lead, with the platform team, lists every system that stores, processes or transmits cardholder data or sensitive authentication data, plus the critical system components and security functions that could affect that environment. Map each component to the data flows that connect it, including administrator access paths and any service providers. Record the result in your PCI scope definition. This step is done when every in-scope source has a named owner and an entry in the scope document, and the list is the input for every later step.
Deploy a multi-node Graylog cluster
The platform team builds the cluster following the Graylog multi-node guide for medium to large deployments: three Graylog server nodes and three MongoDB nodes running as a replica set, three Data Nodes on their own cluster, and a load balancer in front of the Graylog nodes. Set is_leader to false on the follower Graylog nodes. Place the cluster inside the CDE boundary or a segment with controlled access, following your scope decisions. Done means every node reports healthy, the replica set has a primary, and a test message sent through the load balancer is searchable.
Create inputs and stream routing per source
Configure one input per log source type, such as syslog, GELF or Beats, depending on what each component supports. Route messages into streams by source group so that cardholder environment events, administrator activity, authentication events and security tool output land in separate streams that the review and alerting steps can target. Confirm that each in-scope event type from the scope document arrives. Done means a sample event for each required category appears in the correct stream, and any source that cannot send its events is logged as an exception with an owner.
Build index sets for 12 months with three months hot
Create index sets that hold 12 months of audit log history, with at least the most recent three months searchable at all times. Size the storage using the Graylog guidance of daily ingest multiplied by retention days multiplied by 120 percent, and give the message journal 3 to 5 times daily ingest on SSDs. Set index rotation and retention so the oldest indices are deleted only after the 12-month window. Confirm the number of open indices in your configuration. Done means a test index set shows the planned retention settings, and the sizing worksheet is filed with your evidence.
Define roles and restrict access to audit logs
Create Graylog roles that grant search access to the streams and index sets only for people with a job-related need to read audit logs. Keep administrative rights to configuration separate from log read access, and review role membership against your access approval records. Configure authentication through your directory where the edition you hold supports it. Confirm that log data cannot be edited through the Graylog interface and that the backups and file integrity or change detection you use cover audit log storage. Done means a role test shows that an unauthorized user cannot search the restricted streams.
Configure and verify time synchronization
Point every in-scope host, Graylog node, MongoDB node, Data Node and log-producing device at designated time sources using NTP or an equivalent time-synchronization service, and restrict who can change those time settings. Compare clock offsets across hosts and confirm that message timestamps in Graylog agree with the source clock. Document the time sources and the check procedure. Done means a comparison report shows consistent time across the in-scope estate, and any device that cannot sync is recorded as an exception with a remediation owner.
Build event definitions for daily review and notifications
Create event definitions for the conditions your review procedure must catch, such as failed logins, changes to privileged accounts, log collection stopping and access to audit logs. Set a daily review search or dashboard that the responsible reviewer works through, and record each review outcome. Connect notifications to PagerDuty, Slack or email where your edition supports them. Automated review is required under the current standard, so confirm which event definition and notification options your license includes before you commit the design. Done means a test event fires an alert, reaches the intended channel, and leaves a record.
Test backups and restore before sign-off
Back up the MongoDB configuration data and the Data Node or OpenSearch indices on the schedule your retention plan requires, and store copies in a secure central location or hard-to-modify media. Perform a restore into a separate test environment and confirm that searches return the expected events, streams and event definitions come back, and the retained indices are complete. Record the restore date, the operator and the result. Done means a documented restore test passes and the evidence is filed with the scope and sizing records.

Evidence Graylog produces for a PCI DSS assessor and how to keep it

A PCI DSS assessor will ask for proof that logging, retention, access, review and time sync work as described, not just that they were configured once. Each card below names an artifact Graylog can export or record, what the assessor asks for, and how to keep it under change control so the evidence still matches the live system at assessment time.

Index set and retention configuration exports

Export the index set settings that set rotation and retention, including the rotation strategy and the number of indices kept, and store each export with its change record. Assessors compare these settings against the 12-month retention and three months immediately available requirement under 10.5.1, so the export must show the retention in effect on the sampled dates. Keep the configuration in version-controlled files or dated snapshots, and confirm with your team how your Graylog version supports exporting these settings.

Stream and input inventories mapped to 10.2.1

Maintain an inventory listing each input, the source systems behind it and the streams that route their events, with a column mapping each source to the 10.2.1 event types it covers. This shows the assessor that cardholder data environment components, administrator actions, audit log access and credential changes actually reach Graylog. Review the inventory whenever a system joins or leaves the cardholder data environment, and record that review in the change ticket.

Role and access review records

Keep a dated export of Graylog roles, the streams and dashboards each role can read, and the users assigned to them, along with signed review records. Requirement 10.3 limits read access to audit logs to people with a job-related need, so the review should confirm that only current analysts and administrators hold access. Pair the export with your identity provider records for leavers and movers, and confirm how your chosen authentication method is configured in your environment.

Event definition and notification history

Export the event definitions that perform daily review, along with the notification channels they use and the history of fired events and who acknowledged them. Requirement 10.4.1.1 expects automated mechanisms for audit log review, so the assessor will sample event records and follow them to a documented response. Store the definition exports in change control, and retain the notification and triage history for the review period the assessor samples.

Time sync configuration and monitoring records

Record the designated time sources used by Graylog nodes, MongoDB members, Data Node or OpenSearch nodes and the log sources feeding them, along with the monitoring that shows drift is detected. Requirement 10.6 asks for correct and consistent time from designated servers with protected time settings, so keep the configuration files and access records for those settings. Confirm with your platform team how clock offset is monitored on every node, since Graylog itself does not replace host time synchronization.

Backup and restore test records

Keep records of scheduled backups of Graylog configuration and MongoDB metadata, plus dated restore tests showing that the configuration and a sample of log data can be recovered. Requirement 10.3 expects logs to be protected and promptly backed up to a secure central location or hard-to-modify media, so the assessor will ask where backups are stored and who can change them. Document each test with its scope, result and corrective actions, and store the record alongside the change history.

What buyers ask before hiring help with PCI DSS requirement 10 logging

What does outside help for PCI DSS requirement 10 logging cost?

The cost depends on the written scope, which is why DeployOpen does not publish a price list and gives a quote only after the scope is agreed. The main cost drivers are the number of systems in the cardholder data environment that send logs, the number and type of log sources, the retention volume needed for 12 months with three months searchable, whether the design needs a highly available cluster, how many notification integrations are required, and how much of the daily review automation must be built. Setup work is one-time, while support, upgrades and continuous testing are recurring and usually sold as retainers. Ask for the quote to separate design, build, testing and handover, and to state what is excluded. The Graylog software itself has a published starting point: 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 (per the Graylog pricing page).

How long does a Graylog requirement 10 project take?

Duration depends on scope, so no timeline is given here. The factors that lengthen work are the number of log sources that need parsing, the state of existing logging in the cardholder data environment, the storage sizing and index design, the high availability architecture, and how many event definitions and review workflows must be written and tested. Fixed-scope engagements agree deliverables and timelines in writing before work starts, so the schedule is set from the scope document rather than assumed. Ask for a schedule that lists each milestone and the client dependencies behind it.

What must our team provide before an implementation starts?

Your team needs to supply five things before design work can be sized accurately. First, a written scope statement that identifies the cardholder data environment, the components that store, process or transmit cardholder data, and the critical and security components in scope. Second, an asset inventory listing hosts, network devices, applications and cloud services with their log sources. Third, the access model, including who needs read access to audit logs and who administers Graylog. Fourth, the authoritative time sources your systems already use. Fifth, named owners for the daily log review and for responding to alerts. Missing items usually show up later as rework, so confirm each one with your assessor and internal owners early.

Can our own team set up Graylog for PCI DSS requirement 10?

A capable platform team can install Graylog and configure basic inputs, streams and searches, and the Graylog documentation covers package and Docker installs and multi-node layouts. The trap is treating installation as the compliance work. Requirement 10 also depends on the event types you collect across every in-scope component, on protecting logs from modification and restricting read access, on automated daily review with event definitions that your team can evidence, and on time synchronization across all systems. Retention sizing is easy to get wrong because storage must hold 12 months with the most recent three months searchable. Teams that build this in-house should map each sub-requirement to a configured control and a piece of evidence before go-live, and have a qualified assessor review the design.

Is Graylog Open enough for PCI DSS logging, or do we need Enterprise or Security?

Graylog Open can collect logs over inputs such as syslog, GELF and Beats, route them through streams and pipelines, search and build dashboards, rotate indices, and send notifications from event definitions. Those capabilities cover many of the requirement 10 building blocks. Enterprise adds a data lake with archive restore, data tiering, a correlation engine and 24/7 support, and Graylog Security adds compliance packs, risk scoring, anomaly detection, investigations and prebuilt threat detection content, according to the Graylog pricing and product pages. Whether you need archive restore or correlation depends on your retention architecture and your review workflow, so decide that during design. Confirm current feature availability for your version with Graylog, since the license terms of Graylog Open are SSPL-1.0 and not an OSI-approved license.

Does DeployOpen certify that our Graylog logging is PCI DSS compliant?

No. DeployOpen does not certify, issue audit reports, attestations or certifications. DeployOpen plans, builds, hardens, documents and prepares the systems, controls and evidence that a PCI DSS assessment will examine. The assessment itself is documented by your own process, either a Report on Compliance completed by a Qualified Security Assessor or a Self-Assessment Questionnaire with an Attestation of Compliance, and the payment brands decide who must validate. Certificates are not recognized as validation. Ask your acquirer or assessor which evidence they expect for requirement 10 before the design is frozen.

Which design choices change the cost of a high availability Graylog cluster?

High availability is driven by how much log loss and downtime your cardholder data environment can tolerate. 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, a load balancer, and is_leader set to false on follower Graylog nodes. Each extra node adds hardware or cloud spend, licensing considerations, and operational effort. Storage sizing also matters, since Graylog's architecture guidance suggests daily ingest times retention days times 120 percent, plus a message journal sized at 3 to 5 times daily ingest on SSDs. Ask for the sizing worksheet and the failure scenarios the quote covers.

What Graylog does not cover for requirement 10

Graylog collects, stores and helps review audit logs, but several requirement 10 obligations sit outside the platform. Each gap below names what is missing and who has to close it before an assessor will accept the evidence.

File integrity monitoring on audit logs

Requirement 10.3 expects audit logs to be protected from modification and checked for changes. Graylog stores logs in indices, but it does not replace file integrity monitoring or change detection on the log files and the Graylog data nodes themselves. Your security operations team owns this control, usually with a host-based tool that watches log paths and the storage backend. Check that the tool alerts on changes and that its own logs flow back into Graylog.

Endpoint and application log sources

Graylog only sees what is forwarded to it. Requirement 10.2.1 asks for audit logs from every system component and cardholder data environment access path, including administrator actions, credential changes and invalid logins. Your platform and application teams own enabling those audit settings and configuring forwarders such as syslog or Beats on each host, database, firewall and payment application. Build an inventory of sources and reconcile it against the in-scope component list before the assessment.

Customized approach decisions

If you meet a requirement in a different way than the defined approach, PCI DSS v4.x requires a customized approach with documented objectives, risk analysis and evidence. Graylog configurations such as alternative review cycles or alternative retention tiers may qualify, but the decision is yours and your QSA must accept it. Document the stated objective, the test method and the owner in writing before you rely on it.

SSPL-1.0 licensing constraints

Graylog Open is licensed under SSPL-1.0, which is not an OSI-approved open source license. Some organizations, including those with internal rules that require OSI-approved licenses, may not accept it. Your legal and procurement teams own this review. Confirm the license terms against your policies and the current license file before you choose the edition and the deployment model.

Edition-dependent features

Some capabilities that help with requirement 10, such as the correlation engine, archive restore, data tiering and compliance packs, need Graylog Enterprise or Graylog Security rather than Graylog Open. Your architect owns the edition decision and must confirm which features your design depends on. Price these as recurring license costs, since they are based on processed data, and ask the vendor for a written quote tied to your daily volume.

The assessment itself

Graylog can produce evidence, but it cannot validate compliance. A Qualified Security Assessor completes a Report on Compliance, or your organization completes a Self-Assessment Questionnaire with an Attestation of Compliance, and the payment brands decide who must validate. Your compliance lead owns the assessment, and DeployOpen prepares systems and evidence for it without issuing any report or attestation. Confirm the validation level and assessor early.

Which PCI DSS version and dates apply to your logging design

PCI DSS v4.0.1 is the only active version of the standard, so your Graylog logging design should be built against it. The v4.0.1 release was published on 11 June 2024 as a limited revision of v4.0, with no requirements added or deleted. PCI DSS v4.0 was retired on 31 December 2024, and v3.2.1 was retired earlier, on 31 March 2024. For Requirement 10, this means the controls described on this page (event collection under 10.2.1, read restrictions and file integrity monitoring under 10.3, retention under 10.5.1, daily and automated review under 10.4.1 and 10.4.1.1, and time synchronization under 10.6) are the ones an assessor will check against.

Several of the v4.x requirements were future-dated, meaning they were optional best practices until they became mandatory. Of the 64 new requirements in v4.0, 51 became effective on 31 March 2025. Requirement 10.4.1.1, which mandates automated mechanisms for audit log reviews, is one of them. If your Graylog event definitions and dashboards currently serve only as a manual review aid, treat automated review as a present obligation rather than a planned improvement, and confirm with your assessor how they will evidence it.

The PCI SSC opened a request for comments from 3 June to 20 July 2026 to begin the next iteration of the standard, and as of October 2026 it had announced no release date for a new version. Do not design around a version that has not been published. Instead, record the v4.0.1 requirement IDs in your Graylog design documentation, and confirm the currently accepted version and any transition dates with the PCI SSC and with your payment brands, since the brands decide which entities must validate and on what timeline.

How DeployOpen scopes, configures and documents Graylog for PCI DSS logging

DeployOpen plans, implements, hardens, documents and supports self-hosted Graylog inside your own infrastructure, so the logging design for your cardholder data environment stays under your control. We start from the PCI DSS requirement 10 controls your assessor will sample, then build and hand over Graylog evidence that maps to them.

How we scope

Written scope lists the in-scope systems, log sources and cardholder data environment boundaries Graylog must cover for requirement 10.
We agree the defined or customized approach for each requirement with your QSA or internal assessor before configuration begins.
Fixed-scope engagements set deliverables and timelines in writing, and the quote follows from that scope.

How we build

We deploy Graylog server nodes, MongoDB and the Data Node or OpenSearch backend in your environment, sized against your ingest and retention needs.
Inputs, streams and processing pipelines are configured for the event types in scope, with index sets set to keep 12 months with three months searchable.
Access roles, event definitions for daily review, and time synchronization checks are built and tested against documented acceptance cases.

How we hand over

You receive configuration records, role and access matrices, retention settings and event definition inventories mapped to requirement 10 sub-requirements.
Runbooks cover daily review steps, alert triage, backup and restore of Graylog data, and how to evidence each control to an assessor.
We walk your operations and security staff through the system so they can run daily review and change control without us.

How we support

Ongoing support, upgrades and continuous testing are available as retainers after handover.
Retainers can cover Graylog version upgrades, reviewing event definitions after scope changes, and periodic checks of retention and access controls.
DeployOpen prepares systems and evidence for assessments, while independent QSAs and assessors issue the Report on Compliance or other validation.