Built to hold privileged material.

A law firm’s files are not ordinary business data. Briefs, client instructions, draft pleadings, and settlement correspondence carry professional privilege and a duty of confidentiality that follows you for the life of the matter. Chambers is engineered on that assumption.

Every practice that evaluates us asks the same three questions: where does our data live, who can reach it, and what protects it if something goes wrong. This page answers all three, plainly.

Your data stays in India

Chambers is hosted in Indian data centre regions. Your firm’s matters, uploaded documents, notes, task history, and database backups are all created, processed, and retained on infrastructure physically located within India. We do not replicate client content to overseas regions for storage, and we do not move it offshore for convenience.

This matters for two reasons. The first is legal: Indian data-protection law, and increasingly the expectations of institutional clients and in-house teams, treat the location of personal and confidential data as a substantive question rather than a technical footnote. Keeping the data in India keeps the answer simple. The second is practical: data held within the jurisdiction in which you practise is subject to the courts and the process you already understand.

Where a limited operational service sits outside India — for example, transactional email delivery or website analytics — it handles only the minimum metadata required to do its job, never your matter content or documents. Our Privacy Policy sets out how we treat personal data and any transfer of it.

Encryption in transit

Nothing travels between your device and Chambers in the clear. Every request — a page load, a document upload, a search of the Judgment Portal, a mobile session from outside the court — is carried over TLS, the same protocol that secures internet banking and payment networks.

• TLS 1.2 minimum, TLS 1.3 preferred. Older protocol versions, and the weak cipher suites associated with them, are disabled rather than merely deprecated.
• HTTPS is enforced, not offered. Plain HTTP requests are redirected, and strict transport security instructs the browser to refuse an unencrypted connection on later visits.
• Forward secrecy. Session keys are negotiated per connection, so a future compromise of a long-term key cannot be used to read traffic captured today.
• Encrypted internally too. Traffic between Chambers’ own services, and to its databases and object storage, is encrypted on the same basis as traffic from the public internet.

Encryption at rest

Data that is sitting still is encrypted too. Documents in ChamberVault, matter records, task history in ChamberFlow, search indexes, and every database snapshot and backup are encrypted using AES-256 — the block cipher standard adopted by governments and financial institutions for protecting sensitive material.

• AES-256 across the board. Encryption applies to primary storage, object storage for uploaded files, and backups alike. A backup is not a gap in the protection.
• Managed key handling. Encryption keys are held in a dedicated managed key service, separate from the data they protect, with rotation and access logged.
• Nothing readable on a recovered disk. Physical media that leaves service carries only ciphertext. A lost or decommissioned drive is not a disclosure event.

The same protection your bank relies on

When you log in to a net banking portal or authorise a UPI payment, two mechanisms do most of the work: TLS protects the connection, and AES-256 protects the stored records behind it. Chambers uses those same mechanisms, configured to the same modern standards — current protocol versions, strong cipher suites, enforced HTTPS, and encryption of every stored copy.

There is no separate, weaker grade of cryptography for smaller software. The difference between a well-built platform and a poorly built one is not the strength of the cipher; it is whether the discipline around it is applied consistently — every endpoint, every backup, every internal hop. That is the standard we hold ourselves to, and it is why we are comfortable saying your briefs are protected in transit and at rest by the same means as your bank statements.

We are deliberate about what we do not claim. Chambers is an early-stage platform, and we will not imply audits or certifications we have not completed. What we will do is describe our architecture accurately and answer specific questions directly — including from your IT team or an institutional client’s security reviewer.

Who can reach your matters

Encryption protects data from outsiders. Access control decides what your own people can see, and in a practice with associates, clerks, interns, and co-counsel, that distinction does most of the day-to-day work.

• Firm-level separation. Each firm’s workspace is logically isolated. A query scoped to one firm cannot return another firm’s records.
• Role-based permissions. Partners, associates, and support staff are granted different capabilities. Access is assigned to a role rather than negotiated file by file.
• Matter-level access. Visibility can be limited to the matters a person is actually working on — useful for conflicts, ethical walls, and short-term contract staff.
• Deliberate sharing. Documents shared with a client or co-counsel are shared through the platform with a defined recipient, rather than forwarded into a mail thread you can no longer control.
• Audit trails. Uploads, changes, shares, and deletions in ChamberVault are recorded, so “who saw this, and when” has an answer that does not depend on anyone’s memory.

Accounts and sessions

Most breaches begin with a credential, not a cipher. Accounts are protected with hashed passwords — stored using a slow, salted hashing algorithm, never in a form that could be read back — and sessions are issued as signed, expiring tokens delivered over secure, HTTP-only cookies. Sessions can be ended centrally when a device is lost or a team member leaves, and administrators can revoke a colleague’s access immediately without waiting on a password reset.

How we operate

• Least privilege. Engineering access to production is restricted to the people who need it, granted for a reason, and logged.
• No casual access to your documents. Our staff do not browse client files. Access in support of a specific request you have raised is exceptional, and treated as such.
• Automated, encrypted backups. Data is backed up on a regular schedule and restores are tested — because an untested backup is a hope, not a control.
• Patching and dependency hygiene. Operating systems, runtimes, and third-party libraries are kept current, and known-vulnerable dependencies are treated as defects to be fixed, not risks to be accepted.
• Monitoring and alerting. Application and infrastructure activity is monitored so that unusual behaviour is noticed rather than discovered later.
• Incident response. If an incident affected your data, we would tell you what happened, what it touched, and what we did about it — promptly and in plain language.

What we ask of you

Security is shared. The strongest platform in the world cannot protect a matter from a password reused on a compromised website. We ask firms to use a unique, strong password for Chambers, keep the number of accounts with administrative rights small, remove access when a colleague leaves, and lock the phone on which a session is open. Good hygiene at your end is what our controls are designed to complement.

Reporting a security concern

If you believe you have found a vulnerability in Chambers, we want to hear from you before anyone else does. Write to security@runchambers.com with enough detail to reproduce the issue. We will acknowledge your report, investigate it, and keep you informed. We will not pursue action against researchers who report in good faith, avoid accessing other firms’ data, and give us reasonable time to fix what they find.

Questions from your IT team?

If your firm or your client needs specifics — hosting regions, sub-processors, retention periods, deletion on termination, or a completed security questionnaire — write to security@runchambers.com and we will answer directly. See also our Privacy Policy and Terms of Use.