Understanding Your Responsibility in iManage Cloud Data Resilience

For more than three decades, law firms have relied on iManage to manage their institutional knowledge, active matters, and confidential client data. Historically, that deployment model lived on premises, where firms deployed the infrastructure, secured the environment, controlled the storage, and decided exactly how data was backed up and recovered. They owned both the deployment and the protection. 

Today, that model has shifted. With law firms rapidly moving to SaaS and cloud, it has fundamentally changed how law firms think about infrastructure, uptime, and disaster recovery. With the migration to iManage Cloud, customers get the convenience of not having to manage infrastructure, build redundancy, and maintain disaster recovery environments.  

But as our friendly neighbourhood hero would say (perhaps in a parallel universe): ‘With great convenience comes great responsibility.’ 

iManage Cloud operates under a shared responsibility model, where iManage protects the platform and customers remain responsible for protecting their data. In this article, we break down where iManage’s responsibility ends and where yours begins, moving beyond marketing language and into architecture, recovery design, and real-world risk scenarios. 

What Is the Shared Responsibility Model? 

The shared responsibility model is foundational to modern SaaS platforms.  

In every modern SaaS environment, responsibility is divided between the vendor and the customer. The vendor is responsible for the availability, infrastructure, and security of the platform. That includes compute, storage durability, scalability, encryption, and disaster recovery at the service level. 

The customer is responsible for how the platform is used. That includes access controls, retention policies, lifecycle management, and ultimately the recoverability of business data. 

The cloud removes the burden of managing infrastructure, it does not remove ownership of outcomes. This distinction becomes especially important in legal environments where document integrity, auditability, and recoverability are mission-critical. 

System Recovery vs Document Recovery 

Before diving into architecture and capabilities, we need to clarify a fundamental difference between system recovery and document recovery. While they are both critical to customers, they solve different problems and belong to different owners. 

System Recovery 

System recovery is about restoring the platform itself. It includes: 

• Rebuilding services in a secondary redundant region 
• Restoring databases and indexes 
• Recovering storage infrastructure 
• Leveraging the cloud provider’s replication and soft-delete mechanisms 

System recovery is designed for catastrophic events and is part of iManage’s service-level commitments. But it does not guarantee that an accidentally deleted workspace within a customer’s library can be restored on demand. 

Document Recovery 

Document recovery is about customer or tenant-level recovery. It includes: 

• Restoring accidentally or maliciously deleted documents 
• Restoring overwritten versions 
• Recovering from ransomware attacks 
• Restoring content from Trash 
• Recovering from internal misconfiguration 
• Recovering from tenant compromise or malicious deletion  

Document recovery is where most day-to-day business risk actually lives and this is where shared responsibility becomes visible.  

iManage Cloud has two primary native features that help with document recovery: 

• Trash 
• Journal 

We’ll explore these recovery options in detail further into the article. For now, what we need to understand is that iManage owns system recovery and customers own document recovery. 

That boundary defines shared responsibility. 

iManage Cloud Architecture: Built for Availability 

iManage Cloud runs on Microsoft Azure and leverages Azure’s availability and redundancy capabilities. 

Within each iManage supported region, the iManage Cloud service is deployed across three Azure Availability Zones. These zones are physically separate data center within a region. If one zone fails, traffic automatically continues flowing across the remaining zones with no impact to users. 

Azure also provides Geo-Zone-Redundant Storage (GZRS), in which data written in the primary region (let’s say East US) is asynchronously replicated to a paired secondary region located hundreds of miles away. So, if an entire region becomes unavailable, services can be redeployed in the paired or secondary region and access can be restored. 

This architecture delivers high durability, regional failover capability, and infrastructure-level disaster recovery.  

This protects against: 

• Data center failure 
• Availability zone outages 
• Regional disasters 
• Infrastructure corruption 

This is robust, resilient, and enterprise-grade. But availability is not the same thing as tenant-level backup. 

Inside iManage Cloud’s Recovery Safety Net  

Many iManage customers may also be familiar with a 90-day retention period, within which modified or deleted data can be recovered with the help of iManage support. This is different from the Trash or Journal capabilities as this is not customer-facing and can only be recovered by iManage support. Customers cannot directly browse this recovery layer, select restore points, initiate a rollback, or define the retention duration. 

Let’s look at how this works.  

At the underlying storage layer, Azure Blob Storage maintains a soft-delete state for modified or deleted objects for up to 90 days, after which that data is purged forever. This enables iManage to recover modified or deleted data objects for up to 90 days, but this capability is explicitly intended for system recovery purposes in case of large-scale failure, corruption, or disaster. 

It does not exist to provide: 

• Operational document recovery 
• Long-term retention 
• Granular document-level recovery 
• Compliance retention controls 
• Backup archives 

This is not a backup solution. It is a system-level safety net. 

Native Recovery Capabilities and Their Limitations 

As we touched on earlier, iManage Cloud offers a few native recovery capabilities. Let’s do a deep dive into what they are. 

Trash / Recycle Bin 

When a user deletes a document, it moves to Trash for a limited period before it’s purged forever.  

Key characteristics: 

• Documents remain in Trash indefinitely unless explicitly purged. 
• Administrators can restore items. 
• Items retain original metadata and version numbers. 

Limitations: 

• Once purged, the data is permanently gone. 
• Trash applies to documents only. 
• Retention period is often low to avoid unnecessary storage space costs and overages. 
• It does not protect against mass deletion scenarios outside of retention windows. 

Journaling  

Every time a document is modified, iManage creates a secondary copy of the previous state to the Journal. This is a great way to protect against accidental overwrites. Customers can simply rollback to a previous rendition from the Journal.  

Limitations: 

• Journals can be purged and are typically retained only for a limited period.  
• Once purged, recovery is not possible. 
• Applies to document objects only. 

Export / Import API 

iManage provides APIs that allow bulk export and restore operations that can be used to extract data periodically and re-ingest that data back to the library.  

Limitations: 

• Limited granularity. 
• May not preserve full structure or metadata in all scenarios. 
• Manual scripting is operationally complex. 
• High risk of data corruption and overwrites. 

These native recovery features are good for targeted document recovery but they are not replacement for enterprise-grade backup and recovery.  

Let’s understand a little more about why you need backup and recovery capabilities that native features won’t be able to cover.  

Ways Data Can Be Lost in iManage Cloud 

There are several ways law firms can lose their iManage Cloud data and some of iManage documentation itself outlines multiple scenarios where data loss can occur. 

These include: 

• Accidental or malicious deletion by a user 
• Accidental overwrite of a document 
• Purging of Trash 
• Catastrophic regional disaster 
• Cyberattacks like ransomware 
• Automations or third-party failures 
• Infrastructure corruption 
• Administrative misconfiguration 
• Policy-based deletion 
• Retention expiration 
• Large-scale deletion  or clean-up events 
• Incorrect use of Shred API endpoints 

Some of these are operational, some are administrative, and some are disaster-driven, but none of these are hypothetical. In conversations with law firms, we’ve seen incidents ranging from the loss of a single document to the accidental deletion of entire workspaces. 

Your Responsibility in Business Continuity Planning 

Business continuity in the cloud and SaaS era must account for realistic tenant-level events. This means you need more than just restore-from-trash workflows. Whether it’s a misconfiguration or a service downtime, you need to ensure that your business is running and your commitments are met.  

Business continuity planning must account for: 

• How quickly can users get access to documents they’re currently working on? 
• Does the process align with the security requirements of the law firms? 
• Can we restore to a specific date and time? 
• How easy is it to access the recovered data? 
• Can we get immediate access to the most critical data?  
• Can we restore to a different region if necessary? 

These are only some of the questions you should be asking about your business continuity process and if those answers rely solely on native SaaS features, there are serious gaps. 

HYCU: The Independent Data Protection for iManage Cloud 

Independent backup is not a challenge to iManage’s resilient architecture, it is a recognition of the shared responsibility model. 

Just as Microsoft 365 customers deploy backup for Exchange and SharePoint and Salesforce customers deploy backup for their CRM data, iManage Cloud customers must consider independent protection for their document repositories. 

iManage and HYCU partnered in 2024 to offer customers an official data protection and business continuity solution for iManage Cloud customers.  

This independent layer provides: 

• Granular, on-demand restore 
• Immediate alternate access to critical data 
• Customer-controlled storage and retention 
• Control over data and residency 
• Full coverage of iManage Cloud data 
• Reliable and automated backup management 
• Immutable, ransomware-proof data recovery  
• Enterprise-grade encryption and security of data 

Most importantly, it shifts recovery control from vendor discretion back to the customer. 

Final Thoughts 

iManage Cloud delivers a highly resilient platform built for uptime, redundancy, and operational continuity. But platform resilience is not the same as customer-controlled data recovery. 

Documents can still be deleted, overwritten, purged, corrupted, or impacted by operational mistakes and policy-driven actions. Native recovery capabilities help address some of these scenarios, but they are not designed to function as independent backup and long-term business continuity solutions. 

That is the core of the shared responsibility model, and understanding your role in it is critical to the continuity of your business operations.  

iManage protects and operates the platform. Customers remain responsible for defining how their data is protected, retained, recovered, and made available during disruption. 

If you're attending iManage ConnectLive in London, or attended New York or Chicago earlier and want to learn more about protecting and recovering your iManage Cloud data, we're here to help.