Privacy Policy

In short

Lawzer is a business tool. Almost all the personal data in it is about a Customer's own people and counterparties, put there by the Customer. For that data the Customer is the Data Fiduciary and we are its Data Processor — we act on its instructions and not on our own account.
The personal data we hold on our own account is narrow: who our account holders are, how they use the product, what they were billed, and the security logs we are required to keep.
We do not sell personal data. We do not use Customer content for advertising, and we do not use it to train models made available to anyone else.
The production database, the evidence vault, the ICT system logs and the compute are all in Mumbai. Every sub-processor is named with the region it actually processes in on the Sub-processors page, including the two that sit outside India.
We do not knowingly collect data about children, and the service is not directed at them.
A person can ask us what we hold, have it corrected or erased, nominate someone to act for them, and complain — starting at contact@lawzer.in, and escalating to the Data Protection Board of India if we do not resolve it.

1.Two different roles, and why it matters

The Digital Personal Data Protection Act, 2023 distinguishes the person who decides why data is processed (the Data Fiduciary) from the person who processes it on their behalf (the Data Processor). This policy covers both roles, because we occupy both, and a reader's rights differ depending on which one applies to them.

Data	Our role	Who to approach
Entity masters, obligations, notes, uploaded acknowledgements, challans, resolutions, minutes, contracts under review — anything a Customer puts in its workspace	Data Processor. The Customer decides what goes in and why.	The Customer. We will pass a request on to them and assist them in answering it, but we cannot answer for them.
Our own account holders: name, work email, role, designation, membership number, phone, sign-in history	Data Fiduciary	Us — see clause 7.
Billing records, GSTIN, invoices, correspondence with us	Data Fiduciary	Us
Security and access logs, IP addresses, audit trail of actions in the application	Data Fiduciary	Us
An email address given on a public compliance page — to be told before one filing is due, or to receive the monthly calendar	Data Fiduciary. No account and no workspace is involved.	Us — or the stop link in any of those emails, which needs no request.

2.What we collect, and why

Section 5 of the Act requires an itemised description of the personal data collected and the specific purpose of processing. The following is that description.

Category	Items	Purpose	Lawful basis
Account identity	Full name, work email address, password (stored only as a bcrypt hash), role, professional designation, ICSI/ICAI membership number where given, telephone number, avatar colour	To create and secure an account, to enforce role-based access, and to attribute every change in the audit trail to a person	Consent at sign-up, and performance of the subscription contract
Federated sign-in	Where Google sign-in is used: the Google account identifier, verified email address and display name returned by Firebase Authentication	To authenticate without our holding a password	Consent — the person chooses this door
Workspace and organisation	Firm or company name, state, plan	To scope data to one workspace and to bill correctly	Performance of contract
Billing	Billing name and address, GSTIN, invoice history, payment reference and the last four digits and network of a card as returned by the payment aggregator	To issue an invoice for each payment and to take payment	Performance of contract; and a legal obligation to keep books of account under section 128 of the Companies Act, 2013 and under the Income-tax Act, 2025 (the Income-tax Act, 1961, for records of tax years before 2026-27)
Usage and diagnostics	Pages requested, features used, error traces, browser and device type, approximate location derived from IP address	To keep the service working, to find and fix faults, and to decide what to build	Legitimate use — provision of the service the person is using — and consent for anything beyond that
Security logs	IP address, timestamp, user agent, sign-in success and failure, actions taken in the application	To detect and investigate unauthorised access, and to meet our reporting duties	Legal obligation — CERT-In Directions of 28 April 2022; and our own legitimate interest in securing the service
Email delivery records	For each message we send you: the address, our own reference for it, and whether the provider reported it delivered, delayed, bounced or marked as spam	To know that a reminder reached you. A message that bounced means you were not told a filing was due, which we cannot see from the fact that it was sent. Repeated bounces or a spam complaint also stop us writing to that address, which protects the delivery of everybody else’s reminders	Legitimate use — provision of the service you are using — and, for the records of a complaint, our own interest in not sending unwanted mail
Trial emails	Name, work email, role, the date the account was created and last used, and counts drawn from the workspace — how many companies, obligations and documents it holds, and the next obligation falling due	While a workspace is on trial, a short email every few days to help its members use the service — getting started, what the calendar found, inviting colleagues — and to say when the trial ends. At most one a day, and none after the trial ends	Legitimate use — provision of the service you signed up for. Every one carries a link that stops the rest on the first click, and they can be turned off in Settings
Offers and product news	Name, work email, workspace name and trial dates, and when consent was given and withdrawn	Occasional emails about prices and the product, sent only to workspace administrators who asked for them	Consent, given by ticking a box that is never pre-ticked at sign-up, by answering yes to a one-time question in the application (where no is offered on equal terms), or by turning it on in Settings; withdrawn from any such email or from Settings
Support correspondence	What you write to us and our replies	To answer the question and to keep a record of what was agreed	Performance of contract
Monthly compliance calendar	Email address, the legal form and state of the company, and the list of obligations the calendar came to	To send one email on the first of each month listing which of those obligations fall due that month	Consent, confirmed by following a link sent to the address — nothing is sent until it is followed
Deadline alerts	Email address, the one obligation it was asked about, the page it was asked from, and the times consent was confirmed and withdrawn	To send one email before each occurrence of that obligation falls due, and nothing else. The page is kept as the record of what the person was shown when they asked. The confirmation email names the IP address the request came from, so that someone who did not make it can see where it did come from; we do not store that address	Consent, confirmed by following a link sent to the address — nothing is sent until it is followed

What we do not collect

The compliance calendar on the public site asks for turnover, paid-up capital, net worth, net profit and headcount in order to work out which obligations bind a company. If you then ask for the monthly email, those figures are not kept: the list of obligations they produced is stored and the figures themselves are discarded. They are the most commercially sensitive thing a visitor hands over, the monthly email never needs them again, and a consequence worth knowing is that a company crossing a threshold will not silently acquire obligations in that email — the calendar has to be built again. We do not ask for and do not want: Aadhaar numbers, biometric data, health data, caste or religion, political affiliation, sexual orientation, or full payment card numbers. We do not run behavioural advertising and we have no advertising trackers. A Customer should not upload documents containing an Aadhaar number where the purpose can be served without it; where an Aadhaar-bearing document is genuinely required as statutory evidence, it should be redacted to the last four digits before upload.

3.Consent, and how to withdraw it

Where we rely on consent, it is asked for in plain language, for a stated purpose, and by a clear affirmative action — never a pre-ticked box and never inferred from continued use. Section 6(1) of the Act requires consent to be free, specific, informed, unconditional and unambiguous, and we do not make access to the service conditional on consent to anything the service does not need.

Consent can be withdrawn as easily as it was given. Non-essential cookies are refused or later turned off from the cookie banner and the privacy controls in Settings; marketing email is stopped from the unsubscribe link in any such email or from Settings.

Deadline alerts and the monthly compliance calendar, which anyone may ask for from the public compliance library without holding an account, work the same way at both ends. Typing an address does not subscribe it: we send one email to that address with a link, and nothing further is sent unless the link is followed, because typing an address is not evidence that the person who typed it owns it. Every alert carries a link that stops it on the first click, with nothing to fill in and no sign-in. We record when consent was confirmed and when it was withdrawn, and we keep that record after withdrawal — a deleted record cannot show that we stopped when we were asked to.

Withdrawing consent does not undo processing that has already happened lawfully, and it does not affect processing we must continue for a legal reason — an invoice already issued cannot be unissued. Where withdrawal means we can no longer provide part of the service, we will say so before you confirm.

Some processing does not rest on consent at all. Sections 7(a) and 7(b) of the Act permit processing for a purpose for which the person has voluntarily provided their data and has not objected, and for employment purposes. Keeping the account you asked us to create, and the security logs that protect it, fall there.

4.Children

The service is a professional tool sold to organisations and is not directed at children. We do not knowingly create an account for a person under eighteen.

Section 9 of the Act requires verifiable parental consent before processing a child's personal data, and prohibits tracking, behavioural monitoring and targeted advertising directed at children. We do none of those things for any user, of any age. If we learn that an account belongs to a child, we will disable it and delete the associated personal data.

5.Who else sees the data

We share personal data only in the situations below, and only to the extent each needs.

Within the Customer's own workspace: Users see what their role permits. An administrator sees the whole workspace; a company secretary and an accountant see the entities in the practice's portfolio; an auditor has read-only access; a business user sees only the entities they are named on. This is enforced in the software, not by policy alone.
Our processors: Infrastructure, database, file storage, email delivery, error monitoring and payment processing are provided by third parties under written contracts that bind them to process only on our instructions, to keep the data secure and to return or delete it when we say. Each is named on the Sub-processors page, which is versioned so a change is visible.
Professional advisers: Our own auditors, lawyers and accountants, where they need it to advise us, under professional duties of confidence.
Government and law enforcement: Where we are legally obliged. We require lawful written process — a court order, or a written request from an agency authorised to make it under section 69 of the IT Act, 2000 or rule 3(1)(j) of the IT Rules, 2021 — we satisfy ourselves it is properly issued, we disclose only what is asked for, and we tell the affected Customer unless the law forbids it. We publish nothing about individual requests but will report aggregate numbers on request.
A successor: In a merger, reorganisation or sale of the business, on notice to Customers and on terms no less protective than this policy.

6.Where the data is, and cross-border transfer

Our design target is that the production database, the evidence vault and the backups sit in an Indian region, and the application’s compute is pinned to Mumbai. This is a deliberate choice rather than a strict legal requirement: section 16 of the Act permits transfer outside India except to a country the Central Government has notified as restricted, but Indian statutory records are easier to produce, audit and litigate over when they have not left the country.

We do not ask you to take that on trust. The Sub-processors page names each component, what reaches it and the region it actually processes in, and is the authority rather than this paragraph. As at 24 September 2026 the target above is also the position: the database, the evidence vault, the system logs and the compute are all in Mumbai. The two components outside India are email delivery and, where enabled, federated sign-in; that page marks both and states what reaches them. For part of September the database was in fact in the United States while this section described the target as though it were the configuration — recorded here rather than quietly corrected, because a page whose purpose is that the position be verifiable should show its own corrections.

A Customer that requires a contractual data-residency commitment, rather than a configuration we describe, should ask for one. It is available on an enterprise plan and is recorded in the order form, where it becomes enforceable.

We will not transfer personal data to a country notified as restricted under section 16(2) of the Act, and we monitor that list.

7.Your rights, and how to use them

Chapter III of the Act gives a Data Principal the following rights against a Data Fiduciary. Where we are the Data Fiduciary — our own account holders, billing and logs — exercise them with us. Where the data sits in a Customer's workspace, exercise them with that Customer; see clause 1.

Right	Section	What we do
Access — a summary of the personal data we hold about you, the processing activities, and the identities of anyone we have shared it with	s.11	Answered within thirty days of a verified request, in a machine-readable export where you want one.
Correction, completion and updating of inaccurate or incomplete data	s.12(1)	Most of it you can change yourself in Settings. Anything you cannot, we correct within thirty days.
Erasure of data no longer needed for the purpose it was collected for	s.12(2)	Done within thirty days, except where retention is required by another law — clause 8 lists each case and its period.
Grievance redressal, before approaching the Board	s.13	Acknowledged within 24 hours and disposed of within 15 days.
Nomination of another person to exercise your rights in the event of death or incapacity	s.14	Recorded on written request identifying the nominee.

Write to contact@lawzer.in. We will verify that the request comes from the person it concerns — usually by confirming control of the registered email — because acting on an unverified request is itself a breach. Requests are free. Where a request is manifestly excessive or repetitive we will say so and explain why rather than quietly ignore it.

8.How long we keep things

Section 8(7) of the Act requires personal data to be erased once the purpose is no longer being served and retention is not required by law. These are the periods we apply.

Data	Retained for	Why that period
Workspace content — entities, obligations, evidence, notes	The subscription term, then 30 days' export access, then erased within 60 days	The Customer needs its statutory records while it is a customer and needs time to take them away when it stops.
Account identity	While the account is active; 90 days after deactivation	A short window so an account closed by mistake can be restored.
Audit trail of actions in the application	8 years	It evidences who did what to a statutory filing, and is relied on in secretarial audit under section 204 of the Companies Act, 2013.
Invoices and tax records	8 years from the end of the relevant financial year	Section 128(5) of the Companies Act, 2013 requires 8 years of books of account.
ICT system and access logs	180 days, in India	Mandated by the CERT-In Directions of 28 April 2022.
Trial workspaces	30 days after the trial ends	Long enough to decide, short enough not to hold data nobody is paying attention to.
Which trial emails were sent, and when consent to offers was given or withdrawn	As long as the account	So that no message is sent twice, and so that we can show we had consent for every offer we sent and stopped when asked.
Support correspondence	3 years	The limitation period for a contractual claim under the Limitation Act, 1963.
Email delivery records	180 days	They decide whether we may write to an address, and that decision reads the last 90 days — so the records have to outlive the window that reads them, or an address would quietly stop being suppressed and start receiving mail again.
Deadline alerts and monthly calendar subscriptions	A request never confirmed: 30 days. A confirmed one: until it is withdrawn, then 3 years. Erased sooner on request.	An address that was typed but never confirmed carries no consent at all, so it is deleted rather than held on the chance it was meant. A withdrawal is kept because section 8(5) of the Act requires us to be able to demonstrate that consent was given, and the record of the withdrawal is the only thing that shows we honoured it — three years being the limitation period under the Limitation Act, 1963. Both are swept nightly.
Backups	30 days, in India	The database is dumped nightly to encrypted storage in Mumbai and each dump is deleted 30 days later. This is the one retention period that works against you rather than for you: an erasure request is executed in the live database immediately, but the person erased persists in the backups taken before it until the last of those rolls off, so erasure completes within 30 days rather than at once. Section 8(7) of the DPDP Act, 2023 permits retention where another law requires it, and the same books and audit trail obligations named in the rows above apply to the copies. We do not reach into a backup to remove one person, because editing a backup is how you discover during a restore that it no longer restores.

9.How it is protected

Section 8(5) of the Act requires reasonable security safeguards. The Information Security Policy sets ours out in full; in outline:

Encryption in transit (TLS 1.2 or better, HSTS enforced) and at rest.
Passwords stored only as bcrypt hashes, never recoverable, and checked against a denylist of commonly guessed values.
Session cookies that are httpOnly, SameSite and — in production — Secure, signed with HS256 and validated against the live user record on every request, so revoking access takes effect immediately rather than when a token expires.
Every query scoped to one workspace at the data-access layer, so a request cannot reach another Customer's records even if a URL is guessed.
Role-based access enforced server-side, not by hiding buttons.
Rate limiting on sign-in and sign-up, and a content security policy that forbids framing the application.
An append-only audit trail of every state change, reassignment, override and upload.
Least-privilege access for our own staff, granted on need and reviewed quarterly.

10.Automated decisions

The software decides things automatically: which statutes bind an entity, what date an obligation falls on, who it is assigned to, what the penalty exposure is, and what an entity's health score is. Those are decisions about an organisation and its filings, not about a person.

Two of them touch individuals indirectly — work is auto-assigned to a named professional, and reports show workload and on-time performance by person. Neither is used by us for any purpose; they are visible to the Customer and are the Customer's to act on. Every automated decision records its reason in plain English and can be overridden by a professional, and an override is never silently reversed by a later automation pass.

We do not profile individuals, score them for creditworthiness, or make any decision about a person by automated means that has a legal effect on them.

11.Contact and complaints

Questions about this policy or about how we handle personal data go to contact@lawzer.in. Complaints go to the Grievance Officer at contact@lawzer.in; the Grievance Redressal page names the officer, states the timelines and sets out the escalation path.

If we do not resolve a data-protection complaint to your satisfaction, you may complain to the Data Protection Board of India under section 13(3) of the Act. We will not treat a complaint to the Board as a reason to restrict your account.

12.Changes to this policy

When we change what we collect, why, who we share it with or how long we keep it, we publish a new version with a new number and date, and we give notice under section 5(3) of the Act — by email to account holders and by notice in the application — before the change takes effect. Where the change needs fresh consent, we ask for it rather than assume it.

Drafted against