Snare Insider Issue #14 Sept 2026

You are here: Home / Blog / Newsletter / Snare Insider Issue #14 Sept 2026
Subscribe to the Snare Insider Book a Demo

Newsletter Issue #14

Changing Your SIEM Shouldn’t Impact The Continuity Of Your Evidence.

Own the collection layer. Control the cost. Keep your options open.

Cybersecurity architecture is entering another period of change.

Security teams are consolidating platforms. Legacy SIEMs are being reconsidered. AI-native security platforms are emerging, Databricks launched Lakewatch, an open security Lakehouse SIEM, in March 2026, and it will not be the last. Cloud security architectures continue to expand. Data volumes are increasing. And organisations are being asked to demonstrate better security outcomes while controlling the cost and complexity of the technology stack.

IDC’s December 2025 survey found 84% of respondents agreed or strongly agreed that their organisation is prioritising security platformisation. At the same time, concern about dependency remains one of the barriers preventing organisations from consolidating as aggressively as they might otherwise choose.

There is a reason for that tension.

Consolidation can simplify security operations.

Dependency can restrict them.

Nowhere is that distinction more important than in logging.

Many organisations understandably think about log collection, storage, analytics and investigation as parts of their SIEM deployment.

But they do not have to be all linked.

Your SIEM is where you analyse security data. It does not have to own how that data is collected.

And if you decide to replace your SIEM, you should not automatically have to replace thousands of agents, reconstruct every forwarding rule, redesign your retention strategy or rebuild the security-data pipeline from the endpoint upwards.

Changing your SIEM should be a routing decision, not an endpoint project.

That distinction is becoming more important as both attacks and security data continue to accelerate.

Verizon’s 2026 DBIR, its 19th edition, covering more than 22,000 confirmed breaches across 145 countries, found that vulnerability exploitation now accounts for 31% of breaches, overtaking credential abuse (13%) as the leading initial access vector for the first time in the report’s history. Third-party involvement rose to 48% of breaches, a 60% year-on-year increase. Ransomware appeared in 48%. And only 26% of CISA Known Exploited Vulnerabilities were fully remediated during the period, down from 38%.

CrowdStrike’s 2026 Threat Hunting Report found that 88% of observed exploitation involving a published proof of concept occurred within 48 hours of release during the first half of 2026. Vishing intrusions doubled over the same period, and monthly device-code phishing attempts rose fifteenfold.

IBM, meanwhile, puts the global average cost of a data breach at a record US$4.99 million, up 12%, with AI-driven attacks up 56%, and mean time to identify and contain back up to 247 days, reversing five consecutive years of improvement.

THE NUMBER THAT SHOULD SHAPE YOUR ARCHITECTURE

A 43-day median time to remediate a known-exploited vulnerability, against a 48-hour median time to exploitation, is not a patching gap you can close by patching faster.

It is a gap that has to be covered by detection and by evidence, which means the telemetry has to already be collected, retained and searchable before the alert, not provisioned after it.

Security teams therefore need more visibility.

But more visibility does not have to mean:

More SIEM ingestion.

More cost.

More dependency.

More disruption when things change.

This issue of Snare Insider looks at the architecture sitting underneath those challenges, and why maintaining control of the security evidence layer may be one of the most important decisions organisations make about their future SOC.

In this issue

  1. Global Cyber Threat Pulse
  2. Threat Spotlight: The Tools You Trust Are Becoming Attack Paths
  3. The Security Data Cost Problem Is Really an Architecture Problem
  4. Dependency Starts Earlier Than Most Organisations Realise
  5. Quick Read: Consolidation Without Dependency
  6. Quick Read: The Rise of Portable Security Data
  7. The Snare Perspective: Separate the Evidence Layer From the Analytics Layer
  8. AskSnare: Your Investigation Capability Should Be Portable Too
  9. Quick Read: 10 Questions to Ask Before Your Next SIEM Renewal or Migration
  10. Key Takeaway
  11. Sources & Resources

TL:DR

1.Global Cyber Threat Pulse

Four regions, four incidents, one recurring problem.

In Australia, two ACSC High Alerts five days apart — N-able N-central (CVE-2026-18556 and CVE-2026-18577, CVSS 8.2 authentication bypasses) where attackers abused the built-in Take Control feature and deployed Cloudflare Tunnel for persistence, and JetBrains TeamCity (CVE-2026-63077, CVSS 9.8 unauthenticated RCE).

In Asia, two Singpass compromise operations where every authentication was entirely valid — including mobile phone shop staff exploiting routine customer interactions, with 171 further victims identified.

In Europe, Rhysida’s Berlin intrusion, where roughly seven days passed between first detection of suspicious data movement and disconnection of affected departments, and where officials still cannot validate the attacker’s claimed figures.

In North America, the Thomson Reuters C-Track incident: files obtained in March 2026, discovered on 30 June. Together they make one argument — organisations need independent, retained, searchable evidence.

Read the Full Article

Threat Spotlight 

2.The Tools You Trust Are Becoming Attack Paths

Attackers increasingly do not need malicious software; they use legitimate identities, remote-management platforms, SaaS applications, developer tools and administrative utilities.

Verizon’s 2026 DBIR puts vulnerability exploitation at 31% of breaches, overtaking credential abuse for the first time in 19 years, with a 43-day median time to remediate a known-exploited vulnerability.

CrowdStrike found 88% of proof-of-concept-linked exploitation happening within 48 hours.

That gap cannot be closed by patching faster, it can only be covered by telemetry that was already being collected.

The section includes a table setting out what RMM abuse, device-code phishing, OAuth-integrated SaaS abuse, CI/CD compromise, tunnelling persistence and anti-forensic activity each actually look like in the logs, and the specific sources that distinguish them.

Read the Full Article

Feature

3.The Security Data Cost Problem Is Really an Architecture Problem

The problem is not that logs lack value; it is the assumption that every log must be processed, retained and queried in the same place. Ingestion pricing couples two unrelated things, the value of a log on arrival, and the cost of keeping it available months later, which forces a decision that is wrong for one of them.

The answer is not to collect less, but to route by purpose, and the section includes a model classifying data by detection value and investigative value separately. It also separates three operations most cost programmes conflate: filtering, transformation and routing.

A programme that only filters is a visibility-reduction programme. Retention runs on two clocks, the investigation clock (247 days on IBM’s current detection average) and the regulatory clock (GDPR, NIS2, DORA, SEC), and the ASD ISM has already shifted its emphasis from seven-year retention to twelve months in a searchable form.

Read the Full Article
Subscribe to the Snare Insider Book a Demo

Feature

4.Dependency Starts Earlier Than Most Organisations Realise

Conversations about what a SIEM change would involve usually start with dashboards and detection rules, which are the shallowest layer.

The deeper dependency sits in six places: collection agents, parsing and schema, detection content, historical archive format, integration surface, and now the AI investigation layer. Each has a specific test worth running before renewal.

The section recommends estimating cost of change explicitly, agent redeployment, parser rebuild, detection rewrite, historical conversion, integration rework and retraining, because if that figure exceeds the annual licence, the renewal is being decided by switching cost rather than by fit.

Read the Full Article

Quick Read

5.Consolidation Without Dependency

Security consolidation is one of the major CISO conversations of 2026, and there are good reasons for it. Tool sprawl creates integration overhead, multiple contracts, skills requirements, fragmented telemetry, operational complexity, duplicate capabilities and additional cost.

The benchmark data supports the instinct. Wiz’s 2026 CISO Budget Benchmark, drawn from more than 300 security leaders, found that 58% of organisations now run more than 25 security tools, with larger enterprises often running 50 or more, and that nearly half of CISOs say cloud complexity and tool sprawl are actively holding their security programmes back. Eighty-five per cent increased budgets, and nearly nine in ten expect to increase again, yet more than half still believe their organisation under-invests relative to risk.

Consolidation can therefore be entirely rational.

But consolidation and dependency are not the same thing.

THE DEFINITION PROBLEM

IDC’s December 2025 survey found 84% of respondents prioritising security platformisation. But its March 2026 CISO Hub data shows close to two-thirds of senior security decision-makers saying they already have a platform, with no shared definition of what that means or where it is anchored. IDC characterises the result as fragmented islands of platformisation rather than genuine consolidation.

If the market has not settled on what a platform is, anchoring your data architecture to any single vendor’s definition of it is a bet on a moving target.

An organisation can consolidate operational platforms while retaining independence at the data layer. That gives security leaders more freedom to negotiate the next SIEM contract, evaluate an alternative platform, move workloads between platforms, run different SIEMs in different regions, support acquisitions running different security stacks, change MSSPs, run a genuinely competitive proof of concept, adopt an emerging AI-native analytics platform, or maintain one system for active analytics and another for long-term evidence.

The collection layer becomes the constant. Everything downstream becomes a choice.

For MSSPs, this is not hypothetical

Much of the consolidation conversation is written for the single-tenant enterprise. For a managed provider it plays out differently, and more acutely.

An MSSP runs detection across a customer base that has already chosen different SIEMs, different clouds, different data-residency positions and different retention obligations, and that composition changes every time a customer is won, lost or acquired. A few consequences follow directly:

  • The evidence layer has to be multi-tenant at collection, not only at analytics. Tenant separation applied downstream of a shared collection estate is a commercial and contractual problem waiting to happen.
  • Onboarding a customer should not require deploying your SIEM’s proprietary agent into their environment, and offboarding should not mean their evidence leaves with your licence.
  • A customer moving from one SIEM to another should be a routing change on your side, not a re-agenting project on theirs.
  • Regional routing matters. An EU customer’s data may need to remain in-region under NIS2, DORA or GDPR expectations while your SOC still needs to query it operationally.
  • The August N-able alerts make the point sharply: an MSSP’s own administration platform is customer-facing infrastructure, and its audit trail is evidence you may need to produce to every customer at once.

An MSSP whose collection layer is independent can price, win and retain business that a SIEM-coupled competitor structurally cannot.

Quick Read

6.The Rise of Portable Security Data

Another interesting trend is occurring underneath the platform conversation. Security data itself is becoming more portable.

The Open Cybersecurity Schema Framework, OCSF, is the clearest example. Launched in 2022 with support from AWS, Splunk, IBM and Cisco, and derived from schema work contributed by Broadcom (Symantec), it joined the Linux Foundation in November 2024. The current release, version 1.4.0 (January 2025), adds event classes covering cloud resource inventory, vulnerability findings, remediation activities and threat-intelligence enrichment.

OCSF provides a vendor-neutral core security schema intended to simplify normalisation across different producers and consumers of security information, and is explicitly designed to remain independent of storage formats, collection processes and analytics platforms. AWS Security Lake uses it natively, and support now spans Splunk, IBM, Cisco, CrowdStrike, Palo Alto Networks, Okta, Datadog, SentinelOne and Rapid7.

The security market increasingly recognises that telemetry should be interoperable.

Data should be usable beyond the product that originally collected it. But there is an important caveat that rarely makes it into the marketing, and it matters more for investigation than for detection.

NORMALISATION IS LOSSY, KEEP THE RAW EVENT TOO

A normalised event is optimised for correlation. It is not always sufficient for forensics.

Fields that do not map cleanly to a schema class get dropped or flattened, and in a real investigation the decisive detail is frequently one of the awkward, vendor-specific fields that no common schema anticipated. If the only surviving copy of a log is the version a parser decided to keep, your evidence has already been edited by somebody else’s schema decisions, and the edit is invisible.

The defensible position is to retain the raw event alongside the normalised one, and to be able to produce either on demand. Open formats help here for an unglamorous reason: a Syslog RFC 5424 message or a CEF record can be read by anything, indefinitely, including by a forensic examiner three years from now with no licence to your SIEM.

That philosophy aligns closely with the way Snare approaches logging: open formats, independent collection, flexible transformation, multi-destination routing, replay, and platform-neutral storage choices, with the ability to keep the evidence layer intact while analytics technologies continue to evolve.

The Snare Perspective

7.Separate the Evidence Layer From the Analytics Layer

The SIEM is important. But it should not have to be the architecture around which every other security-data decision is built.

There are fundamentally different jobs happening across the logging lifecycle, and they have different requirements, different lifespans and different economics.

THE JOB, COLLECTION Capture the security events required to understand activity across endpoints, infrastructure and applications, and get them off the originating host immediately.
SNARE AGENT Collect detailed security and audit events close to the source across Windows, Linux, Unix, macOS and other environments, including the process-creation, credential-access and configuration-change events every scenario in this issue depends on.
THE JOB, MANAGEMENT & RETENTION Maintain policy consistency, aggregate events, reduce duplication and preserve investigation-ready evidence for as long as the investigation clock requires.
SNARE CENTRAL Centrally manage collection, aggregation, de-duplication, retention and replay.
THE JOB, ROUTING & OPTIMISATION Decide what data goes where, in what format, and for what purpose, before it reaches the highest-cost destination.
SNARE REFLECTOR Filter, transform and route events to multiple SIEMs, data lakes, archives and analytics platforms simultaneously, with independent delivery queues per destination.
THE JOB, INVESTIGATION Turn retained evidence into answers, inside the window the incident and the regulator allow.
ASKSNARE Allow analysts to interrogate Snare-managed data directly using natural-language security questions, independently of the SIEM downstream.

The distinction matters. When these capabilities are separated from the SIEM, the organisation retains control.

The SIEM is an important destination.

It is no longer the dependency around which the entire evidence architecture revolves.

Eight things an independent evidence layer should be able to do

  1. Collect at the source, under a policy you set, not a policy inherited from an analytics platform’s licensing model.
  2. Forward off-host immediately, so the evidence survives compromise of the system that produced it.
  3. De-duplicate and aggregate before anything is billed, rather than paying to ingest the same event twice and filtering afterwards.
  4. Keep the raw event and the normalised event, so correlation and forensics are both served.
  5. Route one stream to multiple destinations, each with its own filtering, transformation and retention policy.
  6. Replay history into a new platform without re-collecting it from source, the single hardest part of most migrations.
  7. Change destination without touching the endpoint estate.
  8. Query the retained evidence without going through the analytics platform, so investigation capability survives a contract change.

That creates a very different SIEM migration conversation. Instead of:

“How do we rebuild logging for the new SIEM?”

The question becomes:

“When do we start routing data to it?”

Find out more
Snare evidence architecture: endpoints, servers and domain controllers are collected by Snare Agent on the host; SaaS and cloud, network, administration platforms and CI/CD feed Snare Central directly by syslog, API or cloud audit feed; Snare Reflector routes evidence to a SIEM, an archive, a data lake and an alternative SIEM; Snare Central and Snare Reflector feed AskSnare. When the SIEM changes, only the destination changes.

8.Your Investigation Capability Should Be Portable Too

AI is the largest single step-change in investigation productivity the SOC has seen in a decade. The right strategic response is to adopt it aggressively, the analysts who can ask a question in plain language and get an answer from a year of retained evidence in seconds are simply operating at a different tempo from those translating each question into platform-specific syntax.

The workload is heading in one direction. CrowdStrike observed AI agent-triggered detection leads growing at 2.5 times the rate of human-triggered leads, more leads, arriving faster, each needing to be qualified against historical context. Meanwhile IBM found that organisations using AI and automation extensively across security operations saved an average of US$1.93 million per breach and shortened breach lifecycles by 65 days.

The question is not whether to adopt AI in investigation. It is where that capability should sit.

Security vendors are increasingly embedding copilots, assistants and agents directly into their platforms. That capability can be extremely valuable. But it introduces a portability question that most organisations have not yet had to answer:

What happens to that capability if we change platforms?

If the AI exists only inside the SIEM, changing SIEMs can mean changing the analyst interface, investigation workflows, query language, accumulated AI investigation history, investigation methodology, automation and analyst training, all at once, and all in the same quarter.

AskSnare takes a different approach. It works with the security data managed through Snare rather than being tied to whichever SIEM happens to be downstream. That means analysts can continue asking questions such as:

  • Which accounts initiated remote-control sessions on managed endpoints last month, and from which source networks?
  • What did this account do in the 48 hours after its registered contact details changed?
  • Which hosts made outbound connections to tunnelling infrastructure they had never contacted before?
  • How much data left this file share in August, to which destinations, and over what window?
  • Which privileged accounts were created or elevated in March, and by whom?
  • Show me failed authentication activity for this user across the last 30 days.
  • Was any event log cleared on these hosts, and did our collection pipeline record events after that point?
  • Did this activity occur anywhere else in the estate?

Those are the questions this issue’s incidents actually generate, and every one of them reaches backwards into retained evidence rather than forwards from an alert.

The SIEM may change.

The investigative relationship with your security evidence does not have to.

Snare describes AskSnare as a portable AI investigation layer that queries Snare data independently of the SIEM in use.

Find out more

Quick Read

9. TEN Questions to Ask Before Your Next SIEM Renewal or Migration

Before renewing or replacing a SIEM, security leaders should understand exactly where dependency exists. Each question below has a technical test attached, the answer should be demonstrable, not assumed.

  1. Who controls our log collection agents?

Would changing SIEM require changing software across the endpoint estate?

Test: count the hosts, and ask who would perform the redeployment and over what change window.

  1. Can our existing collection layer route to another SIEM?

Or is it tied to the current destination?

Test: name the configuration change required to add a second destination, and confirm it does not require an agent update.

  1. Can we send the same data to two SIEMs simultaneously?

This matters enormously during migration and validation.

Test: confirm independent delivery queues per destination, so a slow or unavailable destination does not back-pressure the other.

The SIEM Independence Checklist

How locked in is your security-data architecture?

A scored technical worksheet for CISOs, security architects, SOC leaders and MSSPs. Ten domains, each with a short set of pass/fail tests you can run against your current environment, a scoring band, and a prioritised remediation path.

  1. Where does our historical evidence live?

Would we lose practical access to it after terminating the current SIEM?

Test: read the contract clause covering data access post-termination, and the export format it specifies.

  1. Can old logs be replayed into another analytics platform?

Historical data should remain operationally useful, not merely stored.

Test: replay a week of last year’s data into a test instance and time it.

  1. Which data genuinely needs real-time SIEM ingestion?

And which requires retention but not permanent high-cost analytics?

Test: classify your top twenty sources by detection value and investigative value separately, and see how many sit in different tiers.

  1. Can filtering and de-duplication happen before SIEM billing begins?

Cost optimisation is far more effective upstream.

Test: measure your current duplication rate, the same event arriving via two collectors is a surprisingly common line item.

  1. How much detection and investigation logic is proprietary?

Understand the cost of rebuilding rules, searches, dashboards and workflows.

Test: count active detections and estimate person-days per detection to re-express and re-tune.

  1. Is our AI investigation capability tied to the SIEM?

AI is becoming the newest layer of platform dependency.

Test: ask whether investigation history, prompts and methodology transfer, or terminate with the licence.

  1. Could we change SIEMs without touching the endpoint estate?

If the answer is no, the analytics platform has become part of the security-data architecture rather than a consumer of it.

10.Key takeaway

Own the Evidence. Choose the Analytics

Cybersecurity platforms will continue to change. AI-native SIEMs will emerge. Existing platforms will add capabilities. Security vendors will consolidate. Organisations will change MSSPs. Cloud strategies will evolve. Pricing models will change. Regulatory requirements will change. And the amount of security telemetry enterprises need to manage will continue to increase.

Trying to predict which security analytics platform an organisation will be using five or ten years from now is increasingly difficult.

There is a simpler architectural response.

Subscribe to the Snare Insider Book a Demo

Do not make the evidence dependent on the analytics platform.

  • Collect security data independently, at the source.
  • Maintain control over how it is filtered, transformed and retained.
  • Use open formats, and keep the raw event alongside the normalised one.
  • Route information according to security, regulatory and business requirements, not licensing ones.
  • Keep historical evidence accessible and searchable, not merely stored.
  • Allow competing platforms to run simultaneously when needed.
  • And make the SIEM one component of the security architecture, rather than the architecture itself.

That is the role Snare can play.

SNARE AGENT Consistent collection across the estate, close to the source.
SNARE CENTRAL Manages, aggregates, retains and replays security evidence.
SNARE REFLECTOR Controls where that evidence goes, and what reaches expensive downstream platforms.
ASKSNARE Gives security teams an investigation layer that remains available independently of the SIEM.

Because changing your SIEM should not mean starting your logging strategy again.

Platforms will change.

Your security evidence doesn’t have to.

Sources & Resources

This issue draws on primary regulatory text and named industry benchmarking rather than secondary summaries. Key sources:

Verizon, 2026 Data Breach Investigations Report (19th edition, published May 2026)

More than 22,000 confirmed breaches across 145 countries. Vulnerability exploitation at 31% of breaches overtaking credential abuse at 13%; third-party involvement in 48% of breaches, up 60% year on year; ransomware in 48%; 26% of CISA KEV entries fully remediated, down from 38%; median KEV remediation 43 days, up from 32.

CrowdStrike, 2026 Threat Hunting Report (published 3 August 2026)

Covering July 2025 to June 2026. Trusted-relationship abuse across identity, cloud, SaaS, AI services and software supply chains; 88% of PoC-linked exploitation within 48 hours; vishing intrusions 2x; device-code phishing 15x; cloud-conscious eCrime up 171%; SNARKY SPIDER account takeover to data theft in under five minutes; AI agent-triggered detection leads growing at 2.5x the rate of human-triggered leads.

IBM, Cost of a Data Breach Report 2026 (IBM and Ponemon Institute, published 29 July 2026)

Global average breach cost US$4.99M, up 12%; AI-driven attacks up 56% and present in one in four malicious breaches, averaging ~US$6M; mean time to identify and contain 247 days; detection and escalation plus lost business account for 63% of cost; extensive use of AI and automation associated with US$1.93M lower cost and 65-day shorter lifecycles.

IDC, European CISO Priorities in 2026

84% of respondents in IDC’s December 2025 survey prioritising security platformisation; March 2026 CISO Hub data showing close to two-thirds claiming to have a platform without a shared definition, characterised as fragmented islands of platformisation.

Wiz, 2026 CISO Budget Benchmark

More than 300 security leaders. 58% of organisations run more than 25 security tools, with larger enterprises often 50 or more; nearly half report cloud complexity and tool sprawl actively holding programmes back; 85% increased budgets, and more than half still believe investment is insufficient relative to risk.

ASD / ACSC, Active exploitation of N-able N-central within Australia (High Alert, 19 August 2026)

CVE-2026-18556 and CVE-2026-18577, both CVSS 8.2 authentication bypasses affecting all current versions including 2026.3. Related vendor and researcher reporting (N-able, Huntress, Rapid7, CISA KEV addition 4 August 2026) covers the incomplete-fix chain, Take Control abuse, cloudflared persistence and VPN exit-node indicators.

ASD / ACSC, Active exploitation of a software development platform within Australia (High Alert, 24 August 2026)

JetBrains TeamCity On-Premises, CVE-2026-63077, unsafe deserialisation (CWE-502) in the agent polling protocol, CVSS 9.8, unauthenticated RCE. Disclosed by JetBrains 27 July 2026; fixed in 2025.11.7 and 2026.1.3; added to CISA KEV 5 August 2026.

Singapore Police Force / GovTech, Singpass compromise enforcement operations (August 2026)

Two separate operations: arrests on 5–6 August covering more than 150 compromised Singpass accounts used to register over 30 LiquidPay accounts and more than 1,200 phone lines; and arrests on 25 August following a 21–25 August Cyber Command operation, with 171 further victims identified and more than 160 additional accounts frozen.

Berlin state network, Rhysida ransomware incident (August 2026)

Leak-site claim of 5.79TB across ~1.44 million files posted 28 August 2026, with a 30 BTC opening demand publicly rejected by Berlin’s Governing Mayor. Officials confirmed forensically verified data theft on 31 August, with a confirmed exfiltration window of 7–12 August; reporting indicates a roughly seven-day gap between first detection of suspicious data movement and disconnection of affected departments from the Landesnetz.

Thomson Reuters / West Publishing, C-Track cybersecurity incident (disclosed 2–3 September 2026)

Unauthorised access to certain C-Track files in March 2026, discovered 30 June 2026, affecting court systems in 11 US states, the US Virgin Islands and Ontario, Canada. Ontario chief justices’ statement describes unauthorised activity in a Thomson Reuters cloud environment.

Open Cybersecurity Schema Framework (OCSF)

Vendor-neutral framework for security-event normalisation and interoperability. Launched 2022; joined the Linux Foundation November 2024; version 1.4.0 released January 2025. Used natively by AWS Security Lake, with support across Splunk, IBM, Cisco, CrowdStrike, Palo Alto Networks, Okta, Datadog, SentinelOne and Rapid7.

TechTarget, “The breakup: Why CISOs are decoupling data from their SIEMs”

Reporting on organisations establishing an independent, enterprise-controlled data layer between security log sources and consuming platforms, gaining per-destination control of filtering and per-source control of retention horizons.

Regulatory references

GDPR Article 33 (72-hour notification); NIS2 Article 23 (24-hour early warning, 72-hour notification, one-month final report); DORA Article 19 with Commission Delegated Regulation (EU) 2025/301 Article 5 (4-hour initial notification from classification, 24-hour outer limit from awareness, 72-hour intermediate report, one-month final report) and classification RTS 2024/1772; SEC Form 8-K Item 1.05 (four business days from materiality determination); ISO/IEC 27001:2022 Annex A 8.15 and 8.16.

ASD Information Security Manual, event logging and retention

ISM-0859 (seven-year event log retention) rescinded December 2024 and replaced by ISM-1988, requiring event logs to be retained in a searchable manner for at least 12 months, with alignment to the National Archives of Australia AFDA Express Version 2 disposal requirements. ISM-1815 (event logs protected from unauthorised modification and deletion) maps to Essential Eight Maturity Levels 2 and 3.

*Figures and dates are current as at the time of writing. This issue is not sponsored by, endorsed by, or produced in partnership with any organisation mentioned in this issue. This is not legal advice, organisations should confirm specific obligations with qualified counsel.

Global Cyber Threat Pulse – September 2026
Snare Solutions
Powered by  GDPR Cookie Compliance
Privacy Overview

This website uses cookies so that we can provide you with the best user experience possible. Cookie information is stored in your browser and performs functions such as recognising you when you return to our website and helping our team to understand which sections of the website you find most interesting and useful.