1.The principle
We comply with valid legal process. We do not comply with anything less, and we do not volunteer customer data to anyone.
A polite email from an official address is not legal process. Nor is a phone call, a request on letterhead, or an assertion that the matter is urgent. If a request would be lawful, it can be made lawfully.
2.What we require
| To obtain… | We require |
|---|---|
| Basic account information — name, email, account creation date, billing country | A valid subpoena, court order, or its equivalent under the law of a jurisdiction with authority over us. |
| Non-content records — access logs, IP addresses, timestamps | A court order supported by specific and articulable facts. |
| Content — conversations, knowledge base material, captured leads | A warrant, or a court order of equivalent standard, issued on probable cause or the local equivalent. |
| Anything at all from a non-Indian authority | Process served through a mutual legal assistance treaty, letters rogatory, or another mechanism recognised in Indian law. We are established in India and are not obliged to answer foreign process directly. |
Every request must also:
- identify the requesting authority and a named officer, with contact details we can verify independently
- identify the specific account, workspace or data sought — we reject requests that ask for everything about everyone
- state the legal authority relied on
- be within the scope of that authority
3.What we do when one arrives
- Verify it is genuine, by contacting the issuing authority through details we obtain ourselves rather than the ones on the request.
- Review it against this policy and applicable law, with legal advice where the request is significant.
- Narrow it. If a request is broader than its stated purpose requires, we push back and ask for the narrowest version that meets it.
- Notify the affected customer, unless we are legally prohibited — see clause 4.
- Produce only what is specifically required, and nothing adjacent to it.
- Log it, so it appears in our transparency reporting.
4.We tell you, unless we are forbidden to
Notice is the default, not the exception
If an authority asks for your data, we will tell you before we produce it, with enough time and enough detail for you to challenge it yourself. It is your data and the objection is yours to make.
We will not give notice where:
- a court has ordered us not to, or the law prohibits it
- there is a genuine emergency involving a risk of death or serious physical harm
- notice would be futile because the account is demonstrably fraudulent
Where a non-disclosure order has a fixed duration, we will tell you as soon as it expires. Where it does not, we will ask for one — an indefinite gag on a routine request is something we contest rather than accept.
5.What we refuse
- Requests without valid legal process.
- Requests for bulk or indiscriminate access to customer data.
- Requests to build a backdoor, weaken encryption, or provide ongoing standing access to systems.
- Requests to preserve or intercept data prospectively, without an order that specifically authorises it.
- Foreign process served directly rather than through a recognised legal channel.
- Anything that would require us to break the law of another country whose law also applies to that data.
6.What we could not produce even if ordered to
Worth stating separately, because it is a technical fact rather than a policy position — and a policy can change while a technical fact requires re-engineering.
- Passwords. They are hashed. We do not have them and cannot recover them.
- Payment card details. They never reach our infrastructure. Our merchant of record holds them, and process for them must be served on that company.
- Data we have deleted. Deletion is real, not a soft flag. Thirty days after account closure it is gone, and no order can produce it.
- Data belonging to a workspace not named in the order. Tenant isolation is enforced inside the database engine by row-level security, so producing one customer’s data does not give us casual access to another’s.
7.Emergency requests
Where an authority states in good faith that there is an imminent risk of death or serious physical injury, we may disclose the minimum information necessary to address that risk, without waiting for process. We require the request in writing from a verifiable official address, we record it, and we notify the affected customer afterwards unless prohibited. This exception is narrow and we do not treat commercial urgency, reputational risk or investigative convenience as an emergency.
8.Preservation requests
We will preserve a snapshot of specified data for up to 90 days pending valid legal process, once. Preservation is not disclosure — we hold it, nobody sees it — and if process does not follow within that period, the preserved copy is destroyed. We do not renew preservation requests indefinitely.
9.Transparency reporting
We will publish the number of government and law enforcement requests we receive, how many we complied with in full, in part, or refused, and how many customers were affected.
The current number is zero
We have received no government or law enforcement requests for customer data. When that changes, the report appears here and this paragraph goes away. Publishing a zero is only meaningful if it is maintained honestly once it stops being zero.
10.How to serve process on us
Authorities should send requests to legal@integrable.cloud with the legal basis stated and a verifiable contact for the issuing officer. We acknowledge receipt; acknowledgement is not agreement to comply.
Customers who want to know whether their data has been the subject of a request may ask at the same address, and we will tell them where we are permitted to.
Related: the DPA, which governs what we may do with customer data and includes the transfer impact assessment this policy supports; and security architecture, which describes the isolation and encryption referred to in clause 6.