A backup that has never been restored is a hope, not a backup.
Almost every organisation we assess has backup jobs running and green reports arriving. Far fewer have ever restored a full system, and fewer still have restored one under the conditions a real incident would impose. In 2-4 days we audit what is actually protected, perform a supervised live restore test, and give you a written answer to the only question that matters: would it come back.
- 2-4 daysTypical engagement
- LiveRestore test included
- Remote-firstAnywhere in India
- 9 areasExamined and evidenced
Nine questions a green backup dashboard does not answer.
Coverage: what is not being backed up
Scope drifts constantly. A new application arrives and nobody adds it. A server is rebuilt and the agent never comes back. A database moves and the old path keeps backing up an empty folder. We reconcile what is protected against what the business actually depends on, and the gap is almost never zero and almost never known in advance.
SaaS data: Microsoft 365 and Google Workspace
The most common gap we find in Indian SMBs. Mail, OneDrive, SharePoint, Teams and Drive data live in the vendor cloud, and most organisations assume the vendor backs them up. The vendor keeps the service running; recovering your data from deletion, ransomware sync or a malicious insider is your responsibility, and usually nothing is doing it.
Schedule versus actual success rate
The schedule says daily. The job history often says something else: jobs skipped for lack of space, chains broken by a reboot, a repository filling quietly for months. We read the actual job history over a meaningful window and report the real success rate per system, which is frequently a surprise to the people paying for the backup.
Retention versus what you actually need
Ransomware often sits in an environment for weeks before detonating, and a data-entry error can surface months later. If retention is fourteen days, every restore point may already be compromised or the clean copy may already be gone. We compare configured retention against realistic discovery timelines and against what your auditors and regulators expect you to produce.
Immutability and air-gap against ransomware
Modern ransomware crews look for backups first, because destroying them is what converts an incident into a payment decision. We test whether a copy exists that cannot be encrypted or deleted from a compromised production environment: immutable retention that holds even against an administrator, or storage that production credentials simply cannot reach.
Encryption at rest and in transit
Backups are a complete copy of your most sensitive data, often sitting on the least monitored storage in the company. We check whether backup data is encrypted on disk and on the wire, where the keys live, and who can read them. Under the DPDP Act, personal data in a backup set is still personal data you are accountable for.
RPO and RTO: reality versus assumption
The recovery point objective is how much data you can afford to lose; the recovery time objective is how long you can afford to be down. Both should be business decisions, and in most organisations neither has ever been decided, so the answer defaults to whatever the schedule happens to produce. We set them with you, then measure whether the system meets them.
Backup credentials as an attack surface
The backup service account can usually read every server in the company, and the console can usually delete every restore point. If those credentials sit in the same directory an attacker compromises first, your backup is part of the attack surface rather than a defence. We map who can reach the backup system and with what, and whether that access would survive a domain compromise.
Alerting, and whether anyone acts on it
Backups fail quietly. A job that has been failing for eleven weeks looks exactly like one that has been succeeding, unless a human reads the alert. We check not just that failure alerting exists but where it goes, whether that mailbox is watched, and whether anybody acted the last time it fired. An alert nobody responds to is indistinguishable from no alert.
Ransomware attacks your backups before it attacks your data.
Indian SMBs and mid-market companies are squarely inside the ransomware economy now, and the attack pattern has changed in a way that makes ten-year-old backup thinking dangerous. A design built to survive a disk failure or a fire says nothing about an attacker who is already inside your network and specifically hunting for the backup server.
- The mechanism is simple. An attacker who reaches administrative credentials looks for the backup console, deletes or encrypts the restore points, and only then encrypts production. Removing your alternative to paying is the point of the sequence. This is why backup security now matters as much as backup coverage, and why we test the compromise scenario explicitly.
- The regulatory clock runs at the same time. CERT-In directions require covered cyber incidents, including ransomware and data breaches, to be reported within six hours of noticing them, and the DPDP Act adds breach notification duties towards the Data Protection Board and affected individuals. An organisation that cannot restore is answering regulators and customers from the worst possible position: down, exposed, and negotiating with the attacker.
- The practical test is one question: could somebody holding your domain administrator credentials, right now, delete your backups? If the console authenticates against the same directory, if the repository is reachable over the network with production credentials, or if retention can be shortened from inside the console, the answer is yes, and the backup is not protecting you against the scenario that most threatens you.
- What changes the answer is separation and immutability: backup credentials that do not overlap with production administration, storage that production credentials cannot reach, and retention that cannot be shortened within its window even by an administrator. Most modern platforms support all three. Far fewer estates have them configured, and fewer still have tested that they hold.
Four things that make this an audit rather than a sales call.
We report clean results when we find them
Some estates are in genuinely good shape and the honest report says so, with a couple of small improvements and no reason to change anything. We would rather deliver that report than manufacture urgency. An auditor who never reports a clean result is not auditing.
We restore something, not just read configuration
A configuration review is worth having and it is not evidence. The centre of this engagement is an actual supervised restore, into an isolated environment, timed and documented. That artefact is the only thing that answers the question the whole exercise exists to ask.
We test the compromise scenario, not just the hardware one
Most backup designs survive a failed disk. Far fewer survive an attacker holding administrative credentials, which is the scenario that actually threatens Indian businesses today. We test whether your backups could be reached and destroyed from a compromised environment.
You get evidence you can hand to somebody else
A dated record of what was restored, how long it took, what the objectives were and whether they were met. One document that answers external auditors, cyber insurers at renewal, and enterprise customers doing vendor due diligence, instead of an awkward improvised answer each time.
What we actually restore, and how success is measured.
Full system restore
A production server or virtual machine restored end to end into an isolated environment, then booted and checked. This is the test almost nobody has performed, and the one that settles the question.
- System selected jointly, biased towards what the business depends on
- Restored to isolated compute, never over the top of production
- Boot verified, services started, application layer checked
- Wall-clock time recorded from initiation to usable system
- Result measured against your stated recovery time objective
Database restore with consistency checks
Databases are where naive backups fail most often: a file-level copy of a running database frequently restores as a corrupt one. We restore the database itself and prove it is usable.
- Restore to an isolated instance, not production
- Integrity and consistency checks run after restore
- Application-level read test where feasible
- Point-in-time recovery tested where the platform supports it
- Restore point age compared against your stated RPO
Microsoft 365 and Workspace item restore
Where SaaS backup exists, we test it does what everyone assumes: a deleted mailbox item, a prior document version, a removed site or shared drive, recovered to a chosen point in time. Where no SaaS backup exists, that is recorded as a coverage finding, not quietly skipped.
- Mailbox item and folder recovery to a point in time
- OneDrive, SharePoint or Drive file and version recovery
- Recovery beyond the native retention windows checked
- Native retention settings documented either way
- Gap recorded explicitly if no third-party backup exists
How pass and fail are decided
Success criteria are agreed in writing before the test starts, so the result cannot be argued into a pass afterwards. Every criterion is binary and evidenced.
- Data restored complete and readable, verified, not assumed
- System boots and the application actually serves
- Measured restore time inside the stated RTO
- Restore point age inside the stated RPO
- Dated evidence pack produced whatever the outcome
Six situations where an untested backup becomes a real problem.
You have never actually restore-tested
Backups have run for years, the reports are green, and nobody in the building has ever performed a full system restore. This is the most common state we find, and it means the organisation is operating on an assumption it has never checked. The audit converts that assumption into a measured fact in under a week.
After a ransomware scare, yours or a peer's
Somebody senior reads about a comparable Indian business losing a week of operations and asks whether we would be alright. The honest answer requires testing rather than reassurance, and this is the best possible moment to get it, because the attention and the budget conversation are already won.
You run on Microsoft 365 and assume Microsoft backs it up
Cloud-first companies with no servers often believe backup is not their problem any more. Microsoft keeps the service running and provides retention features; a backup of your tenant data under your control, restorable to a point in time you choose, is a different thing, and by default nothing is providing it. We establish what your tenant actually has.
An auditor is asking for restore evidence
External auditors testing IT general controls, ISO 27001 certification bodies, and customer due-diligence questionnaires have all learned to ask for evidence of a tested restore rather than accepting job success reports. A dated restore test performed during the period closes the question cleanly; its absence is a routine finding.
A cyber insurance proposal or renewal
Insurers now ask specific questions about backup frequency, isolation, immutability, and whether restores are tested, on a proposal form you sign. Establishing the real position before completing the form is straightforward, and considerably better than discovering the gap at claim time.
Onboarding to an AMC or changing IT provider
A new provider inherits a backup configuration built by somebody else, with undocumented assumptions and a scope that may not match reality. We run this audit as the first step of AMC onboarding: it establishes what is actually true at handover and protects both sides from discovering the previous arrangement was inadequate mid-incident.
Assumed, backed up, or verified recoverable.
| Feature | Verified recoverable Tested and evidenced | Backed up Jobs run, untested | Assumed Somebody set it up once |
|---|---|---|---|
Backup jobs run and report success | Probably | ||
Scope reconciled against business systems | Partly | ||
Microsoft 365 / Workspace data covered | Sometimes | ||
RPO and RTO decided by the business | |||
Full system restore tested and timed | |||
Backups survive an administrator compromise | Unlikely | ||
Immutability tested, not just enabled | |||
Failures alerted, and a human responds | Eventually | ||
Dated evidence for auditors and insurers | Policy only | ||
Outcome in a real ransomware event | Recovery | Uncertain | Payment decision |
Four steps over 2-4 days, and the restore test is the point of all of them.
- 1
Scoping and objectives
Half a day
A working session to list what the business actually depends on, and to set recovery point and recovery time objectives per critical system as business decisions rather than schedule accidents. We also agree the restore test scope and its written pass criteria, so the result cannot be argued afterwards. Initial replies to any enquiry go out within 4 business hours.
- 2
Evidence collection
1 day
Remote review of the backup platform: job histories over a meaningful window, schedules, retention, repository health, encryption, credential and access paths, alerting configuration, and SaaS coverage for Microsoft 365 or Google Workspace. Read-only access is sufficient; we change nothing in this phase.
- 3
The supervised live restore test
0.5-1 day
The centre of the engagement. A full system, a database, and SaaS items restored into isolated targets, live in a screen-shared session with your engineer present, timed against your stated RTO, checked against your stated RPO, and recorded against the agreed pass criteria. Whatever the outcome, it becomes dated evidence.
- 4
Report, roadmap and read-out
1 day
The coverage map, restore test results, gap report and remediation roadmap, delivered in a live read-out with your stakeholders. Findings are ranked by what would actually prevent recovery. If you want the gaps fixed, we quote that as separate work; the audit stands on its own either way.
Four documents, each written to be handed to somebody.
| Deliverable | What it contains | Who it is for | |
|---|---|---|---|
| Backup coverage map | Every system, database and SaaS workload the business depends on, against what is actually protected, how often, and with what retention. Gaps named explicitly. | IT leadership and whoever owns risk | |
| Restore test results | What was restored, when, into what, how long it took, whether it met the stated RPO and RTO, and the agreed pass or fail against each criterion. Dated and signed. | Auditors, insurers, enterprise customers, the board | |
| Gap report | Findings across all nine audit areas, ranked by what would actually prevent recovery rather than by generic severity labels. Each finding states the mechanism, not just the symptom. | The engineer or provider who runs your backups | |
| Remediation roadmap | What to fix, in what order, with rough effort per item and a recommended re-test cadence. Written so it can be executed by us, by your team, or by your existing provider. | Whoever plans and budgets the fix |
What organisations ask before booking a backup audit.
Twelve questions to put to your own team this week.
Coverage and objectives
- What is our recovery time objective, and who decided it?If nobody decided, you do not have one. You have a schedule.
- Is every system the business depends on inside the backup scope?Reconcile against the business, not against the server list.
- Is our Microsoft 365 or Google Workspace data backed up by anything?Native retention is not a backup under your control.
- When did the scope last get reviewed against reality?Drift is guaranteed. New systems rarely get added.
Would it survive an attack
- Could a domain administrator delete our backups today?The single most revealing question on this page.
- Does the backup system authenticate separately from production?Shared identity means shared compromise.
- Is retention immutable within its window, even to an admin?Enabled is not the same as enforced. It has to be tested.
- Is there a copy production credentials simply cannot reach?Reachable from production is reachable by an attacker.
Could we actually recover
- When did we last restore a full system, not just a file?A file proves the media works. A system proves recovery works.
- How long did it take, measured rather than estimated?Compare it honestly to what the business can survive.
- Does more than one person know how to run a restore?Recovery knowledge concentrated in one head is a finding.
- Could we show an auditor or insurer dated restore evidence?They are increasingly asking for exactly this.
The pages around this one.
Data Backup Services
The service this page audits. Managed backup for servers, endpoints, databases and Microsoft 365, designed and run with the restore test built in rather than bolted on.
Learn moreCybersecurity Audit & Compliance
The wider security audit practice: independent assessments, penetration testing, and compliance gap analysis against ISO 27001, CERT-In and other frameworks.
Learn moreIT AMC India
The annual maintenance contract this audit slots into at onboarding: verified backups first, then continuous monitoring with a 30 minutes response commitment for managed clients.
Learn moreTwo questions for your team, and neither costs anything to answer.
When did we last perform a full restore, and could a domain administrator delete our backups today? If either answer is uncomfortable, a 2-4 day audit with a live restore test replaces the assumption with a measured fact, and leaves you with dated evidence you can hand to an auditor, an insurer or your board.
Related Services
Explore more solutions that work great with this service