Government and Law Enforcement Requests

What we require before we hand anything over, what we refuse, what we narrow, and when we tell the customer. Written for India and Australia — not adapted from US subpoena practice.

1. Our position

DECTIFY holds Customer Data as a processor. It belongs to our customers, and it is generally theirs to disclose, not ours. When an authority approaches us for it, our default is to redirect them to the customer who actually controls it.

Where we are compelled to act ourselves, we apply four rules without exception:

1. Valid legal process, every time. We do not disclose Customer Data on a request, a letter, a phone call, a verbal assurance of urgency, or a relationship. We require process that is valid on its face, issued by an authority with jurisdiction over us, and legally binding.
2. The minimum the process actually compels. We produce what the instrument names. Not the account. Not the site. Not the period around it.
3. We challenge what is defective or overbroad. Routinely, not exceptionally.
4. We tell the customer unless we are legally prohibited — and where we are, we work to have the prohibition lifted.

2. Not a DECTIFY customer?

If you are looking for footage of an incident, we almost certainly cannot help you directly. DECTIFY does not operate cameras on its own account and has no repository to search across customers. The organisation that operates the cameras holds the data and decides who sees it.

If you can identify the site, approach the operator. If you cannot, write to legal@dectify.in with the location, date and approximate time, and we will tell you whether a DECTIFY system operates there and, if so, route your request to the customer.

3. India

3.1 Process we accept

3.2 What we require on the face of it

• The issuing authority, the officer's name, designation and official identification.
• The statutory provision relied on. A demand citing no provision is not legal process.
• The case or FIR number, and the offence under investigation.
• The specific data sought, the specific site or camera, and a defined time window.
• Service on the address at Legal Notice, or to legal@dectify.in from an official domain.

3.3 What we will not do

• Provide bulk or continuous access, a live feed, or a standing query.
• Run a facial or plate search across a customer's data at an authority's request. We have no such power over customer galleries and will not acquire one.
• Act on an oral request, a WhatsApp message, or a letter on a letterhead without statutory basis.
• Accept a demand from an officer below the rank the statute requires, or from an authority without jurisdiction over us.
• Weaken security, build a backdoor, or create a capability we do not have in order to satisfy a demand.

4. Australia

4.1 Process we accept

4.2 Jurisdiction over a foreign company

DECTIFY is an Indian company with no Australian entity. An Australian instrument is not automatically binding on us in India. Where an Australian authority seeks Customer Data:

• We first direct them to the Australian customer that controls the data, which is within the authority's jurisdiction and is the proper recipient.
• Where an instrument is validly served and we are able to comply consistently with Indian law, we will do so on the terms in this policy.
• Where compliance would breach Indian law, we say so, and the authority may proceed through mutual legal assistance.

5. Cross-border requests

An authority in one country cannot compel production from a company in another simply by asking. A foreign authority seeking data held by DECTIFY in India should proceed through the Mutual Legal Assistance Treaty process via the Ministry of Home Affairs, or through letters rogatory issued by a competent court. We do not treat a direct foreign demand as binding, and complying with one would expose our customers to a disclosure their own law never authorised.

We recognise that MLAT is slow. It is also the mechanism that keeps the safeguard meaningful, and we are not the right body to decide that speed should override it.

6. Emergency disclosure

Where there is an imminent risk of death or serious physical injury, and a delay for process would be fatal, DECTIFY may disclose the minimum necessary to address that risk, without full process.

The conditions are strict, and all of them must be met:

• The request is in writing, on official letterhead or from an official domain, from a named identified officer.
• It states the specific emergency, the individual at risk, and why the data is necessary to address it.
• Legal counsel authorises the disclosure. Support engineers cannot.
• Disclosure is limited to what addresses the emergency, and nothing further.
• The affected customer is notified as soon as the emergency has passed, without exception.
• The disclosure is recorded and counted in the transparency report.

An emergency request is not a way to skip process for an urgent investigation. Urgency is not emergency.

7. Preservation

Where an authority makes a valid preservation demand, we place the identified data on legal hold and exclude it from automated deletion. Holds are as narrow as the demand permits, are recorded, are reviewed every ninety (90) days, and are released as soon as the obligation lapses. A preservation demand is not authority to disclose, and we do not treat it as one. Customers are notified of a hold on their data unless prohibited.

8. Customer notification

Our default is to notify. When we receive process for a customer's data, we tell that customer promptly and, wherever possible, before producing anything, so they can seek protective relief or respond themselves.

We delay or withhold notice only where a court order, a statutory non-disclosure provision, or a specific legal prohibition requires it. In that case we record the basis, seek to have the restriction lifted or time-limited, and notify the customer as soon as we lawfully may — including after the fact.

9. Our process

1. Intake. Everything routes to legal@dectify.in. No other team responds to an authority.
2. Validation. We verify the authority, the officer, the statutory basis and the scope. Contact details are verified independently, never from the request itself.
3. Redirect. If the customer is the proper recipient, we say so and refer the authority to them.
4. Scope review. Overbroad, vague or defective demands are challenged or narrowed in writing before anything is produced.
5. Notify. The customer is told, unless prohibited.
6. Produce. Only the minimum compelled, through a secure channel, with a certificate under the Bharatiya Sakshya Adhiniyam, 2023 where an electronic record requires one.
7. Record. Every request and outcome is logged for seven years and counted in the transparency report.

10. Evidence certification

Where a customer or a court requires certification of an electronic record we hold — that it is what it purports to be, unaltered, and produced by a system operating properly — we provide a certificate under the Bharatiya Sakshya Adhiniyam, 2023, supported by the audit log and the system integrity record. Requests go to legal@dectify.in. We charge only our reasonable cost of production, and we will not certify anything we cannot actually verify.

11. Transparency reporting

We publish, semi-annually, the number of requests received by jurisdiction and instrument type, the number complied with in full, complied with in part, and refused, the number challenged and the outcome, the number of emergency disclosures, the number of customers affected, and the number of times we were prohibited from notifying. Figures are at Compliance and Security Updates. Where we have received no requests in a period, we say so — a zero is a meaningful number.