Threat data and regulatory status current as of 3 September 2026.
Modern ransomware protection has to solve two problems, and most programs are still built for only one of them. Backups answer the encryption problem: if an attacker locks your systems, you restore and refuse to pay. They answer nothing at all about the extortion problem, because stolen data stays stolen after a clean restore. Attackers noticed. Arctic Wolf’s 2026 threat report documents data-only extortion rising roughly elevenfold in a year, from around two percent of incident response cases to twenty-two percent, and Kaspersky reports the share of victims paying fell to about twenty-eight percent in 2025, which is precisely what pushed groups toward an approach where backups do not help. Meanwhile identity misuse features in the large majority of ransomware operations, and analysts report backup systems themselves compromised in a substantial share of incidents. We recommend you stop measuring ransomware readiness by recovery time alone and start measuring whether you would detect data leaving.
Overview
- Backups solve encryption, not extortion. A perfect restore does not un-steal a customer database.
- Identity is the primary entry path. Valid credentials, not malware, are how most of these operations start.
- Your backups are a target, not a refuge. Attackers look for the backup console early, which is why immutability matters more than frequency.
- Detection has to catch exfiltration. If your monitoring only alerts on encryption, quiet data theft passes through it.
- Reporting clocks are tightening. Federal reporting obligations for incidents and ransom payments are close to final, and they are measured in hours.
The 5 Why’s
This is written for IT directors, security leads, and CISOs at mid-market and enterprise organizations in the Atlanta metro and across Georgia, typically between one hundred and a few thousand employees, where backup and endpoint protection are already in place and the question on the table is what else the budget should cover.
Atlanta learned this lesson publicly. The 2018 attack on city systems produced a recovery effort that ran far beyond the ransom demand and took months rather than days, and it remains the reference point many local leadership teams still use. What has changed since then is that an attack of that shape, loud, encryption-first, and immediately visible, is no longer the most likely thing to happen to you.
The regional concentration matters. Georgia’s payment processing sector means a large number of local organizations sit inside the transaction chain for businesses nationwide, which makes them attractive for the leverage they provide over customers rather than only for their own data. Healthcare systems and their vendor networks carry patient data that produces regulatory consequences on exposure alone. Logistics and distribution operators around the airport and rail corridors face availability pressure where hours matter. Professional services firms hold client material whose disclosure damages the client relationship regardless of whether operations were affected.
The consequence of getting this wrong is no longer a recovery timeline. It is a notification obligation, a regulatory file, and a conversation with customers whose data you were holding.
What Changed About Ransomware, and What Your Controls Assume
Most security programs were designed against a threat model that attackers have deliberately moved away from.
The classic model went like this: intrusion, lateral movement, encryption, ransom note, recovery from backup. Every control in the standard stack maps to a stage of it. Endpoint detection watches for encryption behavior. Backups provide the alternative to paying. Incident response plans assume the moment of discovery is loud and unmistakable, because encryption announces itself.
The current model is quieter. Attackers gain access with valid credentials, often bought from an initial access broker who obtained them through an exposed remote access service or an unpatched edge appliance. They move using administrative protocols that look like administration. They locate and exfiltrate the data with the most leverage. Then, increasingly, they stop. No encryption, no ransom note on the screen, just an email weeks later referencing files you did not know had left. Reporting from ReliaQuest on the first quarter of 2026 counted leak site postings up more than twenty percent year over year, with identity-first intrusion and data theft from cloud applications delivering major impact without any encryptor deployed at all.
Dwell time has compressed alongside this, with some incident responders reporting intervals measured in days rather than the weeks that were common a few years ago. That matters because it shortens the window in which detection is useful.
The practical consequence is a mismatch. An organization with excellent backups, a well-tested recovery plan, and endpoint protection tuned for encryption behavior can be fully compromised by an operation that never encrypts anything. This is the gap we look for during an IT assessment, and it is usually not a tooling gap. It is a coverage gap, where the tools are watching for the wrong stage of the attack.
Do Backups Still Protect You From Ransomware?
They protect you from half of it, and that half is the half attackers are moving away from.
Backups remain the correct answer to the availability problem. If systems are encrypted, a tested and immutable backup is what lets you refuse to pay and restore on your own timeline. Nothing in the current threat picture makes that less true, and organizations without that capability should build it before anything else on this page.
What backups do not touch is disclosure. If an attacker has already copied your customer records, your employee data, or your client files, restoring from backup returns your operations and changes nothing about their leverage. Analysts tracking this report that data theft accompanies the large majority of ransomware cases now, and a growing share involve nothing else. Backup quality has no bearing on that outcome.
There is a second problem worth naming. Backup infrastructure is itself a target, and analysis published in 2026 puts backup systems compromised in something close to two in five incidents. Attackers with administrative credentials look for the backup console early, because destroying recovery capability is what makes paying necessary. That changes what a good backup looks like: immutable within its retention window so it cannot be deleted even by a valid administrator account, held in a separate identity and authentication boundary from production, and restored in a test recently enough that you know it works. Organizations running backups under the same domain credentials that manage everything else have a backup plan that fails in the exact scenario it exists for, which is why we scope this inside business continuity planning rather than as a storage decision.
What we recommend you do about it:
- Make at least one copy immutable. Object lock or write-once storage that cannot be deleted or altered within its retention window, including by a compromised administrator.
- Separate the backup identity boundary from production. Backup administration should not be reachable with the credentials an attacker will already have.
- Test restores, not backup job status. A completed job says data exists. Only a restore says you can get it back inside your stated recovery objective.
- Assume backups will be targeted early. Alert on backup deletion, retention policy changes, and console logins as high-priority events.
- Budget for the exposure problem separately. Recovery capability and data protection are different projects with different controls, and one does not fund the other.
Where Do Modern Ransomware Attacks Actually Start?
With valid credentials and exposed remote access, far more often than with malware. Identity misuse features in the large majority of ransomware operations, which reframes ransomware as an access control problem that ends in extortion rather than as a malware problem.
The common entry paths are consistent across the 2026 reporting. Exposed remote access services, particularly web-based remote desktop gateways, are a stated focus for the initial access brokers who sell footholds to ransomware affiliates. Unpatched internet-facing appliances, including VPN concentrators and firewalls from several major vendors, have been exploited at scale. Phishing that harvests session tokens rather than passwords lets an attacker resume an authenticated session without triggering multi-factor authentication, because the authentication already happened. Third-party and supplier access provides a path into organizations whose own controls are sound.
The priority order shifts depending on how the environment is built. Organizations with a large on-premises footprint and remote access for staff or vendors should start with the edge: inventory every internet-facing service, confirm patch status on appliances, and eliminate direct remote desktop exposure entirely. Organizations that are substantially cloud and SaaS based face a different first problem, since intrusions there increasingly bypass endpoints altogether, and the exposure runs through application permissions, OAuth grants, and integration accounts rather than through servers. That overlap with SaaS sprawl risk is not a coincidence. The same unmanaged applications that complicate offboarding are the ones providing quiet access to data.
What we recommend you do about it:
- Inventory every internet-facing service and patch appliances on a defined clock. Edge devices carry disproportionate risk and are frequently outside normal patch reporting.
- Eliminate direct remote desktop exposure. Broker access through a gateway with strong authentication, or remove it.
- Deploy phishing-resistant authentication for privileged accounts first. Hardware-backed keys defeat the token theft that defeats app-based codes.
- Monitor for session anomalies, not just failed logins. Impossible travel, new device registrations, and unusual token use are the signals that matter.
- Scope third-party and vendor access tightly. Time-bound, brokered, and logged, rather than standing credentials nobody reviews.
What Should Change in Your Incident Response Plan?
Three things: the plan needs to work when nothing is encrypted, it needs an exfiltration detection capability behind it, and it needs to run against reporting clocks measured in hours rather than days.
Most incident response plans open with a discovery event that is obvious. In a data-only extortion case there is no obvious event. Discovery frequently comes from the attacker, from a customer, or from a leak site, weeks after the access occurred, which means your logs may have aged out before you know to look. Extending log retention is unglamorous and it is what determines whether you can answer the only question that matters afterward: what actually left, and whose data was in it.
The regulatory side is tightening in a way that should shape planning now. CISA’s rule implementing the Cyber Incident Reporting for Critical Infrastructure Act is expected to be finalized in September 2026, after moving from an original October 2025 statutory deadline and then a May 2026 target. Once effective it will require covered entities across the sixteen critical infrastructure sectors to report substantial cyber incidents within seventy-two hours and ransom payments within twenty-four hours. Those two clocks are written into the statute rather than into the rule, so the rulemaking decides who they apply to and how they operate rather than whether they exist. Organizations in healthcare, financial services, energy, communications, transportation, and the other covered sectors should assume the obligation is coming and rehearse against it. Sector-specific obligations under HIPAA, financial regulators, and state breach notification laws apply regardless and often run on shorter timelines than people expect.
What we recommend you do about it:
- Tabletop a data theft scenario with no encryption. Most teams have never rehearsed the case where operations are fine and the data is gone.
- Extend and centralize log retention. If discovery comes eight weeks late, your investigation window depends entirely on what you kept.
- Deploy exfiltration detection, not just endpoint detection. Unusual outbound volume, access to data stores outside normal patterns, and large downloads from cloud applications.
- Decide the payment question before you face it. Who authorizes, under what conditions, with counsel and insurer involved, and against a twenty-four hour reporting clock if it becomes an obligation.
- Pre-identify counsel, forensics, and notification support. Contracting these under pressure costs time you will not have.
Ransomware Expertise from Matt Rosenthal
In 30 years of building security programs, I have watched the ransomware conversation get stuck on one question: can we restore. What I have seen firsthand is organizations answering that question confidently, investing accordingly, and then facing an extortion demand over data that walked out weeks earlier while every dashboard stayed green. Restoring is table stakes now. Our team scopes ransomware readiness around identity, egress visibility, and whether you could actually tell what left, because that is the half most programs never built. If your last tabletop assumed an encryption event, run a different one. See our cybersecurity services and IT assessment process.
Where to Start If Your Program Is Built Around Recovery
The organizations handling this well have not abandoned backup. They have stopped treating it as the whole answer. Recovery capability protects operations, and it is worth every dollar spent on it. What it cannot do is protect the data that has already been copied, and that is now the primary business consequence of a ransomware event for a growing share of victims.
Start by asking a single question of your current program: if an attacker took a large volume of data out of your environment this week without encrypting anything, how would you find out and how long would it take. Work backward from an honest answer. It usually leads to log retention, egress monitoring, and identity controls rather than to another endpoint product.
Then harden the recovery capability you already have against the fact that it is a target. Immutability, a separate identity boundary, and a tested restore. Then rehearse the scenario your plan does not currently cover, with counsel and communications in the room and a clock running, because the reporting obligations arriving over the next year are measured in hours.
Modern ransomware protection is less about stopping encryption than about controlling access and seeing what leaves. If you cannot currently tell what left your environment last month, that is the gap worth closing first. Contact Mindcore to request a ransomware readiness review.
