Resources

Insights, events, and proof from the field

Latest blogs, whitepapers, webinars, in-person events, podcast episodes, and customer case studies — all in one place.

Blog

Latest posts

Thought leadership, product updates, and technical deep dives from the Elastio team.

View all posts

June 30, 2026

The 2026 DBIR Makes Recovery Your Ransomware Plan. Can You Prove It Works?

In Verizon’s 2026 Data Breach Investigations Report , 69% of ransomware victims did not pay the ransom. Declining to pay shifts the response onto recovery, because the alternative to paying for the attacker’s decryption key is restoring from your own data. The DBIR shows that refusal is climbing and the median ransom paid is falling, to $139,875 from $150,000 the year before. 48% of confirmed breaches involved ransomware, up from 44% 69% of ransomware victims did not pay the ransom 31% of breaches started with vulnerability exploitation, the top entry route for the first time in 19 years 62% of breaches involved the human element The 2026 DBIR is the largest in the report’s history : more than 31,000 security incidents and over 22,000 confirmed breaches across 145 countries, covering November 2024 through October 2025. Ransomware appeared in 48% of those confirmed breaches, and the human element in 62%. Those headline numbers describe how attackers got in and what they did once inside. They do not tell you the one thing that decided how each victim’s year ended, which was whether a clean, restorable recovery point existed when the encryption started. Not paying is a recovery bet When 69% of victims decline to pay, the ransom stops being the center of the incident. Recovery becomes the lever that determines downtime, disclosure timing, and negotiating position. The criminal economics point the same way. Chainalysis tracked on-chain ransom payments falling roughly 8% to about $820M in 2025 even as claimed attacks rose by about half. That shift puts weight on a capability the DBIR cannot see. The report classifies confirmed breaches by initial vector, actor, and action. It does not record, for each victim, the age of the most recent recovery point that was verified clean and proven restorable. That number is what separates an organization that recovers in days from one that inherits the attacker’s preferred timeline. Vulnerability exploitation moved to the front, and it changes the backup question For the first time in 19 years , software vulnerability exploitation passed stolen credentials as the top way into a breach, reaching 31% of breaches . Verizon also reported that attackers are using AI to compress the time from a disclosed vulnerability to a working exploit from months to hours. Faster exploitation compresses the time defenders have to react, and backup jobs keep running between the moment of compromise and the moment it is detected. If the intrusion predates your most recent recovery point, that recovery point can contain the malware, the staged tooling, or the altered data the attacker left behind. The backup succeeded. The copy is intact. It is also unsafe to restore. Key Distinction Immutability protects a recovery point from being changed or deleted during its retention window. It does not prove the data inside that recovery point was clean when the copy was written. A locked vault full of compromised data preserves the problem precisely. Attackers reach the backups before they encrypt Targeting recovery is common enough to have its own entry in the attacker playbook. MITRE catalogs the behavior as T1490, Inhibit System Recovery , the technique for disabling or destroying a victim’s recovery options. Survey data shows how often it is attempted: in Sophos research , 94% of ransomware victims said attackers tried to compromise their backups during the attack, and 57% of those attempts succeeded. The outcome gap is the part worth taking to a budget conversation. Organizations whose backups were compromised faced a median recovery bill near $3M, against roughly $375K for those whose backups survived, and they were about twice as likely to pay. Backups also fail under pressure for reasons that have nothing to do with an attacker. In the State of Ransomware 2025 , 38% of organizations that paid more than the original demand reported their backups had failed or malfunctioned, whether from compromise, misconfiguration, or an untested restore. At decision time the cause matters less than the result: no recovery point the team can rely on. By the time encryption begins, the attacker has often already touched the backup tools your response plan is about to call. The number that decides the outcome is not in the DBIR The DBIR is a strong map of how breaches begin. It is not a recovery readiness score, and it was never meant to be. Whether declining to pay holds up depends on a number the DBIR never collected: the age of your last verified-clean, restorable recovery point for each tier-zero service. Most teams cannot produce that number on demand, because their backup dashboards report job success, not data integrity. Closing that gap means treating recovery as something you can prove, not assume. For each critical service, the useful evidence is concrete: when the most recent recovery point was confirmed free of malware and encryption, who confirmed it, whether a restore was tested against realistic conditions, and how far back an analyst would have to search to find a point written before the intrusion. That last figure depends on detecting compromise inside the backup data itself, off the production trust path, so a compromised environment cannot certify its own copies. Run that evidence forward and the first question in the runbook changes. When nearly half of breaches involve ransomware and the recovery plane is a primary target, “do we have a backup” is the wrong place to start. The question that matches the threat is which recovery point the team can defend as clean, current, and restorable, and who is authorized to act on it. Read the full research behind these numbers Our research report, Ransomware Recovery in 2026, reconciles the 2026 DBIR with Chainalysis, Mandiant, Sophos, ENISA, and four named incident cost breakdowns, then defines the recovery-assurance metrics and maturity model boards can score against. Get the 2026 Report Sources [1] Verizon, 2026 Data Breach Investigations Report, Executive Summary , 2026 [2] Verizon, Vulnerability exploitation is the top breach entry point, 2026 DBIR finds , 2026 [3] Chainalysis, 2026 Crypto Crime Report: Crypto Ransomware , February 2026 [4] Sophos, The State of Ransomware 2025 , June 2025 [5] Sophos, The Impact of Compromised Backups on Ransomware Outcomes , 2024 [6] MITRE ATT&CK, T1490: Inhibit System Recovery

Read post

PCI DSS 4.0, Ransomware, and the Recovery Question It Leaves Open

June 30, 2026

PCI DSS 4.0, Ransomware, and the Recovery Question It Leaves Open

Ransomware lands in the cardholder-data environment. PCI DSS told you to segment it, log it, and protect the stored account data. It did not tell you how to prove you can bring that environment back clean. It is the gap a ransomware event walks straight through. PCI DSS 4.0 is a strong control standard for protecting cardholder data at rest and in transit. It is comparatively quiet on whether you can recover that data after an attack, and quiet in a way that stays invisible until you are mid-incident. What PCI DSS 4.0 does cover The current standard, PCI DSS v4.0.1 , was published in June 2024 as a clarifying revision, and the future-dated requirements from v4.0 became mandatory for all applicable entities on 31 March 2025 . Several of its requirements touch the ransomware lifecycle: Requirement 12.10 mandates an incident response plan that is implemented and tested, so the team has a defined way to respond when the CDE is affected. Requirement 3 protects stored account data through encryption and key management. Requirement 10 logs and monitors access to cardholder data and systems. Requirement 11 requires regular testing of security, including change and tamper detection. These are real controls and they do useful work. They reduce the odds of an intrusion and improve the odds you notice one. Where the standard goes quiet What the standard does not do is require you to prove that the cardholder-data environment can be restored from a recovery point known to be clean. Requirement 12.10 is about responding to an incident. It is not a mandate to validate that your backups of the CDE are free of the attacker before you rely on them. This is not a criticism of the standard’s intent. It is a precise statement of scope. PCI DSS is built to protect cardholder data and keep it out of the wrong hands. Provable recovery of that data after a destructive attack sits at the edge of what it asks for, which leaves the decision, and the risk, with you. Requirement 12.10 does ask you to test the incident response plan, which exercises the response process. It does not require you to attempt a restore and confirm the recovered cardholder-data environment is free of the attacker, which is the test that actually predicts whether recovery works. PCI DSS protects cardholder data. It does not prove you can bring it back clean. The recovery problem is bigger than the assessed CDE PCI DSS lets you shrink the assessment by segmenting the cardholder-data environment away from the rest of the network. That scoping is a sound way to reduce audit burden. It is not a boundary ransomware respects. If an intruder gets a foothold, restoring the CDE often depends on systems that sit outside the assessed scope: directory services, DNS, hypervisors, and the backup infrastructure itself. A clean CDE restore that has nowhere trustworthy to land is still a failed recovery. The recovery question is wider than the boundary the assessment drew. Why the gap bites in a ransomware event Here is where the quiet requirement gets loud. An attacker reaches the CDE and dwells before detonating. Your backups of that environment keep running, and they capture the intrusion along with the data. When you restore, the recovery point you reach for may already contain the attacker’s foothold, the staged tooling, or partially encrypted data. Bringing it back re-introduces that exposure into the environment that holds account data. The result is a fresh cardholder-data problem on top of the outage. Blind vs. evidenced A restore decision made blind versus made with evidence looks like this. Blind: the team picks the newest backup of the CDE, restores it, and hopes the intrusion is not in it. Evidenced: the team picks the newest recovery point that has been inspected and confirmed free of ransomware, restores it, and can show the QSA why that copy was safe. Same backup estate, opposite risk posture. Closing the gap without waiting for the standard You do not have to wait for a future revision to address this. The move is to treat the CDE’s recovery points the way you treat its access: as something to verify, not assume. Inspect the recovery points for the cardholder-data environment for ransomware and unauthorized encryption. Keep a named, most-recent clean copy per critical system. Hold the evidence so it is ready when a QSA, or an actual incident, asks for it. Knowing where that data actually lives is the first move, since cardholder data tends to sprawl beyond the assessed CDE; data classification finds the account data sitting where it should not be. Because cardholder data can live in object storage, securing Amazon S3 data against ransomware is a practical starting point for where that inspection has to reach. Treating CDE recovery points as something to prove rather than assume is the discipline What Is Recovery Assurance? describes. Could you prove your CDE recovery point is clean? Pick the systems inside your CDE and ask one question: could you hand a QSA evidence that the recovery point you would restore is clean? A Recovery Posture Assessment shows you where the gap is before an attacker does. Run a Recovery Posture Assessment Sources [1] PCI Security Standards Council, Now is the Time for Organizations to Adopt the Future-Dated Requirements of PCI DSS v4.x . Future-dated v4.0 requirements mandatory 31 March 2025 [2] PCI Security Standards Council, Document Library (PCI DSS v4.0.1) . Requirements 3, 10, 11, and 12.10; v4.0.1 published 11 June 2024 [3] Elastio, Securing Amazon S3 Data Against Ransomware Attacks [4] Elastio, What Is Recovery Assurance? [5] Elastio, Recovery Posture Assessment [6] Elastio, Data Classification: Sensitive Data as a Threat Finding

Read post

When Ransomware Can Turn Off Your EDR, Your Backups Need Their Own Detection

June 29, 2026

When Ransomware Can Turn Off Your EDR, Your Backups Need Their Own Detection

The ransomware-as-a-service crew known as The Gentlemen ships its affiliates a dedicated toolkit whose only purpose is to switch off endpoint protection before encryption begins. ESET documented the framework, called GentleKiller, in Killing Me Gently: Inside Gentlemen’s EDR Killer Framework . It runs at least eight variants, each abusing a different vulnerable or malicious kernel driver, and together they target more than 400 processes mapped to 48 security products. 8+ variants in the GentleKiller framework, each abusing a different vulnerable or malicious kernel driver 400+ processes the framework targets to terminate or blind protection 48 security products in scope, spanning the major EDR platforms most teams rely on T1562.001 the MITRE ATT&CK technique, Impair Defenses: Disable or Modify Tools, turned into a maintained product That list spans the major endpoint detection and response (EDR) platforms most security teams rely on. Disabling security tools is an old technique. What changed is that doing it is now a maintained product, distributed to vetted affiliates and updated like any other software. Killing EDR is now a product, not a custom job The variants operate at the kernel level, beneath the EDR agent, where they can terminate or blind security software. The common pattern is bring-your-own-vulnerable-driver (BYOVD): load a signed but flawed driver, then borrow its privileges to kill protection. Some variants load malicious drivers outright rather than abuse legitimate ones, and ESET’s indicators of compromise include rootkit components. The operators also adopt newly published EDR-killer proofs-of-concept, including ones tracked as UnknownKiller and PoisonKiller, within days of their public release. The framework is built to look legitimate. Variants impersonate well-known software such as Kaspersky, Valorant, FACEIT Anti-Cheat, Javelin, and WatchDog, carry invalid digital signatures copied from real executables along with matching icons and version strings, and ship under commercial packers (Enigma or Themida) to slow analysis. The Gentlemen also fold in third-party EDR killers rather than build everything themselves: HexKiller previously appeared in Warlock operations and abuses a Baidu Antivirus driver. ThrottleBlood is linked to MedusaLocker and DragonForce and abuses a TechPowerUp driver. HavocKiller was publicly disclosed in March 2026 but in operational use since January, and abuses a Huawei audio driver. A separate Rust-based credential stealer, OxideHarvest, pulls saved passwords from Chromium and Firefox browsers. A May 2026 internal data leak confirmed that GentleKiller is operator-maintained, with leadership discussing how to keep the EDR-killer packages current for affiliates. MITRE catalogs disabling defenses as T1562.001, Impair Defenses: Disable or Modify Tools . The Gentlemen turned that technique into a supported feature. Key Distinction When an attacker can switch the EDR agent off from kernel level, the absence of an alert stops being evidence of anything. A quiet console can mean the environment is clean, or it can mean the sensor was blinded before it could report. What a blinded endpoint does to your recovery ESET’s public analysis focuses on defense evasion, not backup compromise or initial access. The recovery problem is more general than one crew. Most backup hygiene quietly assumes production detection is working: that if malware were present, the EDR agent on the host would have caught it before the data was copied. An EDR killer removes that assumption. Backups run on a schedule. If endpoint sensors are blinded during the window between compromise and detection, a scheduled job can copy the compromised state into a recovery point with no alert attached. The backup succeeds and the dashboard stays green. The copy may still carry the malware, the staged tooling, or the altered data the attacker left behind, and nothing in the production telemetry will say so. A host whose kernel is owned cannot certify its own backups. The detection that still works in that situation is the detection that the attacker’s driver cannot reach. Inspecting the recovery points themselves, off the production host, puts the integrity verdict outside the trust path the EDR killer just compromised. Our recovery-point inspection runs outside production: Elastio inspects supported recovery points for ransomware, insider-threat encryption, and malware, so a clean point is identified by evidence rather than by an alert that may never have fired. Disabling the EDR during the attack also erases the evidence you would use later to decide which backup is safe to restore. "We already run EDR" is the assumption being attacked Endpoint detection is still the front line, and nothing here argues against it. The Gentlemen built GentleKiller precisely because EDR works well enough to be worth disabling. The narrower issue is that a control an affiliate can turn off with a vulnerable driver cannot also be the thing that vouches for your recovery points after the fact. Immutability has the same limit: a locked vault preserves whatever was written to it, including a copy made while the sensors were dark. For the next recovery review, take one tier-zero service and ask a specific question. If the EDR agents on its hosts had been disabled for the two weeks before your most recent backup, what independent evidence would tell you that recovery point is clean? If the only answer is that EDR did not alert, the plan is resting on a control the current ransomware market sells a tool to defeat. See where your recovery stands In a Recovery Posture Assessment, our team inspects your existing backups for ransomware and encryption with you and identifies your last known clean recovery point per critical service, independent of whatever production detection did or did not catch. Book a session and we will show you what your recovery points would reveal. Book My Assessment Sources [1] ESET, Killing me gently: Inside Gentlemen’s EDR killer framework , June 2026 [2] ESET, ESET Research investigates Gentlemen ransomware gang and its defense-evasion tools , June 2026 [3] MITRE ATT&CK, T1562.001: Impair Defenses: Disable or Modify Tools

Read post

Patching Is Not Remediation. CISA Just Made That Federal Policy

June 23, 2026

Patching Is Not Remediation. CISA Just Made That Federal Policy

When your team remediated its last known exploited vulnerability, did anyone prove the system was not already compromised before the patch landed? For most security programs, the honest answer is no. The patch closed the door. Nobody checked whether someone was already inside. That gap was an operational shortcut everyone tolerated. As of June 10, federal policy treats it as unacceptable. What changed CISA issued Binding Operational Directive 26-04, Prioritizing Security Updates Based on Risk . It supersedes BOD 19-02 and BOD 22-01 and rebuilds federal vulnerability management around four risk criteria: whether the asset is publicly exposed, whether the vulnerability is in the Known Exploited Vulnerabilities catalog, whether exploitation can be fully automated, and whether exploitation yields control of the asset. Vulnerabilities meeting the highest-risk criteria must be remediated within three days. CISA’s stated rationale is that adversary use of AI may be compressing the window between patch release and exploitation. The remediation timeline got the headlines. It is not the part that should change how you operate. The requirement that matters For the highest-risk tier, BOD 26-04 pairs the three-day clock with a second mandate: agencies must check whether the affected asset was compromised before the patch was applied. Key Distinction CISA’s reasoning, in its own words : “Applying a patch generally does not evict a threat actor.” It adds that judiciously checking for existing compromise is vital to manage risk. That should be read carefully. The agency responsible for defending federal networks has stated, as policy, that patching is not remediation if the attacker arrived first. Close the vulnerability while the adversary retains access and you have a patched, compromised system. The compliance checkbox is green. The breach is ongoing. The check is not a log review. It is forensic triage: scope the exposure, gather sufficient evidence, analyze it, and produce a record stating who, what, where, and when, with timestamps. It runs inside the same 72-hour window as the patch. And the clock does not start when the team is ready. It starts when the vulnerability is identified. This will not stay federal BOD 26-04 binds federal civilian executive branch agencies. If you run security for an enterprise, it is tempting to file this under government news. The last directive CISA issued in this space argues otherwise. BOD 22-01 created the Known Exploited Vulnerabilities catalog as a federal patching mandate in 2021. Within a year, KEV remediation was the reference standard for enterprise vulnerability management. Auditors asked about it. Cyber insurers underwrote against it. Regulators in financial services cited it in examinations. None of those organizations were bound by the directive. All of them were measured against it. The pattern is set to repeat. The practical question for enterprises in regulated industries is not whether examiners will ask about compromise assessment at patch time. It is when, and whether the answer will hold up. Boards now have a sanctioned question with a federal citation behind it: when we patched, did we prove we were not already compromised? Why the obvious approach fails The instinct is to treat this as more incident-response work: when a KEV notification lands, send responders to investigate the affected asset. That approach fails for two reasons: the workload it creates, and the evidence it can no longer reach. Take the workload first. Forensic triage is skilled work traditionally performed on demand, over days or weeks, on a small number of systems after an incident is declared. The directive demands it at vulnerability-management cadence, per asset, on a 72-hour clock that someone else starts, at whatever volume the KEV catalog produces. The baseline is already failing at the lighter workload. Verizon’s 2026 Data Breach Investigations Report found that only 26 percent of KEV vulnerabilities were fully remediated in 2025, down from 38 percent the prior year. That was the success rate for patching alone. The directive adds an investigation to the same window. No SOC closes that gap by hiring. Then the evidence itself. A triage that begins when the KEV entry publishes is investigating the past with the tools of the present. The real question is not whether the system is compromised right now. It is whether it was compromised at any point during the exposure window, which may stretch back weeks or months before the patch existed. Point-in-time inspection at patch time cannot answer that. The evidence was either captured continuously across the window, or it is gone. On-demand forensics cannot reconstruct a window that has already closed. This is the structural gap in most security architectures. Prevention controls block threats at the perimeter. Detection and response tools watch processes, identities, and network traffic in the present tense. Neither maintains a forensic record of the estate over time. When the directive asks whether an asset was compromised before you patched it, the existing stack has no layer that holds the answer. The shift the directive forces If the evidence cannot be gathered after the fact, it has to already exist when the alert lands. That is the shift the directive forces. Detecting compromise becomes continuous, not something that begins after a notification. A program built that way looks different from the IR model in a specific way, and that difference is what makes it workable at KEV cadence. Call it Active Attack Detection. The aim is to find active attacks and signs of compromise before the encryption that finally makes an attack obvious, so that when a vulnerability lands on the KEV list, the compromise state of the affected systems is already known. Answering CISA’s question becomes a lookup, not a fresh investigation. It works because the analysis is agentless and runs against data the estate already produces, not by stationing responders on every asset. There is nothing to deploy per system and no investigation to staff on the clock, so the continuous record is maintained without the cost and alert volume that made the IR approach fail. It has to cover the whole arc. An attack is not one event. It runs from persistence to lateral movement to exfiltration to encryption, and finally to the recovery you would count on afterward. Compromise has to be detected across all of it, in both the systems and the data, or the answer to whether you were already breached has a hole in it. The same goes for recovery, and it is becoming urgent. Mandiant’s M-Trends 2026 found attackers going after the very systems companies use to recover after a breach, a pattern it calls recovery denial. Restore from a backup that still carries the attacker and you are back where you started, which is why the same continuous record has to prove the recovery point is clean before you rely on it. The defensible position The directive reduces to one question a security leader should be able to answer before being asked: for any asset we patched this quarter, can we prove it was not already compromised, and can we prove what we would recover from is clean? A program that can produce that proof, continuously, is ahead of where federal policy just moved and ahead of where enterprise expectations are heading. A program that cannot has a documented gap that a federal directive now describes. Compromise assessment is moving from something you do after an incident to something you run continuously. The programs that treat it that way now will not be the ones scrambling when the question arrives with a citation behind it. Prove it before you’re asked Elastio continuously determines whether your systems and data have been compromised, so the answer is proven before you patch. Assess your recovery posture Sources [1] CISA, BOD 26-04: Prioritizing Security Updates Based on Risk , June 10, 2026 [2] CISA, CISA Issues New Directive Improving How Federal Agencies Prioritize the Mitigation of Cyber Vulnerabilities (issuing announcement), June 10, 2026 [3] CISA, BOD 22-01: Reducing the Significant Risk of Known Exploited Vulnerabilities , November 3, 2021 [4] CISA, Known Exploited Vulnerabilities Catalog [5] Verizon, 2026 Data Breach Investigations Report , 2026 [6] Mandiant (Google Cloud), M-Trends 2026 , 2026

Read post

Elastio Data Classification: Sensitive Data Findings

June 22, 2026

Elastio Data Classification: Sensitive Data Findings

If an attacker reached one of your protected assets today, could you state what regulated data sat on it? Per asset, per file, with evidence? Most security teams cannot answer that question. Not because they lack tools, but because the tools watch the wrong places. Regulated data drifts into export directories, archives, file shares, and the data the platform protects. No control in the security stack inspects those locations for content. That is where exposure accumulates, and that is where attackers go. What shipped Elastio now ships Data Classification as a hunt type in the platform. The Data Classification hunt inspects assets in policy scope and raises a Threat finding when selected data types are found out of place. The finding lands in the same queue as ransomware, malware, and encryption findings, with severity, status, and ownership. The team selects, per policy, which classes are treated as out of place on which assets: Class Detects PII National identifiers, SSN, TIN, dates of birth, passport numbers, driver’s licenses PCI PAN, CVV, track data, cardholder names PHI / HIPAA MRN, ICD and CPT codes, diagnosis notes, NPI GDPR EU resident PII, behavioral profiles, IP addresses Secrets and credentials API keys, OAuth tokens, private certificates, cloud credentials, .env files Each finding carries file-level evidence: the affected files with paths, sizes, timestamps, and the specific match signals per file. The evidence is exportable as a sensitive files report, ready for the data owner, the auditor, or the regulator. Auditable by Design Suppressing a classification finding requires an explicit reviewed acknowledgment. Every disposition is recorded. No silent dismissals. Why this is a security control, not an inventory Data discovery tools produce inventories. Inventories get filed. Elastio treats out-of-place sensitive data as a threat, because operationally it is one. Credentials in protected data API keys, tokens, and certificates sitting in archives are re-entry material for an attacker. They deserve the same triage urgency as malware. Cardholder data in an exports directory An exfiltration target waiting to be found, and a compliance finding waiting to be written. Health records outside their system of record Exposure no one signed off on, now visible with file-level evidence instead of discovered during an incident. Where it fits in Active Cyber Resilience Detection answers whether the data is clean. Classification answers what is inside it. Together they change what you can say after an incident. When a recovery point is compromised, the platform can state what regulated data sat inside it. The incident becomes a quantified exposure statement instead of an open question in front of the board, the regulator, and the insurer. Classification runs inside the Hunt pipeline that already inspects your data estate. One policy setting. No new tool to deploy, integrate, or defend. An incident becomes a quantified exposure statement instead of an open question. What to do Enable the Data Classification hunt on the policies covering your highest-exposure assets. Select the data classes that do not belong on those assets. Route the first round of findings to the data owners and set the suppression discipline early. The configuration takes minutes. The answer it gives you is the one you have not had. Assess Your Recovery Posture Find out what sensitive data sits in your protected estate and whether your recovery is provable. Get Started

Read post

The SEC Clock Starts When You Decide The Incident Is Material. Can You Make That Call?

June 18, 2026

The SEC Clock Starts When You Decide The Incident Is Material. Can You Make That Call?

The four-business-day disclosure clock does not start when you discover a cyber incident. It starts when you determine the incident is material to investors. Most teams assume the deadline runs from detection and brace for a four-day sprint. The harder problem is the determination that starts the clock. You cannot soundly judge materiality until you can bound what the incident did to the business, and a large part of that is a recovery question: which systems you can bring back, how fast, and on data clean enough to trust. What the rules require, briefly The SEC adopted its cybersecurity disclosure rules in July 2023 under Release No. 33-11216 . Two pieces matter here. Form 8-K Item 1.05 requires a registrant to disclose a material cybersecurity incident within four business days of determining that it is material, describing the material aspects of the nature, scope, and timing of the incident and its material impact. A narrow exception exists when the U.S. Attorney General determines that disclosure poses a substantial risk to national security or public safety. The requirement has applied since December 2023, with smaller reporting companies given until June 2024 to begin filing under Item 1.05. Regulation S-K Item 106 requires annual disclosure in the 10-K of the processes for assessing, identifying, and managing material cyber risks, the material effects of cyber threats and prior incidents, and the board’s oversight of those risks. Those annual disclosures applied beginning with fiscal years ending on or after December 15, 2023. Materiality is a recovery question in disguise The rule does not let you stall. The materiality determination has to be made without unreasonable delay after discovery, so the pressure lands on the investigation, not on a calendar you control. Walk the determination. To decide whether a reasonable investor would care, you have to bound the impact: which systems are affected, how long they will be down, whether data was altered or destroyed, and whether operations resume on data you can trust. Several of those inputs are recovery facts before they are anything else. Scenario Take a public manufacturer that detects encryption across part of its ERP estate on a Friday. Here the materiality call turns largely on a recovery fact. If a clean recovery point from Thursday night restores the ERP by Monday, the impact may be contained. If the newest clean point is three weeks old because the intrusion predates the visible encryption, the company is facing extended downtime and a material hit to results, and the legal team cannot tell those two cases apart without recovery evidence. A team that cannot identify its last clean recovery point cannot honestly bound the recovery impact. It is left choosing between two bad options: disclose early on incomplete information, or wait while it tests restores and risks an unreasonable delay. The provable clean recovery point is the input that lets legal and the CISO put a defensible bound on that side of the impact, one of the larger unknowns in the early hours. The four-business-day clock, step by step: You discover an incident. You investigate scope: what was accessed, what was changed, what you can recover. You make the materiality determination, without unreasonable delay. This is the gating step. The four-business-day clock starts here, at the determination. You file the 8-K describing the material nature, scope, timing, and impact. Step three is where recovery evidence shapes whether the next four days are a controlled disclosure or a scramble. The clock starts at the materiality call, and you cannot make that call without recovery evidence. Related events count as one incident The rule does not let an attacker’s campaign be sliced into immaterial pieces. The SEC defines a cybersecurity incident to include a series of related unauthorized occurrences, so several smaller events that turn out to be related must be assessed together for materiality. Whether events are related is, again, a scoping and recovery question. If you cannot see how far the intrusion reached and which recovery points it touched, you cannot tell whether last month’s anomaly and today’s encryption are one incident or two. Understating that scope is how a disclosure becomes a misstatement after the fact. The annual disclosure invites the same question Item 106 is the slower-burning exposure. It asks you to describe, in writing and on the record, how you assess and manage material cyber risk and how the board oversees it. A recovery program you cannot evidence produces vague Item 106 language. Vague language is fine until an incident, at which point the disclosure is read against what actually happened, and a gap between the two is the kind of thing that draws scrutiny. RPO Is Not Enough for Ransomware Recovery covers why backup metrics are not the recovery evidence this disclosure implies. What legal should be able to ask the CISO now The time to build this is before the clock starts. A general counsel preparing for Item 1.05 should be able to get a fast answer to a short list: Which Tier 0 and Tier 1 services have a current recovery point with clean-copy evidence? For those services, how far back is that clean point? Who is authorized to approve return to production, and what evidence do they sign against? Can we produce a timestamped record of the recovery decision after the fact? If those answers take days to assemble, the materiality determination will too. Building that answer ahead of time is what the security-leader page is about: measuring the gap to the last proven clean recovery point so legal opens the materiality conversation with evidence, not a status meeting. Build the evidence before you need it Map your Tier 0 services to a current clean recovery point with a Recovery Posture Assessment, so the recovery facts behind the materiality call are ready when the clock starts, not assembled under it. Run a Recovery Posture Assessment Sources [1] U.S. Securities and Exchange Commission, SEC Adopts Rules on Cybersecurity Risk Management, Strategy, Governance, and Incident Disclosure by Public Companies , press release 2023-139, July 26, 2023 [2] U.S. Securities and Exchange Commission, Cybersecurity Risk Management, Strategy, Governance, and Incident Disclosure, Small Entity Compliance Guide . Implements the final rules adopted July 26, 2023 (Release No. 33-11216; effective September 5, 2023) [3] Elastio, Ransomware Recovery Starts With a Provable Clean Recovery Point [4] Elastio, RPO Is Not Enough for Ransomware Recovery [5] Elastio, Active Cyber Resilience for Security Leaders

Read post

Podcast

Detonation Point

Conversations with investigators, CISOs, and researchers on the front lines of cybercrime.

All episodes

Webinars

Recent webinars

On-demand and upcoming sessions on ransomware resilience, AWS, and recovery assurance.

Webinars & events

Solution briefs

Architecture deep dives

Technical briefs on how Elastio integrates with AWS Backup, Veeam, and other platforms to deliver provable ransomware recovery.

All solution briefs