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
Annual DR Testing vs Continuous Recovery Validation: Why One Test a Year Is Not Enough

August 6, 2026

Annual DR Testing vs Continuous Recovery Validation: Why One Test a Year Is Not Enough

Your last DR test passed. The team picked a date, chose a backup, spun up the workloads in a recovery account, hit the RTO target, and signed the report. That report is true, and it is narrow. It proves that on the day you tested, one recovery point restored and came up. It does not prove that the recovery point you would reach for during an actual ransomware incident is free of ransomware today, or that it would restore at all. That gap is the difference between annual DR testing and continuous recovery validation. An annual test is a snapshot of a single restore path on a single date. Ransomware does not wait for the test window, and it does not respect the recovery point you happened to validate last quarter. What an annual DR test actually proves A traditional DR test answers a mechanical question: if we restore this backup, does the system come back within the recovery time objective? That is worth knowing. It exercises the runbook, the IAM roles, the network cutover, and the people who run them. AWS built this pattern into the platform. AWS Backup restore testing runs restore jobs on a scheduled cadence, monitors how long each restore takes, and lets you audit whether restores meet your target time. It restores a recovery point, confirms the restore completes, and then deletes the restored resource. That is a real control, and a scheduled restore test contributes to what regulators ask for. DORA (Regulation (EU) 2022/2554) sets digital operational resilience testing and ICT risk-management obligations that run wider than any single annual restore: a full testing programme, backup and recovery procedures, and periodic assessment of ICT systems supporting critical or important functions. An annual DR test is one input to that programme, not the whole of it. The mechanical question and the integrity question are not the same question. A restore that completes on time still tells you nothing about whether the data inside that recovery point was already encrypted, corrupted, or carrying malware when the backup was written. The three assumptions an annual test bakes in Every annual DR test carries three assumptions that hold on test day and quietly expire afterward. The date is fixed. You validated a restore on, say, March 12. An attacker who detonates on March 10 does not get the March 12 backup. They get whatever recovery points exist in August, none of which your test touched. The recovery point is chosen. Restore testing selects the latest eligible recovery point or a random one from a defined window. During a real incident you do not get to choose a known-good backup. You have to find one, under pressure, from a set that may all be contaminated. The failure mode is operational, not adversarial. DR planning grew up around hardware failure, power loss, and site outages. In those events, the data in the backup is assumed clean. Ransomware breaks that assumption. The threat is inside the recovery point. NIST names this directly. NIST SP 800-184 , the Guide for Cybersecurity Event Recovery, treats validating recovery capabilities as an ongoing discipline, not a one-time checkbox. Section 3.1 states that “exercises and tests should be performed periodically” to build real-world recovery capability. Periodic is the operative word, and it points in the same direction as continuous. NIST does not set a fixed cadence here; the annual floor that many teams actually run to comes from regulatory regimes, not from NIST. DORA (Regulation (EU) 2022/2554) and sector rules oblige regular resilience testing, and an annual test is a common way to meet that bar. But even a test that clears the regulatory minimum still validates one date; it does not track the state of a live environment where new backups are written every day. Continuous validation asks a different question every day Continuous recovery validation inverts the model. Instead of proving one restore path worked on one date, it inspects the configured recovery points on supported sources as they are written and asks whether the data inside shows signs of ransomware encryption, malware, or corruption. Elastio runs this inspection continuously and out-of-band. The Hunt Engine performs Deep File Inspection on backup data, checking for ransomware encryption, malware, and corruption without touching production systems and without agents on the protected workloads. Because it inspects configured recovery points rather than a sampled one, it can name the last-known clean recovery point across the estate it covers, including points a scheduled test would never select. Continuous does not mean instantaneous or all-seeing. There is scan latency between a backup completing and a verdict being available, so the most recent recovery point may not yet be inspected. The finding also covers only what is inspected: the data inside the recovery points and resource types in scope, reporting that no supported indicators of ransomware, malware, or corruption were detected. That is a strong signal about the data, and it is not the same as proving the workload will restore and run, which is what isolated restore testing establishes. A state Department of Public Health running on AWS described the before state plainly: the lack of verified backups meant every incident carried the risk of downtime and reintroducing threats. Their security manager compared ransomware recovery to walking a tightrope, then replaced that guesswork with continuous verification that identifies the last-known clean recovery point and when the infection started. The shift was not from slow recovery to fast recovery. It was from guessing which backup was safe to knowing. The failure mode a passing test hides Here is the scenario an annual test does not catch. Ransomware operators frequently sit in an environment for weeks before they encrypt anything, using that dwell time to disable defenses, exfiltrate data, and spread. During that window, every backup you take is a backup of a compromised environment. The malware is dormant in the data, not yet detonated. Your DR test in that window passes. The restore completes, the RTO is met, the report is green. What the test cannot see is that the recovery point it validated already contains the attacker. Restore it after detonation and you reinstall the intrusion. The timing is what defeats the annual model: the test proves a restore path on the day the calendar picked, while the recovery point that carries the infection is written on some other day the calendar never checks. A test that only measures whether the restore mechanism works will never surface that. Key Distinction This is also where “immutable” gets misread. An immutable backup cannot be altered after it is written. That protects the copy from tampering. It does nothing to prove the data was clean at the moment it was written. Immutability plus an annual restore test can produce a perfectly preserved, perfectly restorable copy of an infected system. The real axis is cadence and coverage The annual model optimizes for one recovery point, one date, one clean path. The real problem is coverage across the whole estate over time. Coverage means every workload, not the handful chosen for the test. It means every recovery point, not the latest one in a window. It means AWS Backup, EBS and RDS snapshots, DRS replicas, S3, and EFS, all inspected on the same basis, so a clean point in one data source does not create false confidence about another. JetSweep, working with a sports-equipment manufacturer on AWS, layered continuous Deep File Inspection onto AWS Elastic Disaster Recovery and AWS Backup so that every recovery point is inspected automatically, not sampled on a schedule. The disaster recovery setup already handled replication and failover. What it could not do on its own was check whether the replicated data carried hidden encryption or corruption. None of this replaces the annual test. Keep it. Exercise the people, the runbook, and the RTO. Meet the regulatory cadence. Continuous validation runs underneath it and narrows the question the annual test structurally cannot: which recovery points show no supported indicators of compromise, so the candidate you take into an isolated restore test is a clean starting point rather than a guess. This is a different axis from your RPO. RPO tells you how much data you could lose measured in time; it says nothing about whether the recovery point at that boundary is clean. Why RPO is not enough for ransomware recovery works through that distinction. Cadence and coverage of validation are the missing dimension, and an annual test does not measure either. What to change before your next test cycle If your DR program still runs on an annual proof point, the smallest useful change is to stop treating the passing test as evidence that a clean recovery point exists today. It is evidence that one restore path worked on one date. Add continuous integrity inspection so that on the day you are actually attacked, finding the last-known clean recovery point is a lookup, not a gamble. See what a continuous view of your recovery points would show Run our recovery assessment against your existing backup estate and find out which recovery points show no supported indicators of compromise. Request an Assessment Sources [1] Amazon Web Services, Restore testing , AWS Backup Developer Guide [2] NIST, SP 800-184: Guide for Cybersecurity Event Recovery , Bartock, Cichonski, Souppaya, Smith, Witte, and Scarfone, 2016 [3] European Parliament and Council, Regulation (EU) 2022/2554 (DORA) on digital operational resilience for the financial sector , 2022 [4] Elastio, Proving backup integrity for public health on AWS [5] Elastio, Proving AWS recovery readiness with JetSweep [6] Elastio, RPO is not enough for ransomware recovery

Read post →

July 29, 2026

EDR, SIEM, CNAPP, and Immutable Backups: The Ransomware Recovery Gap They Leave

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 →

What Is Ransomware Recovery Attestation? An Elastio Framework for Documenting a Clean Restore Point

July 20, 2026

What Is Ransomware Recovery Attestation? An Elastio Framework for Documenting a Clean Restore Point

The question that ends most board cyber briefings is not “Do we have backups?” It is “How do you know you can actually recover?” The honest answer from most security teams is a backup success rate and a last DR test date. Neither one proves that the recovery point you would restore from today is free of ransomware. Recovery attestation closes that gap. A recovery attestation is documented proof that a specific recovery point passed content-integrity inspection with no supported indicators of ransomware detected, tied to an asset and a timestamp, and that its candidate clean point was confirmed by isolated restore testing. It is the evidence a CISO can put in front of a board, an audit committee, a regulator, or an insurer without reconstructing anything under deadline. Definition A recovery attestation is documented proof that a specific recovery point passed content-integrity inspection with no supported indicators of ransomware detected, tied to an asset and a timestamp, and that its candidate clean point was confirmed by isolated restore testing. This is an Elastio framework, not settled industry terminology. Regulators require you to test recovery and validate the integrity of restored data. They do not use the phrase “recovery attestation,” and no standards body has ratified it as a defined term. We use it because the market lacks a clean name for the artifact that answers the board’s real question, and because the artifact is what our platform produces after every hunt cycle. Attestation is the evidence artifact, not the capability Recovery assurance and recovery attestation are related but distinct. Our recovery assurance work is the operational capability: continuous content-integrity inspection of recovery points across live data, replicated data, and backups, paired with isolated restore testing of the candidate clean point. Recovery attestation is the artifact that capability produces. Assurance is the machine. Attestation is the receipt. A capability with no artifact cannot survive an audit. A team can run continuous validation and still fail a DORA resilience review or an insurance renewal if it has no dated, asset-level record it can hand over. Attestation is what turns an internal control into external evidence. What a recovery attestation actually contains Treat an attestation as a compliance object, not a marketing claim. To be usable as board or audit evidence, it needs concrete fields: Asset identity. The specific system, volume, database, or workload the recovery point belongs to, not a vault name. Recovery point and timestamp. Which point in time was inspected, and when the inspection ran. Verdict. Clean or compromised, with the finding detail if compromised. Method. How the verdict was reached. In Elastio’s case, Deep File Inspection by the Hunt Engine, which opens and inspects inside each file rather than reading metadata, entropy scores, or backup job status. Clean boundary. The dividing line in time between recovery points that are verified clean and those that are not, so recovery decisions have a floor. Chain of evidence. A retained log a third party can review, so the attestation is auditable after the fact. A backup success report has none of these except a timestamp. It confirms a copy completed. It says nothing about whether the data inside that copy was already encrypted or carrying a dormant payload when the job ran. Why “the backup succeeded” is not attestation The failure mode plays out the same way in most incidents. The backup jobs are green. The storage is immutable. Then the team restores a recovery point and reintroduces the same ransomware that caused the outage, because the malware was already present when that point was written. Immutability protected the copy from deletion. It never proved the contents were clean. A green job status and an object-lock flag are two facts about the copy. Neither is a verdict on the data, and a board asking whether you can recover is asking for the verdict. An attestation is worth the most when it exists before you need it. A regulated auto insurance firm running Veeam had Elastio inspecting its backups every day , so the dated clean-or-compromised record for each recovery point already existed when a compromised document surfaced inside a backup. The firm did not have to reconstruct evidence under deadline; the attestation was a standing artifact, refreshed each cycle, rather than a report someone assembles after the audit committee asks. That is the operational shape of attestation: a running record the audit request reads, already written before the request arrives. Where the evidence is actually used Recovery attestation is not a compliance requirement by name. It is the artifact that satisfies recovery-integrity expectations that already exist in the primary texts. NIST SP 800-184, Guide for Cybersecurity Event Recovery (Bartock et al., December 2016), frames recovery as a process that must be planned, tested, and improved, with recovery decisions grounded in verified system and data state rather than assumption. An attestation is the record of that verification for a given recovery point. For EU financial entities, DORA Article 12 (Regulation (EU) 2022/2554) requires documented backup and restoration procedures, ICT systems that are physically and logically segregated from the source, and data-integrity checks during recovery, including multiple checks and reconciliations. A dated, asset-level clean-or-compromised record helps satisfy that obligation by supplying evidence those checks ran, where a written procedure only shows they were planned. Under NYDFS 23 NYCRR 500 , covered entities must maintain recovery capability and, under Section 500.17, provide an annual certification of compliance. A continuous evidence log of recovery-point integrity supports that certification without reconstructing it from memory the week before it is due. The SEC cybersecurity disclosure rules (Release Nos. 33-11216; 34-97989, adopted July 26, 2023) require disclosure of a material cybersecurity incident on Form 8-K within four business days of a materiality determination, plus periodic disclosure of risk-management processes under Regulation S-K Item 106. The rules do not require recovery attestation. Attestation data may support the Item 106 risk-management disclosure by documenting the recovery-integrity process, and it can help scope impact for the incident timeline. For healthcare, HIPAA’s contingency plan standard at 45 CFR 164.308(a)(7) requires a data backup plan, a disaster recovery plan, and procedures for periodic testing and revision. It does not name content inspection. Attestation records can be used to demonstrate the testing and integrity work behind that standard on an ongoing basis, not once a year. None of these rules names recovery attestation as a requirement. Each one obliges you to plan, test, or disclose recovery-integrity work, and a dated attestation is evidence that the work happened. From attestation to a board pack The board does not need the raw log. It needs a short, defensible summary drawn from it. A recovery attestation reduces to a handful of numbers a director can act on: Percentage of critical assets under continuous inspection. Age of the last-known clean recovery point for the most critical systems. Number of active threats found in recovery data this period. The clean boundary for the systems that would carry the business through an outage. Those numbers replace the two answers boards usually get, backup success rate and last test date, with a statement about whether the organization can recover to a clean state today. That is a materially different claim, and it is one the CISO can defend under questioning because it traces back to dated, asset-level evidence rather than a plan on a shelf. The gap most teams discover here is that they have the capability conversation but not the artifact. They can describe continuous validation. They cannot produce a recovery point, a timestamp, and a verdict when the audit committee asks for one specific system. If you want to see what that evidence looks like against your own environment, our Recovery Assessment runs against an existing backup estate and returns the last-known clean recovery point per service and where the gaps are. Bring the output to your next board or audit meeting and answer the recovery question with a document instead of a promise. See your last-known clean recovery point Our Recovery Assessment runs against your existing backup estate and returns the last verified-clean recovery point per service, plus where the gaps are. Bring the output to your next board or audit meeting. Run a Recovery Assessment Sources [1] NIST, SP 800-184: Guide for Cybersecurity Event Recovery , Bartock, Cichonski, Souppaya, Smith, Witte, Scarfone, December 2016 [2] European Union, Regulation (EU) 2022/2554 (DORA), Article 12: Backup policies and procedures, restoration and recovery procedures and methods , 2022 [3] New York State Department of Financial Services, 23 NYCRR Part 500: Cybersecurity Requirements for Financial Services Companies [4] U.S. Securities and Exchange Commission, Cybersecurity Risk Management, Strategy, Governance, and Incident Disclosure: Small Entity Compliance Guide , 2023 [5] U.S. Department of Health and Human Services, 45 CFR 164.308: Administrative safeguards (HIPAA Security Rule) [6] Elastio, How an auto insurance firm proved backup integrity before an attack

Read post →

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 →

Events

In-person & virtual

Workshops and leadership panels — register or watch on demand where available.

All events

Podcast

Detonation Point

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

All episodes
From Federal Cybercrime Prosecutor to Big Tech Security Leader

August 17, 2026

From Federal Cybercrime Prosecutor to Big Tech Security Leader

with Joe Sullivan

Joe Sullivan, a federal cybercrime prosecutor for nearly eight years before leading security at eBay, PayPal, Facebook, Uber, and Cloudflare, traces the evolution of cybercrime from the earliest electronic-crime investigations to the challenges facing Big Tech today — covering post-9/11 investigations, the Patriot Act, international cases, and what changes when you move from prosecuting attackers to defending against them.

Listen on Spotify →

SIM Swapping: How to Protect Your Digital Identity

August 4, 2026

SIM Swapping: How to Protect Your Digital Identity

with Mark Kreitzman, Efani

Mark Kreitzman, General Manager and co-founder of Efani, became a SIM swapping victim despite two decades building cybersecurity companies — and turned that into a mission. He explains how the attack works, why your mobile number has become the master key to your digital identity, how attackers use social engineering to bypass traditional security, and the practical steps anyone can take to protect themselves.

Listen on Spotify →

Beyond the Badge: Leadership, Cyber & the Next Mission

July 28, 2026

Beyond the Badge: Leadership, Cyber & the Next Mission

with Ray Shuler, 5OH Consulting

Ray Shuler, former Assistant Director for Cyber and Operational Technology at Homeland Security Investigations and partner at 5OH Consulting, traces his path from local law enforcement to leading HSI's cyber programs over three decades — covering cyber-enabled crime investigations, protecting investigators in child exploitation cases, integrating AI into modern investigations, and mentoring the next generation of federal agents through the government-to-private-sector transition.

Listen on Spotify →

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

Case studies

Customer stories

How enterprises prove recovery readiness and close the data integrity gap with Elastio.

All case studies

Whitepapers

Latest whitepapers

Research, maturity models, and frameworks for boards and risk leaders on provable ransomware recovery.

View all whitepapers