How Graylog supports Swift CSCF control 6.4 for your local environment
If you are preparing your KYC-Security Attestation against CSCF v2026, control 6.4 (Logging and Monitoring) is mandatory and now also covers your customer client connectors. Graylog can collect, retain, search and alert on the events that 6.4 asks you to record and watch. It does not determine your scope, the assessor's conclusion or the attestation you submit. Those remain yours and your independent assessor's. The control sits under the detect and respond objective and the anomaly detection principle, and 26 of the 32 CSCF v2026 controls are mandatory, so 6.4 must be covered in the annual attestation and its supporting independent assessment.
Graylog helps with the technical parts of the control: central collection of event sources into one place through inputs such as syslog, GELF and Beats, search and dashboards for regular review, event definitions that raise alerts on patterns of anomalous activity, and index retention that keeps the records for the period you set. It also gives you a searchable trail you can show an assessor. Confirm with your assessor which retention period and review evidence they expect, since the CSCF text and their methodology will drive that answer.
The parts that stay with you are the decisions Graylog cannot make. You must decide which systems and connectors fall inside your local Swift environment for your architecture type, including the customer client connectors, and which events from those systems count as security events. You must write the Swift-specific event definitions and thresholds, assign owners for alert triage, and document the process that turns an alert into a recorded response. Confirm these choices with your assessor before building the Graylog content, so the configuration reflects a scope you can defend.
Mapping control 6.4 requirements to Graylog capabilities and configuration
This table maps each part of CSCF control 6.4 to the Graylog capability that supports it and the configuration your team would need to build. Read it as a set of building blocks: no single Graylog feature satisfies the control, and each row ends with what your own team or assessor must still confirm.
| Requirement | Graylog capability | Configuration needed |
|---|---|---|
| Record security events from the local Swift environment | Inputs such as syslog, GELF and Beats receive events from hosts, applications and devices | Inventory every Swift component in scope, including SWIFT Alliance and operating system, database and identity sources, then enable the security-relevant event types on each and confirm the input type each source supports |
| Forward records from in-scope sources reliably | Graylog server nodes and the message journal buffer incoming messages | Document the forwarding agent or native log export for each source, set time synchronization on every sender, and confirm the journal sizing against expected daily ingest |
| Separate Swift-relevant records from other traffic | Streams route messages by rule into separate index sets | Create a dedicated stream for Swift environment sources with rules based on source, facility or application name, and restrict who can edit it |
| Normalize and enrich events for review | Processing pipelines parse, tag and enrich messages | Write pipeline rules that extract user, account, host and action fields, and tag records from customer client connectors so they can be filtered during review |
| Detect anomalous actions and operations | Event definitions run real-time and historical checks on searches, with aggregation conditions | Define rules for failed or unusual logins, administrative changes, off-hours activity and unexpected operations, and record the baseline and threshold chosen for each |
| Alert the responsible team promptly | Notifications to PagerDuty, Slack and email from event definitions | Name the notification targets, the priority for each event, and the escalation contact, then test each path end to end |
| Review events and show follow-up | Search and dashboards support daily review and investigation | Build a dashboard for the Swift stream, schedule a review record for each cycle, and keep triage notes outside Graylog if your procedure requires it |
| Attestation and independent assessment | Graylog supplies stored records, event history and search results | Your team supplies the assessor's evidence walkthrough, the attestation in KYC-SA and the proof that the controls were independently assessed. Confirm the assessor's expectations before finalizing the design |
Configuring Graylog for control 6.4 in the order an assessor will test it
This sequence walks from scope confirmation to a tested alert path, so each step produces the evidence an independent assessor will ask to see for control 6.4. It shows how the architecture, collection, detection and access settings line up with what the control expects the user to record and detect.
Confirm architecture type and in-scope components
The security or compliance lead, working with the Swift operations team, identifies the architecture type that applies to the local Swift environment (A1, A2, A3, A4 or B) and lists every in-scope component for control 6.4, including customer client connectors brought into scope from CSCF v2026. Keep the scope decision as a signed record, because the assessor will start by checking that every in-scope source feeds the logging design. Done when each in-scope system has a named owner and a log source listed against it.
Deploy Graylog server nodes and search backend
The platform team deploys Graylog server nodes with MongoDB configured as a replica set, and a Graylog Data Node cluster or a supported OpenSearch cluster for log storage, following the installation and multi-node documentation. Confirm the versions against the compatibility matrix before installing, and place a load balancer in front of the nodes. Done when the cluster reports healthy nodes, the leader node is the only node with is_leader set to true, and a test message is searchable.
Configure inputs and streams for each source
The operations team creates one input per log source, such as syslog, GELF or Beats, and routes each source into a stream that matches its scope category, for example Swift application logs, connector logs or operating system security logs. Each stream should have a clear owner, so that the assessor can see which events land where. Done when a sample event from every in-scope source appears in the correct stream within the test window agreed by the team.
Build processing pipelines that normalize events
The engineers write processing pipelines that parse each source into consistent fields such as user, action, host, outcome and timestamp, so that detection rules can compare events across systems. Store the pipeline rules in version control and record each change, since the assessor may ask how a field was derived. Done when sample events from each source show the same field names in search results.
Define event definitions for anomalies and logging gaps
The security team creates event definitions for anomalous activity within the local Swift environment, such as unexpected administrative actions or unusual transaction patterns, and for logging failures, such as a source that stops sending events. Thresholds should be set from the baseline recorded for each source, and each definition should state what it detects and why. Done when each definition has been reviewed and approved, and a documented test confirms it triggers on sample data.
Configure notifications and named responders
The security operations lead connects each event definition to a notification channel, such as email, Slack or PagerDuty as supported by the Graylog Open product, and names a responder and a backup for each alert category. The responder list should be included in the incident response procedure so the assessor can trace an alert to an accountable person. Done when a test notification reaches each named responder and the acknowledgment is recorded.
Restrict access to log data through roles
The Graylog administrator creates roles that limit who can search, edit streams, change pipelines and view alerts, and assigns those roles through the identity source the organization already uses, such as LDAP or Active Directory. Keep administrative access to Graylog separate from routine read access, and review the role membership on a schedule the team defines. Done when a test user with a read-only role cannot change pipelines or streams, and the role matrix is saved as evidence.
Document time synchronization and index retention
The operations team records the time source used by every in-scope system and by the Graylog nodes, and documents the index rotation and retention settings that apply to each index set. The record should explain how long events remain searchable and how the team confirms that clocks stay aligned. Done when the settings are exported to the control file and a spot check shows timestamps from all sources aligned within the documented tolerance.
Run a test event through the full path
The security team generates a controlled test event on an in-scope source and follows it through the input, stream, pipeline, event definition, notification, and responder acknowledgment, recording the time at each stage. The test record is the evidence an assessor will ask for to show that the control operates as described. Done when the test record shows every stage completed and the team has retained it with the control documentation.
Sizing storage and retention for Swift log volumes
Size Graylog storage before you enable the new sources, because the storage estimate is daily ingest multiplied by retention days and then by 120 percent, and every figure in that formula depends on how much the in-scope sources actually send. Graylog's system architecture guidance also advises giving the message journal 3 to 5 times daily ingest on SSDs, so the journal needs its own sizing step rather than being treated as a side effect of the index disks. Start with an inventory of the local Swift environment: the Swift interface servers, the message-handling and integration hosts, the database and directory servers, the firewalls and jump hosts, and the customer client connectors that were brought into scope for control 6.4 from CSCF v2026. For each source, record the events per second you expect, the average message size measured from a sample rather than assumed, and the peak-to-average ratio across a working day. Confirm these numbers with your Swift operations and platform teams, and keep the sample and the method on file, because an assessor will ask how the figure was derived.
Retention in Graylog is controlled by index rotation and index retention. Rotation by message count, size or time decides how large each index gets before a new one starts, and retention deletes the oldest indices once the configured limit is reached. Together these settings decide how long events stay searchable, which is the period a security team can query directly. The supplied control facts do not set a retention period for control 6.4, so the period must come from your own information security policy, your Swift attestation scope and what your independent assessor expects to sample. Ask the assessor early which look-back window they will test, and ask your compliance lead whether any longer archive obligation applies to the same records. Keep the search period and the archive period as separate decisions, and document both with the reason for each.
Connector logs are the main reason estimates made before scope expansion become wrong. Once customer client connectors become in-scope components, their authentication, session and operation events add to the daily ingest, and the volume often changes in step with customer activity rather than with Swift infrastructure alone. Re-run the estimate after the connectors are added to the input list, and treat the first full month of data as the calibration point for the storage formula. Plan a margin for growth and for busy periods, and set alerts on index disk use and journal fill level so that a sudden increase in volume does not silently create a gap in the record. If collection drops during an incident, you will need to show that the gap was detected and that the logs were not lost, so confirm with your Graylog operations owner how journal and buffer status will be monitored.
What Graylog produces that an assessor can review
Control 6.4 asks you to record security events and detect anomalous activity within the local Swift environment, and each card below is a record an assessor can sample. Keep them together as one dated evidence set, because the assessor decides whether that set is sufficient for your architecture type and in-scope components.
Configured inputs and source status
Export the list of inputs that receive events from Swift local environment components, including customer client connectors brought into scope from CSCF v2026, with each input's status and the sources feeding it. An assessor uses this to confirm that every in-scope component is actually sending logs, not only that a collector exists. Keep dated exports in version control and record who approved each new source. Check that no in-scope host has silently dropped out of the list.
Stream and pipeline configuration exports
Streams and processing pipelines show how Swift-related events are routed, parsed and separated from other traffic. Export them on a schedule and store each export alongside the change ticket that modified it. An assessor will compare the pipeline logic against the events you claim to detect, so confirm that the rules still match the current in-scope architecture after each change.
Event definition records and notification targets
Event definitions are the records that express your anomaly conditions, such as unusual operator activity or unexpected changes on Swift components, and they name where each alert is sent. Export each definition with its version history and the notification targets it uses. Confirm that every alerting destination is still staffed and monitored, since an alert routed to a retired mailbox is weak evidence of detection.
Notification history and alert triage records
The notification history shows which alerts fired, when, and whether they were delivered. Pair it with a review log that names who triaged each alert, what they checked, and how the case closed. Without that log, an assessor sees alerts but cannot see anomalous activity being acted on. Store the log in a system the Swift security owner controls, and keep it separate from the log data it describes.
Search and dashboard exports for periodic review
Saved searches and dashboards that the security team opens on a set cadence provide evidence of routine review, not just of automated alerting. Export them with their owners and filters, and keep dated snapshots that show what was reviewed in each period. Ask your assessor whether they expect a particular review frequency for your architecture type before you set one.
Role assignments for log data access
Export the user roles, team memberships and stream permissions that govern who can search, change or delete log data. Confirm that administrators who can alter Graylog configuration are a separate group from those who triage alerts. Keep dated role exports with approval records, and review them regularly so an assessor can see that access to the monitoring evidence is itself controlled.
Which Graylog edition each control 6.4 capability needs
Graylog Open covers the event recording and search work that control 6.4 starts from. It is free with no volume limits and community support, and it is licensed under SSPL-1.0, so confirm those terms with your legal team before you rely on it in a regulated environment. Any anomaly detection in Open is designed in-house from searches, streams and event definitions, and your team owns the logic and its tuning.
- Inputs and collection: Syslog, GELF and Beats inputs receive events from hosts, middleware and customer client connectors in the local Swift environment.
- Streams and pipelines: Route security events into dedicated streams and normalize fields in processing pipelines so one rule covers several sources.
- Search and dashboards: Analysts query and chart activity such as logins, privilege changes and transaction-related events.
- Event definitions and notifications: Build rules for real-time and historical monitoring, with notifications to PagerDuty, Slack or email.
- Authentication: Active Directory, LDAP and trusted header authentication cover console access. Open does not include SAML, OpenID Connect or Okta sign-on.
Check with your Swift independent assessor whether detection logic you build and tune yourself will be accepted as evidence for anomaly detection under control 6.4.
Graylog Enterprise keeps the Open workflow and adds capacity for longer retention, correlated alerting and vendor support. The Graylog pricing page lists a starting price of 15,000 US dollars per year, 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, so ingest volume and retention design drive the cost more than headcount does.
- Data lake and archive restore: Keep older events in a lower-cost store and restore them when an investigation or an assessor sample needs them.
- Data tiering: Move data between storage tiers by age, so search performance matches how often the data is queried.
- Correlation engine: Combine events across sources, such as a failed login followed by a new privileged action, into a single alert.
- 24/7 support: Vendor support around the clock matters if monitoring of the Swift environment must continue outside office hours.
- Okta, OpenID Connect and SAML single sign-on: Central sign-on for analysts, with role mapping confirmed against your identity provider.
Ask the vendor which Enterprise features apply at your expected ingest volume, and whether the minimum applies to the Swift log sources you plan to collect.
Graylog Security adds SIEM content on top of the Enterprise capabilities, for teams that want detection supplied with the product. The Graylog Open product page and the pricing page describe it as adding SIEM features. The starting price is 18,000 US dollars per year, with the same 10 GB per day or 100 Graylog Compute Unit minimum and licensing on processed data as the other paid edition. Graylog Security also requires OpenSearch 2.0 or later, which affects the backend choice and upgrade plan.
- Risk scoring: Scores entities or events so analysts can prioritize review of unusual activity.
- Anomaly detection: Supplied detection that flags deviations from baseline behavior, reducing the hand-built rule work that control 6.4 otherwise requires.
- Investigations: Structured case handling that records triage decisions, which supports evidence that alerts were reviewed.
- Compliance packs and threat content: Prebuilt content to start from, which your team still has to map to its own environment and tune.
- Backend requirement: OpenSearch 2.0 or later must be in place before the Security features can run, so plan that version into the build.
Ask which anomaly detection models are included, how they are tuned for Swift transaction patterns, and what records the investigation workflow produces for the assessor.
What Graylog does not cover for control 6.4
Graylog gives you the collection, storage and search layer for control 6.4, but several parts of the control stay with your institution. The cards below cover the decisions, edition limits and licensing checks that sit outside the product and must be owned before an assessor reviews the evidence.
Swift scope and log mapping
Deciding which parts of your local Swift environment, and which customer client connectors, fall under control 6.4 is your job, based on your architecture type. Graylog will not identify those components for you. Map each in-scope component to a named log source, confirm who owns it, and record the mapping so an independent assessor can trace every component to collected events. Gaps in this mapping show up as gaps in evidence.
Defining anomalous activity
Graylog does not interpret Swift message content or decide what counts as anomalous for your institution. You must define the thresholds, patterns and conditions that matter, then build event definitions that encode them. Document the reasoning behind each rule, because the assessor will ask why a condition was chosen and why others were left out.
Detection features need Security edition
Anomaly detection and investigations are Graylog Security features, not part of Graylog Open. An Open deployment can still run event definitions for threshold and pattern alerts, but correlation and investigation workflows must be built by hand or licensed. Confirm which capabilities your chosen edition provides before committing to a detection design.
Enterprise-only authentication and restore
SAML single sign-on and archive restore require Graylog Enterprise. Graylog Open supports Active Directory, LDAP and trusted header authentication, so teams that rely on SAML for administrator access or need to restore archived logs for an assessment must price that edition in. Check the authentication options against your identity standards early.
SSPL licensing review
Graylog Open is licensed under SSPL-1.0, which is not an OSI-approved open source license. Earlier releases used GPL v3, so the license terms depend on the version you deploy. Your legal and procurement teams should review the SSPL terms against your internal open source policy before production use, especially if the platform sits inside a regulated service.
Retention and assessor conclusions
Graylog does not set your log retention period or determine whether the independent assessment is satisfied with your evidence. Decide retention based on your own policies and the attestation process, configure index rotation to match, and agree on the evidence set with your internal or external assessor. Compatibility also depends on the Graylog, MongoDB and OpenSearch pairing in the compatibility matrix, and the current documentation covers version 7.2.
Questions buyers ask before using Graylog for Swift CSCF
How much effort does a Graylog build for Swift CSCF control 6.4 usually take?
The effort depends on how many log sources are in scope, which Swift architecture type applies, how many event definitions you need and whether you add an Enterprise or Security license on top of Graylog Open. Start by counting the in-scope sources: the local Swift environment, its operating systems, databases, identity systems and, from CSCF v2026, customer client connectors. Each source needs an input, parsing, a stream and a test that proves events arrive. Event definitions for anomalous activity then multiply the work, because each one needs tuning against real data before it can be trusted. Ask any provider to break the effort down by source group, detection rule and evidence deliverable, and to state which assumptions it depends on.
What does our team need to provide for a Graylog build against control 6.4?
The work needs four groups of people. Swift scope owners must confirm the architecture type, the systems and connectors that fall within control 6.4, and the events that count as security events for your environment. Infrastructure staff must provide hosts, storage, network paths for log transport, time synchronization and the MongoDB and Data Node or OpenSearch backends. Security operations must define what anomalous activity looks like, who triages alerts and how cases are closed. An assessor liaison should agree early on the evidence the independent assessment will sample, so that the Graylog configuration, retention settings and review records are produced in a form the assessor can check.
Can our own team build Graylog for Swift CSCF without a partner?
Yes, a team can do it in house if it already has working Graylog skills and Swift CSCF knowledge, and if it has enough time to finish the scope and evidence work, not only the technical build. Graylog Open is free to download and deploy, and the platform documentation covers inputs, streams, pipelines, index sets and event definitions. The harder part is usually the control mapping: deciding what the attestation needs, documenting how each source is covered and keeping that evidence current through the attestation cycle. If one of those three skills is missing, a fixed-scope engagement can cover the gap while your team keeps ownership of the running system.
What is one-time work and what recurs after a Graylog build for CSCF?
The build is one-time work: architecture, installation, inputs, parsing, streams, dashboards, initial event definitions and the first evidence pack. Graylog Open itself has no license fee, but the Enterprise and Security editions are licensed on processed data, starting at 15,000 US dollars per year for Enterprise and 18,000 US dollars per year for Security, each with a minimum of 10 GB per day or 100 Graylog Compute Units, according to Graylog's pricing page. Storage, backups and infrastructure recur every day. Recurring work also includes tuning event definitions to reduce false positives, reviewing alert records, handling new or changed connectors and preparing the evidence each assessment cycle. Ask for these recurring items to be shown separately in any quote.
What should a quote for Graylog support of Swift CSCF include?
A useful quote starts from a written scope. It should list the Swift architecture type, every in-scope source including customer client connectors, the log types collected, the number of event definitions and notifications, and the Graylog edition each feature requires. It should name the environments covered, such as production, disaster recovery and any test systems, and state which backend is used, including Data Node or OpenSearch, MongoDB and the topology. The evidence deliverables should be explicit: configuration exports, retention settings, access control records, review and triage procedures, and a mapping from control 6.4 to each artifact. The quote should also separate one-time build work from recurring operations and state the assumptions your team must meet.
Does Graylog on its own make our organization compliant with CSCF?
No. Control 6.4 is one of the 26 mandatory controls in CSCF v2026, and compliance is decided by your annual KYC-Security Attestation and the independent assessment that supports it. Graylog can help you record security events, detect anomalous activity and keep the evidence, but the attestation depends on the whole control set, including access, segregation and incident response. DeployOpen prepares systems, controls and evidence for compliance assessments, but it does not issue audit reports, attestations or certifications. Those come from your independent assessor and Swift's attestation process, so confirm the assessment approach with them before the build starts.
Which Graylog edition do we need for anomaly detection on Swift events?
Graylog Open covers ingestion, search, dashboards, streams, pipelines and event definitions for real-time and historical monitoring, with notifications to email, Slack and PagerDuty. Anomaly detection, investigations and prebuilt threat detection content are Graylog Security features, and the Graylog Security edition starts at 18,000 US dollars per year on the pricing page. Correlation and 24/7 support are Graylog Enterprise features. Choose the edition after you map each detection rule to the feature it needs, and confirm the feature list against the current pricing and product pages before you commit.
How DeployOpen scopes, builds and documents Graylog for Swift CSCF
DeployOpen starts by fixing which Swift architecture type applies, which log sources sit inside the local Swift environment and which customer client connectors are in scope for control 6.4. We then build, test and document a self-hosted Graylog deployment in infrastructure you control, so your internal or external assessor can trace each claim back to a configured source, search or event definition.
How we scope
- Confirm your architecture type and the Swift components that produce security events in your local environment.
- List every customer client connector in scope for control 6.4 under CSCF v2026 and record its log sources.
- Agree in writing which inputs, streams, event definitions, retention settings and deliverables the fixed scope covers.
How we build
- Install Graylog server nodes, MongoDB and Data Node in your environment, with the topology your sizing requires.
- Configure inputs, streams and processing pipelines for each in-scope source, then test that events arrive and are parsed.
- Build searches, dashboards and event definitions for anomalous activity, and test them against replayed or sample events.
How we hand over
- Document the source inventory, control mapping to 6.4, alert logic, retention settings and access model for your assessor.
- Provide runbooks for triage, alert review and gap checks, so your team can show that monitoring operated during the period.
- Walk your operations and compliance staff through the configuration and record who owns each part of the workflow.
How we support
- Support is available as a retainer for upgrades, new connectors, rule changes and assessment questions after handover.
- Retainers can cover Graylog version changes and the CSCF updates Swift publishes, scoped in a separate written agreement.
- Ask any provider for the support hours, response commitments and upgrade responsibilities in writing before you sign.
