When an auditor sits down with your team, they don’t ask whether you have a SIEM. They ask you to prove something: show me every privileged access event on this system for the last twelve months, timestamped, complete, and unaltered. Compliance in financial services isn’t a posture; it’s an evidence problem. And the moment you treat your SIEM as the place where evidence lives, you’ve put your audit trail on the most expensive, most volatile, and least complete layer of your stack.
That’s a strong claim, so let’s make the case.
The SIEM was built to detect, not to retain
A SIEM is an analytics engine. It’s optimized for correlation, alerting, and investigation over a hot window of data. None of that is the same as retaining a complete, demonstrable record of everything that happened across your environment. The mismatch shows up in three predictable ways:
- Gaps at the point of collection
-
If a log source isn’t onboarded (a legacy core banking system, a Windows host that the native agent doesn’t fully cover, an air-gapped node, an OT segment), then it simply isn’t in the SIEM. From an auditor’s perspective, "we didn’t collect it" and "the control failed" look identical.
- Cost pressure that quietly creates gaps
-
Ingestion-priced platforms make completeness expensive. The standard response (sampling, dropping "low-value" sources, shortening retention) is both a reasonable cost decision and a compliance liability. You don’t find out which logs you need until the audit or an incident requests them.
- Vendor change resets your evidence
-
When you switch or add a SIEM (and over a DORA- or PCI-DSS-length horizon, you will), re-instrumenting every source means your historical, audit-ready record is tied to a product you no longer run.
A pipeline-first framework
The fix is to stop asking the analytics layer to also serve as a system of record and to put a telemetry pipeline underneath it. The pipeline’s job is the unglamorous, durable work that compliance depends on:
-
Collect everything at the source. Every host, every OS, every format, including the legacy and Windows-heavy systems that native SIEM agents struggle with.
-
Normalize and timestamp on the way through, so an event is audit-ready the moment it’s captured, not after a downstream parser gets to it.
-
Retain independently of the analytics tier: full-fidelity records in storage you control, at a cost that doesn’t punish completeness.
-
Route anywhere. Send the slice your SIEM needs for detection, send the complete record to retention, and send a subset to a second tool. You decide, per source.
This is the difference between NXLog Platform and a SIEM: it’s a pipeline, not a SIEM. It sits in front of whatever analytics tools you run and owns the part that the auditor grades.
Why this travels across regions
Financial institutions rarely adhere to a single framework. A pipeline-first model is deliberately region-independent. DORA, NIS2, and PCI DSS in the EU, and SOX, GLBA, NYDFS, FFIEC, and SEC requirements in the US, are different checklists asking the same underlying question: can you produce a complete, tamper-evident, retained record on demand? Solve it once at the pipeline layer, and you’re answering all of them, instead of re-solving compliance every time a new framework lands.
This isn’t theoretical. A business division of one of the world’s top-tier automotive groups, operating across direct banking, financing, leasing, insurance, and payments, set out to meet exactly this spread of mandates (SEC, SOX, PCI, GLBA, plus national and corporate regulations) by replacing a log-collection tool it considered obsolete and hard to manage. The goal it set wasn’t "buy a better SIEM." It was to build a single vendor-agnostic pipeline that could integrate old and new systems alike and feed into whatever downstream tools the business chose. On that foundation, the business achieved compliance. NXLog runs in financial institutions across both regions on the same principle, from European banks like La Banque Postale and QNB Finansbank to one of the largest banks in the US.
The controls auditors keep asking about
A pipeline is also where several recurring audit requirements are cleanest to satisfy, at the collection and routing layer rather than bolted on after the fact.
File integrity monitoring (FIM) to prove critical files and records weren’t altered:
<Input fim>
Module im_fim
File '/etc/*'
Recursive TRUE
ScanInterval 3600
</Input>Personally identifiable information (PII) handling to redact sensitive fields before data leaves the source, so a card number isn’t written to a log a downstream tool retains:
<Input app_logs>
Module im_file
File '/var/log/app/*.log'
Exec $raw_event =~ s/\b\d{13,16}\b/[REDACTED-PAN]/g; (1)
</Input>| 1 | Redact anything that looks like a card number before the event leaves the host. Treat this as a sample of what can be done. You’ll want to test this regex extensively prior to rollout. |
And role-based access control (RBAC) governs who can see and manage telemetry centrally rather than per tool.
The takeaway
Your SIEM choice should be free to change. Your compliance evidence shouldn’t move when the SIEM does. Put the pipeline first, and the audit trail becomes an architectural property of your estate rather than a feature of one vendor’s product.
