Our Expertise
Our solution does threat scanning while the backup is being ingested.
Not the next day. Not after an attack. At the moment your backup ingests the data. As the backup job reads your systems, every stream is inspected for ransomware, encrypted files, high entropy, file types that no longer match their contents, sudden extension changes. Anything suspicious is flagged and isolated before that copy is ever trusted for recovery. Immutable is not the same as clean. Now your backups are both.
of ransomware victims say attackers went after their backups during the attack. Assume they will go after yours.
higher median recovery cost when backups are compromised: US$3.0M vs US$375K.
global median dwell time for ransomware intrusions. That is the time you have to notice before encryption starts.
The scan happens during the backup. Not after it.
Until now, most organisations backed up first and scanned later, if at all. That leaves a gap of hours, days or weeks where poisoned data sits in your recovery copies looking perfectly normal. We close that gap by putting the threat scan inside the backup process itself, at the point of ingestion.
The data is inspected in the backup stream, while the job is running, not in a separate scan days later.
Suspicious files are flagged in the backup index and isolated before that recovery point is ever used for a restore.
Each backup carries a verdict from the moment it is written, so on the worst day you already know which copy is clean.
Your backups are now part of the attack.
For a decade the answer to ransomware was "keep a good backup". Attackers noticed. Modern ransomware groups get in, escalate privileges, map the environment and look for your backup console before they launch. The reason is simple: if you can restore, you don't need to pay them.
You may already have immutable storage, and it solves one part of this: nobody can delete or overwrite a locked copy. But immutability only protects what you write to it. If malware, a dormant implant or half-encrypted files reach the vault, immutability faithfully keeps those too.
Poisoned restore points
Files encrypted early in the attack, or implants planted during the dwell window, are backed up as if they were normal changes. Restore them and you let the attacker back in.
The "last clean copy" hunt
Without a verdict on each recovery point, your team restores, tests, finds malware, rolls back further and tries again. That trial and error is what turns hours into days.
Paying because recovery looks uncertain
Organisations whose backups were compromised were almost twice as likely to pay the ransom (67% vs 36%) and paid roughly double. Your uncertainty is exactly what attackers are selling.
Encryption leaves a mathematical fingerprint.
Your business data is full of patterns. Documents repeat words, databases repeat structures, and even binaries have recognisable headers. Good encryption destroys those patterns: the output looks like random noise. Shannon entropy measures exactly that, per block, in bits per byte.
p(x) is how often each of the 256 byte values appears. Ordinary office files typically sit around 4 to 6 bits/byte. Strongly encrypted data approaches the maximum of 8.0.
We switch on detection that watches the write stream on the array itself, across NAS shares and SAN volumes, and looks for that change at scale: a user or process suddenly rewriting many files whose entropy jumps, whose extensions change, and whose file headers no longer match their type.
Illustrative histograms, simplified for clarity.
Two independent detectors. One clean recovery.
Each layer sees something the other cannot. Primary storage sees the attack as it happens. The backup platform scans everything you will ever restore, at the moment it is backed up. Together they close the gap between "we've been hit" and "we're back".
Layer 1: Storage-level entropy monitoring and lockdown
Detection runs inside the storage operating system, close to the data, on the volumes you choose. When it sees an encryption burst it does three things within moments: takes a locked snapshot so the last good state survives, raises an alert with evidence (which user, which share, which files) and, where the platform supports it, suspends the offending user or session at the storage layer. That last control matters because it does not depend on a host operating system or directory account the attacker may already own.
Layer 2: Commvault threat scanning at backup ingestion
This is the part that changes the game. As the backup job ingests your data, Commvault inspects it for ransomware indicators such as encrypted content, entropy, file types that do not match their contents, unusual extension growth and abnormal change rates, so suspicious data is caught during the backup instead of being discovered weeks later. Commvault Threat Scan then applies several engines: signature scanning, YARA rules, hash lookups and machine-learning classifiers, plus an AI model trained to recognise files that have been encrypted by ransomware from their statistical structure. Infected files are marked in the backup index and quarantined, so a restore assembles the last known-good version of each file instead of rolling the whole system back to an arbitrary date. The same scanning is also available on demand for threat hunting, during restores and inside a Commvault Cleanroom.
Our layer: design, integration and operations
Technology is only half the outcome. We design the policies and thresholds around your workloads, separate your backup control plane from your production identity, wire alerts from both layers into your SOC, build your recovery runbooks and rehearse them with you. If you prefer, we run it for you as a managed service.
From "which backup can we trust?" to a verified restore.
| Moment | Backup only | With Inline Threat Defence |
|---|---|---|
| Backup runs | Data copied blindly, malware included | Data scanned as it is ingested; threats isolated before the copy is trusted |
| Encryption starts | Noticed when users or the ransom note report it | Burst detected on the array; snapshot locked; session blocked |
| Scoping the damage | Manual log trawling across servers | Alert names the user, share, files and time |
| Choosing a restore point | Guess, restore, test, roll back, repeat | Each recovery point carries a scan verdict |
| Restoring | Whole-system rollback, losing good recent data | Last known-good file versions; infected files withheld |
| Proving it is safe | Hope | Cleanroom test and scan evidence before going live |
| Regulator & board | Narrative assembled after the fact | Timestamped evidence trail from both layers |
Six decisions that decide how a ransomware day ends.
You probably already own backup software and some form of immutable storage. Whether you face a bad week or a bad afternoon usually comes down to these six decisions, in roughly this order of impact.
Measure time-to-clean-recovery, not RTO
RTO assumes the data you restore is good. Track how long it takes to restore a verified clean copy of your top five systems. That single number exposes every weakness below.
Take backups off the production domain
If one stolen domain-admin account can reach the backup console, nothing else matters. Use a separate identity plane, phishing-resistant MFA and multi-person approval for deletes and retention changes.
Detect in two places, not one
Storage sees encryption as it happens; the backup platform sees dormant malware and slow, low-volume encryption that slips under real-time thresholds. Each covers the other's blind spot.
Scan at ingestion, not after the incident
Scanning only after an incident means scanning terabytes under pressure while your systems are down. Scanning while the backup is being created means every recovery point already has a verdict when the call comes.
Rehearse in a cleanroom every quarter
Untested recovery is a belief, not a capability. Quarterly isolated restores of critical systems, timed and documented, turn the runbook into muscle memory and give the board evidence.
Tune for signal, wire into the SOC
A detector that cries wolf gets switched off. Baseline normal behaviour per workload, route both layers' alerts into your SIEM, and agree in advance who may approve a restore.
Designed for how your organisation actually runs.
Wherever you operate, your regulators and your board are moving in the same direction. Banking supervisors, energy and telecoms regulators and data protection authorities increasingly expect you to detect incidents quickly, report them within tight deadlines and prove that critical services can be restored. Having backups is no longer the test. Proving a clean, timely recovery is.
We design for the way you really operate: data that must stay within national borders, links between sites that are not always fast, and budgets that need your existing storage and backup investments to work harder rather than be replaced.
Evidence for regulators
Your regulator may expect a significant cyber incident to be reported within hours, and data protection laws add breach-notification duties on top. Timestamped detections from both layers, showing what was touched, when and by whom, give you the facts quickly.
Residency by design
Detection runs on-premises on your storage, and immutable copies can live in your own data centre or a facility in the right jurisdiction, with an optional cloud tier where residency rules allow.
Low-bandwidth friendly
Because scanning happens where the data lives, recovery does not depend on pulling terabytes across a WAN. Clean restores run locally first, and replicate later.
Sectors where downtime is a national event.
Banking & payments
Core banking, card and mobile-money platforms where hours of downtime affect millions of customers and the payment system.
Moves the needle: verified restore points for core databases and regulator-ready evidence.
Energy & utilities
Billing, customer and operational systems that are prime targets and where backup compromise rates are among the highest of any sector.
Moves the needle: isolating the backup estate from the corporate domain.
Government
Citizen registries, revenue and records systems where data loss is permanent and public trust is at stake.
Moves the needle: sovereign immutable copies and rehearsed cleanroom recovery.
Telecoms
Subscriber, billing and mediation platforms with very large, fast-changing datasets.
Moves the needle: per-file last-known-good recovery instead of full rollbacks.
Start with the truth about your recovery.
We start by measuring, not selling. Our first step tells you how long a clean recovery would take you today and exactly where your gaps are.
Recovery readiness review
We map your critical systems, backup identity paths, immutability and current time-to-clean-recovery. You get clear findings and priorities.
Proof of concept
We enable entropy detection on selected volumes and Threat Scan on a representative backup set, then simulate an encryption attack in a controlled test so you see it work.
Production pilot
We tune thresholds on your real workloads, connect alerts to your SOC, isolate your backup control plane and run your first cleanroom rehearsal together.
Scale & manage
We roll out across your estate with runbooks, quarterly rehearsals and board reporting, run by your team or by us as a managed service.
How long would a clean recovery take you today?
Book a recovery readiness review with our cyber resilience team. You'll get a measured answer, not a brochure.
Talk to Sybyl →- Storage-level entropy detection on NAS & SAN
- Commvault Threat Scan & Cleanroom Recovery
- Isolated backup identity & immutable copies
- SOC integration and rehearsed runbooks
Case Study & Related Insights
The Reality of the AI landscape: Debunking the reality from expectations
Artificial intelligence adoption is nearly universal among firms, yet measurable returns
The Reality of the AI landscape: Debunking the reality from expectations
Artificial intelligence adoption is nearly universal among firms, yet measurable returns remain elusive. While 69% of companies utilize AI, a staggering 89% report no significant productivity gains. This disconnect raises critical questions: What distinguishes the minority of firms achieving results from the majority that are not? The answer lies in ownership and tailored AI solutions. This piece explores the essential transition from generic tools to customized AI, offering a practical framework for executives ready to harness AI’s true potential. Discover how to build the infrastructure that makes AI specific to your organization and unlocks its value.
The Era of the Self-Propagating AI Worm: A Post-Mortem on Palisade’s Self-Replication Findings
1. The Sybyl Perspective: An Intelligence Briefing Empirical data has codified
