Privacy Policy
What personal data Mallah Software Services Private Limited collects through Lawzer, why, for how long, who else sees it, and how a person exercises their rights under the Digital Personal Data Protection Act, 2023.
Drafted against
- Digital Personal Data Protection Act, 2023 and the rules notified under it
- Information Technology Act, 2000 — sections 43A, 72A and 79
- Information Technology (Reasonable Security Practices and Procedures and Sensitive Personal Data or Information) Rules, 2011
- Information Technology (Intermediary Guidelines and Digital Media Ethics Code) Rules, 2021
- CERT-In Directions dated 28 April 2022 under section 70B(6) of the IT Act
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.
- We host in an Indian region by design, and every sub-processor is named with the region it processes in on the Sub-processors page.
- 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 |
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 raise a GST-compliant tax invoice and to take payment | Performance of contract; and a legal obligation under the CGST Act, 2017 and the Income-tax Act, 1961 |
| 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 |
| 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 |
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.
Withdrawing consent does not undo processing that has already happened lawfully, and it does not affect processing we must continue for a legal reason — a tax invoice 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.
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 every third party that touches data, says what it does, and states the region it is configured to process in — so the actual position of this deployment is verifiable rather than asserted. Where a component is outside India it is marked as such, and Customer content is not sent to it.
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, tax records and GST returns data | 8 years from the end of the relevant financial year | Section 36 of the CGST Act, 2017 requires 72 months from the due date of the annual return; section 128(5) of the Companies Act, 2013 requires 8 years of books. We keep the longer. |
| 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. |
| Support correspondence | 3 years | The limitation period for a contractual claim under the Limitation Act, 1963. |
| Backups | 35 days, rolling | Deleted data disappears from backups as the window rolls forward. An erasure request is executed in the live system immediately and completed in backups within 35 days. |
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.