Resources

Insights, events, and proof from the field

Latest blogs, 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
Project Glasswing: What Zero-Day Discovery at Scale Means for Your Data

April 13, 2026

Project Glasswing: What Zero-Day Discovery at Scale Means for Your Data

What Anthropic Announced On April 7, 2026, Anthropic announced Project Glasswing , a restricted cybersecurity initiative built around Claude Mythos Preview, their most advanced AI model. The model is not publicly available. Access is restricted to a coalition of launch partners and roughly 40 organizations that build or maintain critical infrastructure software. The launch partners include AWS, Apple, Microsoft, Google, CrowdStrike, Palo Alto Networks, Cisco, Broadcom, JPMorganChase, and the Linux Foundation. Anthropic committed $100M in usage credits and $4M in direct donations to open-source security organizations. 1000s Zero-day vulnerabilities found 52+ Organizations with access $100M Usage credits committed Mythos Preview has already identified thousands of previously unknown zero-day vulnerabilities across every major operating system and every major web browser. In one case, a researcher using the model found a bug in OpenBSD that had been present for 27 years. The model chains multiple vulnerabilities together into exploits that no single flaw would enable on its own. Anthropic warned senior U.S. government officials that the model makes large-scale cyberattacks significantly more likely this year. According to reporting by Fortune and CNBC , Anthropic has privately communicated to officials that this class of model capability will proliferate beyond actors committed to deploying it safely. Why This Changes the Threat Landscape Glasswing is a signal that AI has shifted the economics of attack. Cheap models, open weights, and commodity compute mean adversaries can now generate novel malware variants, automate lateral movement, and compress dwell times from months to weeks. No signature database stays current against this velocity of change. AI has collapsed the cost of discovering and exploiting vulnerabilities. The zero-day supply is about to expand dramatically. Every product in the current enterprise security stack relies on one of two things: behavioral signals from a running system, or a known indicator such as a file hash or malware signature. AI-generated, zero-day attacks defeat both. There is no hash to match. There is no behavior pattern in any database. The attacker's tooling has never been seen before. Key Distinction Zero-days are vulnerabilities, not malware. A zero-day is a flaw in software that the developer does not know about. What follows a zero-day exploit is malware, lateral movement, data staging, and ransomware. Those post-exploitation artifacts land in the data layer. That is where the damage is done, and that is where detection must happen. The Gap No Security Stack Covers Enterprise security stacks protect the perimeter, endpoints, identity, and network. None of them inspect the data itself. This is not a configuration problem. It is a structural gap in the architecture of enterprise security. Security Layer What It Inspects What It Misses Perimeter (Firewall, WAF) Inbound/outbound traffic Threats already inside Endpoint (EDR, XDR) Running processes on live servers Threats in snapshots and backups Identity (IAM, PAM) Access and privilege Malware in data at rest Network (NDR, SIEM) Traffic patterns and logs Ransomware in the data layer Backup (Rubrik, Veeam, Cohesity) Known malware hashes in own backups Zero-days. Data they do not manage. Data Layer (Elastio) Every file across live, replicated, and backup data -- The attacker exploits a zero-day to get in. Once inside, they deploy ransomware, stage data for exfiltration, and encrypt files. Every one of those post-exploitation actions writes artifacts into the data layer. EDR does not see them there. SIEM does not log them. Backup vendors copy the data without verifying whether it is clean. If your security stack does not inspect the data itself, how do you know whether your backups are already compromised? How Elastio Addresses This Gap Elastio performs Deep File Inspection across live data, replicated data, and backup data. It inspects the actual content of every file in the data layer to find ransomware and malware that has already landed. It does not rely on signatures, known hashes, or behavioral inference. Inspects the data, not the perimeter Elastio hunts inside the data layer where ransomware persists and where recovery is determined. No other security control reaches this surface. Finds zero-day ransomware Deep File Inspection does not need a known indicator. It examines file content directly. It finds threats that have never been cataloged. Works across any data surface Live data, replicated data, and backups. Any storage platform. Any backup vendor. One inspection engine across the full estate. Identifies the last clean recovery point When ransomware is found, Elastio traces backward to identify the last recovery point that is provably clean. No guessing. No manual inspection under incident pressure. How It Works Deep File Inspection examines the actual content of every file. It does not infer from entropy changes or statistical anomalies. One inspects. One infers. The detection accuracy profiles are fundamentally different. Why Glasswing Accelerates the Need for Data-Layer Inspection The Glasswing relevance is not about the vulnerabilities themselves. It is about volume. When AI compresses the cost of discovering and exploiting zero-days, more enterprises will be dealing with post-exploitation activity that their current stack does not inspect. Every security tool in the stack will continue to do its job at the perimeter, endpoint, and network layers. But the volume of novel threats reaching the data layer will increase. The question shifts from “Can we block the attack?” to “Can we find what it left behind and prove we can recover clean?” That is the question Elastio exists to answer. The Hunt Engine inspects the data layer today, across live data, replicated data, and backups. As the zero-day supply expands, every enterprise will need a security control that operates where the attacker's work ultimately lands: inside the data. The security stack protects the perimeter, endpoints, identity, and network. None of it inspects the data. That gap is about to be tested at a scale the industry has not dealt with before. Sources [1] Anthropic, Project Glasswing: Securing critical software for the AI era , April 7, 2026 [2] Fortune, Anthropic is giving some firms early access to Claude Mythos , April 7, 2026 [3] CNBC, Anthropic limits Mythos AI rollout over fears hackers could use model for cyberattacks , April 7, 2026 [4] CyberScoop, Tech giants launch AI-powered Project Glasswing , April 7, 2026 [5] Simon Willison, Anthropic's Project Glasswing , April 7, 2026 See How Elastio Detects This Find out whether your data layer is inspected and your recovery is provable. See the Hunt Engine

Elastio Delivers Zero-Day Ransomware Detection and Provable Recovery for IBM Cloud Object Storage

April 8, 2026

Elastio Delivers Zero-Day Ransomware Detection and Provable Recovery for IBM Cloud Object Storage

Which objects are compromised. Which are clean. Where recovery starts. Elastio answers all three. Summary Object storage is not built to inspect what is written to it. Ransomware and insider threats can exploit that gap deliberately, moving slowly over days or weeks to avoid detection thresholds. By the time an incident surfaces, the scope of compromise is often unknown and recovery cannot start. As enterprises face increasing threats, Elastio announced support for IBM Cloud Object Storage (IBM COS), designed to deliver ransomware detection and provable recovery for the object storage environments enterprises use for financial records, healthcare archives, and AI training data. What Elastio Delivers for IBM COS Elastio uses Deep Object Inspection to examine stored objects directly. When a threat is detected, four outcomes follow: Immediate threat context. Compromised objects are tagged with detection type, timestamp, and severity, surfaced in the Elastio portal and forwarded to your SIEM. Responders know the scope from the first alert. A provable recovery point. Elastio identifies the Last Known Clean (LNC) state by scanning backward through prior object versions. The recovery point is verified, timestamped, and auditable before the restore begins. Controlled recovery. Restores execute manually via console or automatically via policy, from the same platform that made the detection. Forensic isolation (upcoming). Compromised objects will be quarantined to a separate bucket outside the original permission boundary, enabling analysis without operational disruption. "IBM Cloud Object Storage holds the data enterprises rely on most. With Elastio, security teams can identify exactly which objects are clean, establish a verified recovery point, and restore with confidence." - Najaf Husain, CEO, Elastio Availability Elastio is available now as a tile in the IBM Cloud Catalog. No changes to storage architecture or application workflows are required. Contact ibm@elastio.com for a product briefing or proof-of-concept engagement. About Elastio Elastio delivers ransomware detection and provable recovery for cloud environments. Its platform inspects live data, replicated data, and backups for zero-day ransomware, insider threats, and malware, and identifies a verified recovery point before a restore begins. Elastio serves enterprise and regulated-industry customers who require security controls that extend into the data layer.

DORA: What CISOs Must Prove About Recovery in 2026

April 1, 2026

DORA: What CISOs Must Prove About Recovery in 2026

Summary The EU's Digital Operational Resilience Act (DORA) became enforceable on January 17, 2025. It requires all in-scope financial entities to test backup and recovery procedures under cyberattack scenarios at least yearly, prove data integrity on recovery, and submit results to regulators. The ECB's 2024 cyber resilience stress test of 109 banks found gaps in recovery capabilities. Penalty regimes vary by member state, with some jurisdictions imposing fines up to 2% of global annual turnover and personal liability for senior management. DORA applies extraterritorially to EU subsidiaries of global banks and to critical ICT providers regardless of domicile. Your Regulator Will Ask for Proof of Clean Recovery The EU's Digital Operational Resilience Act ( Regulation (EU) 2022/2554 ) became enforceable on January 17, 2025. It applies to banks, insurers, investment firms, payment providers, crypto-asset service providers, and 15 other categories of financial entities operating in the EU. It also applies to their critical ICT third-party service providers, regardless of where those providers are headquartered. This is not a future obligation. Enforcement is active. The European Supervisory Authorities (ESAs) have designated critical third-party ICT providers and regulators across member states are conducting oversight. In March 2025, the European Commission opened infringement procedures against 13 member states for failing to fully transpose the accompanying directive. For CISOs at global financial institutions, DORA creates a specific, testable obligation: prove that your recovery works. Not in a slide deck. In a documented test, under a cyberattack scenario, with results submitted to your regulator. If your board asks whether the organization is DORA-compliant, the answer depends on one question: can you prove that your backups are clean and your recovery procedures work under a cyberattack scenario? Articles 11 and 12 require exactly that. Why DORA is Different Financial services is not short on regulation. CISOs in this sector already manage obligations under NYDFS Part 500, PCI-DSS, NIST CSF, and a patchwork of national supervisory frameworks. DORA is different for three reasons. First, DORA is a regulation, not a directive. It applies directly in all 27 EU member states without requiring national transposition of its core requirements. This means uniform rules, uniform enforcement, and no ability for individual countries to weaken the standard. (The accompanying Directive 2022/2556 amends existing sectoral legislation to align with DORA, which is why some member states received infringement notices for transposition delays.) Second, DORA explicitly mandates cyberattack scenarios in resilience testing. Article 11(6) requires financial entities to test ICT business continuity plans at least yearly. For all entities other than microenterprises, those tests must include scenarios of cyberattacks and switchovers between the primary ICT infrastructure and the redundant capacity, backups, and redundant facilities. This is not guidance. It is a statutory requirement. Third, DORA creates personal accountability. The regulation makes an entity's management body responsible for ICT risk management. Board members, executive leaders, and senior managers must define risk management strategies, actively participate in executing them, and maintain current knowledge of the ICT risk landscape. Leaders can be held personally liable for compliance failures, with individual penalty ceilings varying considerably by member state . What Articles 11 and 12 Actually Require The recovery obligations in DORA are concentrated in Article 11 (Response and Recovery) and Article 12 (Backup Policies and Procedures, Restoration and Recovery Procedures and Methods) . These two articles define what financial entities must build, test, and document. Article 11: Response and Recovery ICT Business Continuity Policy Financial entities must implement a comprehensive ICT business continuity policy through dedicated, documented plans, procedures, and mechanisms. These must ensure continuity of critical functions and enable rapid response, containment, and recovery from ICT-related incidents. Annual Testing Under Cyberattack Scenarios Testing must occur at least yearly for ICT systems supporting all functions. For entities beyond microenterprise scale, testing plans must include cyberattack scenarios and switchovers between primary infrastructure and backup systems. Independent Internal Audit ICT response and recovery plans must be subject to independent internal audit review. Crisis Management Function Entities must maintain a crisis management function with documented procedures for managing internal and external communications during an activation event. Records and Reporting Entities must keep readily accessible records of activities before and during disruption events. Upon request, they must report estimated aggregated annual costs and losses from major ICT incidents to competent authorities. Article 12: Backup Policies and Recovery Methods Documented Backup Policies Entities must develop and document backup policies specifying data scope and minimum backup frequency based on criticality and confidentiality levels. Backup System Activation Backup systems must be activatable without compromising network security or data availability, authenticity, integrity, or confidentiality. Backup procedures and recovery methods must be tested periodically. Physical and Logical Segregation When restoring from backups, entities must use ICT systems that are physically and logically segregated from the source system and protected from unauthorized access or ICT corruption. Redundant ICT Capacity Non-microenterprise entities must maintain redundant ICT capacities with adequate resources. Central securities depositories face additional requirements under Article 12(5), including maintaining a secondary processing site at a distinct geographic location. Recovery Time and Recovery Point Objectives Entities must define RTO and RPO for each function, accounting for criticality and potential market impact. In extreme scenarios, agreed service levels must still be met. Data Integrity on Recovery When recovering from an ICT-related incident, entities must perform multiple checks and reconciliations to ensure the highest level of data integrity. This applies to internal data and to data reconstructed from external stakeholders. The Compliance Gap Most CISOs Face Article 12(7) requires that when recovering from an incident, financial entities perform checks to ensure the highest level of data integrity. Most backup and recovery tools can restore data. Few can prove that the restored data is clean. The regulation does not ask whether you can recover. It asks whether you can prove that what you recovered is not already compromised. This is the gap between backup infrastructure and data-layer security controls . The ECB Enforcement Signal The European Central Bank is not waiting for DORA violations to surface. It is actively stress-testing cyber resilience and feeding results into its supervisory process. In 2024, the ECB conducted its first-ever cyber resilience stress test , involving 109 banks under direct supervision. The test scenario assumed all preventive measures had failed and a cyberattack had severely affected core system databases. Banks had to demonstrate their response and recovery procedures. A subset of 28 banks underwent extended testing with actual IT recovery tests and on-site quality assurance reviews. The ECB's conclusion: banks have response and recovery frameworks in place, but areas for improvement remain. Results fed directly into the 2024 Supervisory Review and Evaluation Process (SREP), which assesses each bank's individual risk profile. This was not a one-time exercise. The ECB's supervisory priorities for 2025-2027 explicitly name cyber resilience and operational resilience as core focus areas. The 2026-2028 priorities go further: full DORA implementation is a stated requirement, including ICT governance, incident reporting, resilience testing, and third-party risk management. Targeted on-site inspections for cyber risk and ICT third-party provider risk are planned for the 2026-2028 cycle. In 2026, the ECB is also conducting its first-ever reverse stress test on geopolitical risk , requiring banks to define the scenarios under which prescribed failure outcomes would materialize. The results will inform the SREP and the 2026 internal capital adequacy assessment process (ICAAP). The Supervisory Loop The ECB is building a continuous cycle: stress test, SREP findings, targeted on-site inspections, follow-up. If your bank was among the 109 tested in 2024 and received individual feedback, that feedback is now a supervisory expectation. The 2026-2028 OSI campaigns will check whether gaps identified in earlier reviews have been remediated. DORA's Reach Beyond the EU DORA is an EU regulation, but its impact extends beyond EU borders. Two mechanisms create global exposure. EU subsidiaries of global financial groups are directly subject to DORA. A US-headquartered bank with EU-licensed subsidiaries must ensure those subsidiaries comply with DORA's full requirements, including backup testing under cyberattack scenarios, incident reporting to competent authorities, and maintenance of ICT third-party provider registers. Critical ICT third-party service providers serving EU financial entities are subject to the DORA oversight framework regardless of their domicile. The ESAs have the authority to designate critical third-party providers, conduct off-site investigations, perform on-site inspections, and levy fines of up to 1% of average daily worldwide turnover per day of non-compliance, for up to six months. For global institutions operating across both EU and US regulatory frameworks, DORA creates a floor that often exceeds existing US requirements. The FFIEC CAT has been sunsetted. NIST CSF 2.0 is broad and principles-based. DORA is prescriptive and specific, particularly on backup testing, recovery verification, and incident reporting timelines. This extraterritorial reach is why global banks with EU operations are treating DORA compliance as a 2026 priority. When your EU operations are subject to a regulation that mandates documented recovery testing under cyberattack scenarios with results reportable to supervisors, the compliance program necessarily extends into global infrastructure. Threat-Led Penetration Testing (TLPT) DORA's testing requirements operate at two levels. The first is the annual resilience testing that all in-scope entities must perform under Article 11 . The second is the more advanced Threat-Led Penetration Testing (TLPT) mandated by Articles 26 and 27 for systemically important entities. TLPT is a full-scale, intelligence-driven attack simulation conducted on live production systems. It must cover critical or important functions and must be performed at least every three years. The ESAs' Regulatory Technical Standards specify mandatory purple-team phases, a dual-vendor rule (separate threat intelligence and red team providers), and reporting requirements to competent authorities. For credit institutions classified as significant under the ECB's Single Supervisory Mechanism, external testers are mandatory for every TLPT. The testing framework aligns with TIBER-EU , which was updated in February 2025 to align with DORA's RTS. The connection to recovery is direct. If a TLPT reveals that a simulated cyberattack can compromise backup systems and the entity cannot demonstrate clean recovery, that finding goes to the regulator. It creates a documented supervisory expectation for remediation. The Penalty Framework DORA's penalty framework delegates specific amounts to member states, resulting in considerable divergence across EU jurisdictions . Article 50 requires penalties to be "effective, proportionate and dissuasive." The following reflects ranges reported across member state implementations. Entity Type Penalty Range (varies by member state) Source Financial entities Up to 2% of total annual worldwide turnover in some jurisdictions DORA Art. 50, national implementations Individual managers EUR 100,000 (Finland) to EUR 5 million (Germany) DLA Piper analysis Critical ICT third-party providers 1% of average daily worldwide turnover per day of non-compliance, up to 6 months DORA Art. 35(8) Penalties vary by member state. DLA Piper's analysis of national penalty regimes shows considerable divergence across EU jurisdictions. Some member states have adopted higher ceilings than DORA's minimum requirements. Article 52 also allows member states to impose criminal penalties for severe violations. Beyond fines, competent authorities can order cessation of infringing conduct, require public disclosure of breaches (creating reputational exposure), and limit or suspend business activities until compliance is achieved. The Recovery Question DORA Forces You to Answer Strip away the regulatory language and DORA asks one question of every CISO at an in-scope financial entity: If a cyberattack compromises your production systems today, can you prove that your backup data is clean, that your recovery procedures work, and that restored data maintains integrity? Can you document this in a way that satisfies your regulator? Article 12(2) requires periodic testing of backup procedures and recovery methods. Article 12(7) requires data integrity checks on recovery. Article 11(6) requires all of this to be tested under cyberattack scenarios. The ECB's 2024 stress test simulated exactly this scenario and found gaps in banks' ability to execute. This is a provable-or-not-provable question. A CISO either has documented evidence that backup data has been verified as clean before recovery, or they do not. They either have test results showing successful recovery under an attack scenario with data integrity confirmed, or they do not. (For a deeper look at how provable recovery works as a security control, see the Elastio glossary.) The regulation does not care about the tools you selected. It does not care about your vendor relationships. It cares about outcomes: did recovery work, was data integrity maintained, and can you prove it to your supervisor? What to Do Now For CISOs at financial entities with EU exposure, the action items are concrete. Audit your current backup testing regime against Articles 11 and 12. Does your annual testing include cyberattack scenarios with switchovers to backup systems? Can you document the results in a format suitable for regulatory submission? Assess whether you can prove data integrity on recovery. Article 12(7) requires checks and reconciliations to ensure data integrity after an ICT incident. If your recovery process restores data without verifying it is clean, you have a gap. Map your ICT third-party provider register. DORA requires financial entities to maintain and submit registers of contractual arrangements with ICT third-party providers. The ESAs set April 30, 2025 as the deadline for national authorities to report these registers. Prepare for ECB on-site inspections. If you are an ECB-supervised institution, the 2026-2028 supervisory cycle includes targeted OSI campaigns for cyber risk and ICT third-party risk. Gaps identified in the 2024 stress test are now tracked supervisory expectations. Determine your TLPT obligations. If you are designated for TLPT under Article 26, your first test cycle is approaching. Competent authorities designate entities based on systemic importance, ICT maturity, and the impact of services on the financial sector. Frequently Asked Questions What is DORA? DORA is the EU's Digital Operational Resilience Act ( Regulation (EU) 2022/2554 ). It is a binding regulation that requires financial entities operating in the EU to manage ICT risk, report incidents, test resilience under cyberattack scenarios, and oversee third-party ICT providers. It became enforceable on January 17, 2025. What does DORA Article 12 require for backups? Article 12 requires financial entities to document backup policies specifying data scope and frequency, test backup procedures and recovery methods periodically, use physically and logically segregated systems when restoring from backups, maintain redundant ICT capacity, define recovery time and recovery point objectives for each function, and perform data integrity checks when recovering from an ICT incident. Does DORA apply to US banks? DORA applies directly to EU-licensed subsidiaries of US-headquartered banks. It also applies to ICT third-party service providers that support critical functions of EU financial entities, regardless of where the provider is domiciled. US banks with EU operations must ensure those operations comply with DORA's full requirements, including backup testing under cyberattack scenarios and incident reporting. What are the penalties for DORA non-compliance? DORA delegates penalty amounts to member states under Article 50, requiring penalties to be "effective, proportionate and dissuasive." Some jurisdictions have adopted ceilings of up to 2% of total annual worldwide turnover for financial entities. Individual manager penalties range from EUR 100,000 to EUR 5 million depending on the member state. For critical ICT third-party providers, Article 35(8) allows the Lead Overseer to impose periodic penalties of 1% of average daily worldwide turnover per day of non-compliance, for up to six months. Member states may also impose criminal penalties under Article 52. What is DORA TLPT? Threat-Led Penetration Testing (TLPT) is an advanced testing requirement under DORA Articles 26 and 27. Systemically important financial entities must conduct full-scale, intelligence-driven attack simulations on live production systems at least every three years. The tests must cover critical functions, include mandatory purple-team phases, use separate threat intelligence and red team providers, and report results to competent authorities. The framework aligns with TIBER-EU. What did the ECB cyber resilience stress test find? The ECB's 2024 cyber resilience stress test involved 109 banks under direct supervision. The test scenario assumed all preventive measures had failed and a cyberattack had compromised core system databases. The ECB concluded that banks have response and recovery frameworks in place, but areas for improvement remain. Results fed into the 2024 Supervisory Review and Evaluation Process (SREP). The ECB's 2026-2028 supervisory priorities include targeted on-site inspections for cyber risk and ICT third-party provider risk. How does DORA relate to NIS2? DORA is lex specialis to the NIS2 Directive, meaning it takes precedence over NIS2 for financial entities on matters of ICT risk management and incident reporting. Financial entities subject to DORA follow DORA's requirements rather than the corresponding NIS2 provisions. DORA's requirements are more prescriptive and sector-specific than NIS2. Reference Links DORA Full Text Regulation (EU) 2022/2554 (EUR-Lex) Article 11: Response and Recovery digital-operational-resilience-act.com Article 12: Backup Policies and Recovery Methods digital-operational-resilience-act.com Article 26: Threat-Led Penetration Testing digital-operational-resilience-act.com Article 27: Requirements for TLPT Testers digital-operational-resilience-act.com ECB Cyber Resilience Stress Test (2024) ECB Press Release, July 2024 ECB Supervisory Priorities 2025-2027 ECB Banking Supervision ECB Supervisory Priorities 2026-2028 ECB Banking Supervision ECB Stress Tests Overview ECB Banking Supervision ESAs TLPT Regulatory Technical Standards ESA Final Report, July 2024 TIBER-EU and Cyber Resilience ECB Macroprudential Bulletin, February 2025 EBA DORA Overview European Banking Authority EIOPA DORA Overview European Insurance and Occupational Pensions Authority DLA Piper: DORA Penalty Regime Divergence DLA Piper, October 2025 DLA Piper: DORA Application Key Considerations DLA Piper, February 2025 Mayer Brown: DORA Takes Effect Mayer Brown, January 2025 RECOVERY POSTURE Find out whether your recovery is provable. Assess Your Recovery Posture See the Platform

Events

In-person & virtual

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

All events

Virtual

2026 CISO & CIO Predictions: What Boards Need to Know About Cyber Strategy

A live leadership panel on board-level cyber governance, resilience, AI-driven threats, regulatory pressure, and what CISOs and CIOs need to prioritize in 2026.

Learn more

Toronto, ON

Building for the Breach: Ransomware Resilience & Recovery Assurance

Half-day in-person workshop hosted by AWS, NetApp, and Elastio on ransomware resilience, recovery assurance, and practical next steps before the next breach.

Register today

London, UK

Prove You're Ready for Ransomware

AWS and Elastio workshop and lunch focused on provable recovery readiness, resilience testing, and what financial services teams need before an incident forces the issue.

Register today

Singapore

AWS Summit Singapore

Meet Elastio at AWS Summit Singapore at Sands Expo — provable recovery and regulatory-ready evidence for financial services teams across ASEAN on AWS.

Register today

New York, NY

AWS Financial Services Symposium

Meet Elastio at the AWS FSI Symposium for banking, capital markets, and insurance leaders — provable recovery and what happens after ransomware on AWS.

Register today

Sydney, Australia

AWS Summit Sydney

Meet Elastio at AWS Summit Sydney at ICC Sydney — APRA-ready evidence, AWS Backup integration, and provable recovery for Australian financial services on AWS.

Register today

National Harbor, MD

Gartner Security & Risk Management Summit

Meet Elastio at the Gartner Security & Risk Summit — provable recovery, board-ready evidence, and the blind spot in your security stack (June 1–4).

Register today

New York, NY

AWS Summit New York

Meet Elastio at AWS Summit New York at the Javits Center — live demos, private meetings, and proof your AWS backup data is clean before an attack.

Register today

Las Vegas, NV

Black Hat USA 2026

Live demo of ransomware in cloud backups, file-level evidence, and provable clean recovery — Mandalay Bay Business Hall, August 5–6.

Register today

London, UK

Gartner Security & Risk Management Summit London

DORA, ICT resilience, and provable recovery — meet Elastio at the Gartner Security & Risk Summit in London, September 22–24.

Register today

Las Vegas, NV

AWS re:Invent 2026

Meet Elastio at AWS re:Invent — architecture conversations, live demos, and private meetings on provable recovery for AWS workloads.

Register today

Past event

Chicago, IL

Building for the Breach: Ransomware Resilience & Recovery Assurance

Half-day in-person workshop hosted by AWS, NetApp, and Elastio on ransomware resilience, recovery assurance, and practical next steps before the next breach.

View details