Skip to main content
Backup Audit India

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.

Book a backup auditSee what we examine
Engineer reviewing backup job history and restore test results across multiple systems
  • 2-4 daysTypical engagement
  • LiveRestore test included
  • Remote-firstAnywhere in India
  • 9 areasExamined and evidenced
What the audit examines

Nine questions a green backup dashboard does not answer.

Backup software reports whether a job completed. That is worth knowing and it is not the question that matters. The question that matters is whether, on a bad morning, your data and systems come back inside the time the business can survive without them. These are the nine areas we examine to answer it.

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.

Why this matters more in India right now

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.
Ask us to test whether your backups survive an admin compromise
How we audit it

Four things that make this an audit rather than a sales call.

We also sell backup services, and that creates an obvious incentive to find problems. We manage that by being explicit about it rather than pretending it does not exist.

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.

The restore test

What we actually restore, and how success is measured.

The restore test is the centre of the engagement, because it is the only step that produces evidence rather than opinion. It is supervised, performed into an isolated target so production is never touched, timed against your stated objectives, and documented. A restore that produces files but not a working system is recorded as a failure, because that is what it would be during an incident.

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
When this is worth doing

Six situations where an untested backup becomes a real problem.

The common thread is that either somebody external is about to ask, or an event is about to test the backups for you. Both are far better anticipated than met unprepared.

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.

Three positions

Assumed, backed up, or verified recoverable.

These are three genuinely different states, and organisations routinely believe they are in the third when they are in the first. The difference only becomes visible on the day it matters, which is the worst possible moment to discover it. The audit exists to move you into the right-hand column deliberately.
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
RecoveryUncertainPayment decision
How the audit runs

Four steps over 2-4 days, and the restore test is the point of all of them.

Remote-first: evidence collection and the review happen over secure remote sessions with your team, which is how we audit organisations across India from Hyderabad. The restore test is performed live in a supervised session with your engineer watching, into an isolated target, so production is never touched.
  1. 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. 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. 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. 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.

Deliverables

Four documents, each written to be handed to somebody.

Everything the audit produces is written down, dated, and usable by a named audience. Nothing is delivered as a verbal debrief that evaporates in a fortnight.
DeliverableWhat it containsWho it is for
Backup coverage mapEvery 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 resultsWhat 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 reportFindings 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 roadmapWhat 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
Straight answers

What organisations ask before booking a backup audit.

No. Evidence collection is read-only: we review job histories, configuration and access paths without changing anything. The restore test is performed into an isolated target, a separate VM, an isolated database instance, or a recovery sandbox, never over the top of a live system. Your engineer is present in the session throughout. The disruption to the business is essentially the time of the people involved, not the systems.

Then the audit has done exactly its job, because you have learned at the cheapest possible moment what an incident would have taught you at the most expensive one. A failed test in a controlled environment costs part of a day. The same failure during a ransomware event costs the business. We investigate the cause, which is usually specific and fixable: a broken chain, a missing component, an application dependency nobody documented, a repository problem. The failure, its cause and the fix all go into the report, and we re-test once it is addressed.

Microsoft keeps the service running and protects against failures of its own infrastructure, and it provides retention and recycle-bin features you should understand and use. What that does not amount to is a backup of your data under your control: recoverable to a point in time you choose, held outside the tenant, and safe from a compromised administrator inside your own organisation deleting it. The same logic applies to Google Workspace. Whether you need a third-party backup is a decision about your obligations and risk appetite, and the audit makes sure you take that decision deliberately instead of by assumption.

A full audit with a live restore test at least annually for critical systems, and after any significant change: a migration, a virtualisation or cloud move, a new backup platform, or a change of IT provider, because each of those can silently invalidate assumptions the backup design was built on. Lighter partial restore tests, a database or a single server, are cheap and worth doing quarterly. What matters more than the interval is that each test is real: isolated, timed, documented, rather than described as intended.

The audit is tool-agnostic because the questions are. Coverage, success rates, retention, immutability, credentials, alerting and restorability mean the same thing on every platform. In practice we regularly work across Veeam, Acronis, Datto, Synology Active Backup, Windows Server Backup, native database dumps and scripts, cloud-native tooling such as Azure Backup and AWS Backup, and SaaS backup products for Microsoft 365 and Google Workspace. If you run something unusual, the method still applies; we tell you up front if anything in your stack limits what the restore test can cover.

Both, but never bundled. The audit deliverable is complete on its own: the roadmap is written so your own team or your existing provider can execute it without us. If you want us to do the remediation, immutable repositories, SaaS backup deployment, retention redesign, credential separation, alerting, we quote that as separate work after the report is delivered. Keeping the two apart is deliberate: an audit that only exists to sell the fix is not an audit, and we would rather you trust the findings.

The restore test results document: what was restored, on what date, into what environment, how long it took, the recovery objectives it was measured against, and the pass or fail outcome per agreed criterion, along with the coverage map. This is precisely the artefact external auditors testing IT general controls ask for, the substantiation behind the backup questions on cyber insurance proposal forms, and a clean answer to the backup section of enterprise due-diligence questionnaires. Producing it once a year is much cheaper than improvising an answer each time somebody asks.

Yes, and the seams between them are where we look hardest, because gaps concentrate at boundaries. On-premises servers and databases, virtualised estates, workloads in Azure or AWS, and SaaS data in Microsoft 365 or Google Workspace are all in scope. Cloud workloads carry their own trap: the platform being highly available is not the same as your data being backed up, and a misconfiguration or deletion replicates to every zone just as reliably as good data does. The coverage map covers the estate as the business sees it, not as any one console sees it.

For an audit, yes, because the scope is sharp: we are answering whether your backups would restore, not redesigning your infrastructure. Reading job histories, reviewing configuration and running supervised restores parallelise well over remote sessions, and backup consoles are made to be operated remotely. Very large or heavily segmented estates can take longer, and we say so at scoping rather than discovering it mid-engagement. Where a site visit genuinely adds value, verifying offline media or an air-gapped repository physically, we schedule one from Hyderabad.

The DPDP Act does not name backup technology; it holds data fiduciaries to reasonable security safeguards to prevent breach of the personal data they process, and it imposes breach notification obligations to the Data Protection Board and affected individuals when things go wrong. Losing personal data because it was never recoverably backed up sits poorly against that standard, and backups themselves are personal-data stores you remain accountable for, which is why encryption and access control over backup data are part of this audit. Separately, CERT-In directions require covered incidents, ransomware included, to be reported within six hours of noticing them. None of this is legal advice; it is the operating reality the audit is designed around.

Running the backups is their job. Testing them is a shared responsibility that routinely falls between the parties: providers report job success because that is what their tooling measures, while a real restore test needs coordination, an isolated environment and scheduled business involvement that has to be asked for. Asking your provider when they last performed a full restore of your systems is a fair and revealing question. An independent test is not an accusation; it protects both sides. And if we run your backups under our own AMC, we tell you plainly that our audit of them is not independent, and recommend a third party for the arms-length version.

We scope and quote per organisation, driven by the number of systems, data volumes, and whether you want a focused test of critical systems or a broader exercise; there is no standard rate card because estates differ too much for one to be honest. What we will tell you free, in the first conversation, are the two questions to put to your own team today: when did we last perform a full restore, and could a domain administrator delete our backups right now. Those two answers usually tell you whether you need this and how urgently, and they cost nothing to obtain.
Backup reality check

Twelve questions to put to your own team this week.

The first group is coverage, the second is whether the backups would survive an attack, and the third is whether anybody could actually execute a recovery. Answer them honestly rather than optimistically, because an incident will.

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.
Related services

The pages around this one.

Cybersecurity Audit & Compliance

The wider security audit practice: independent assessments, penetration testing, and compliance gap analysis against ISO 27001, CERT-In and other frameworks.

Learn more

IT 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 more
References

Official documentation

Next step

Two 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.

Book a backup auditSee disaster recovery

Related Services

Explore more solutions that work great with this service

Breach Response Plan

Meet the seventy two hour notification clock

Learn more

Disaster Recovery

Business continuity and disaster recovery

Learn more

IT Infrastructure Audit

On-site audit of your Hyderabad IT estate

Learn more