Draft: to be checked by Lingsaa's lawyer before the first client. First drafted on 6 October 2026 and brought up to date on 26 October 2026 with what the CCC really does now (sealed keys, the customer's own key, data regions, the export, erasure and deletion flows). Not legal advice and not yet agreed text. Every point marked [lawyer to confirm] is an assumption or an interpretation that must be confirmed before use. Where these terms describe what the software does, they say where that is documented, so the description can be checked against the product. Lingsaa's own details marked [to be filled by Lingsaa] are never guessed.
1. Parties and roles
1.1 The Customer (the organization that subscribes to Lingsaa CCC and the Lingsaa apps) is the Data Fiduciary for the personal data its people and its own contacts put into the service: its staff, visitors, customers, suppliers, applicants and anybody else whose data it records.
1.2 Lingsaa ([legal name, registered address and CIN to be filled by Lingsaa]) is the Customer's Data Processor for that data. Lingsaa processes it only to provide the service the Customer subscribed to, as the Customer instructs.
1.3 For the data Lingsaa needs to run the account itself (the Customer's admins and billing contacts, invoices, payments, the record of who accepted Lingsaa's terms, and sign-in records of Lingsaa's own staff), Lingsaa decides the purposes and is a Data Fiduciary in its own right. These terms do not cover that data; Lingsaa's Privacy Policy does. [lawyer to confirm]
1.4 The service is: Lingsaa CCC (the Command and Control Center) and the Lingsaa apps and modules the Customer's plan includes (for example HRMS, Visitor, Gate, CRM, Finance & Accounts, Documents, Assets, Projects, Cafeteria), with their web and phone apps and the Lingsaa Edge software at the Customer's sites.
2. What is processed
2.1 Categories of Data Principals: the Customer's staff and contractors; visitors and residents; the Customer's own customers, leads and contacts; suppliers and payees; people whose documents the Customer files; anybody else the Customer records.
2.2 Categories of personal data, depending on the apps used: names, contact details, employee and identity records, attendance and access records, photographs and face templates where the Customer uses face sign-in or face recognition, camera footage and events, documents and their contents (which may include PAN, Aadhaar and contracts), financial and payroll data, messages, call records and meeting notes where switched on, location at sign-in where the Customer's rules ask for it, computer-use records where the Customer uses monitoring, and logs of use.
2.3 Purpose: only to provide, secure and support the service. Lingsaa does not sell personal data, use it for advertising, or train any model on it.
2.4 Children's data: the service is not designed for processing children's personal data. If the Customer processes such data (a school, for example), obtaining the verifiable consent required by section 9 of the Act and rules 10 and 11 is the Customer's responsibility. [lawyer to confirm]
3. Lingsaa's duties as Data Processor
3.1 Instructions. Lingsaa processes the Customer's personal data only on the Customer's documented instructions. The agreement, the Customer's settings in the service, and the actions its people take in the service are those instructions. Lingsaa tells the Customer if it believes an instruction breaks the law.
3.2 Confidentiality. Everybody at Lingsaa who can reach the Customer's data is bound by confidentiality.
3.3 No standing access by Lingsaa staff. Lingsaa staff have no standing access to the Customer's data in the apps:
- Staff may open a Customer's records only through Lingsaa support access: the Customer's admin grants one named staff member access to one app (or all), for a stated reason, for at most 24 hours, look-only unless the admin allows changes, and can withdraw it at any moment. Every grant, use, withdrawal and end is written to the Customer's audit trail, and the Customer's admins are alerted when access is given, first used and ended (docs/INTEGRATION.md, "Lingsaa support access").
- Co-browsing (Lingsaa support seeing one CCC page with a person) happens only after that person's own Yes, shows no typed values, and ends on Stop, sign-out or after 30 minutes (docs/SUPPORT-LEVELS.md).
- Staff never move or approve the Customer's money (bank accounts, payees, payments), even with support access that allows changes.
- Lingsaa's staff see each organization's audit trail in numbers only, never its entries, without a support grant (docs/AUDIT.md).
3.4 Security safeguards as set out in clause 4 and Schedule 1.
3.5 Help with Data Principals' rights. Lingsaa gives the Customer, in the service, the means to answer requests under sections 11 to 14 of the Act (docs/PRIVACY-REQUESTS.md): a person asks once (signed in, on the Customer's public privacy page after a one-time code, or recorded by staff), the request goes to the CCC and to every Lingsaa app the Customer uses, each answers for its own records, and the person gets one answer; an erasure waits for a person of the Customer with the Approve right, never the person themselves; complaints go to the Customer's grievance officer; every step is recorded. Lingsaa forwards to the Customer, without answering it, any request it receives directly from a Data Principal.
3.6 Help with breaches as set out in clause 5.
3.7 Sub-processors only as set out in clause 6.
3.8 Export, deletion and return as set out in clause 8.
3.9 Information and audits as set out in clause 9.
4. Security safeguards (rule 6)
4.1 Lingsaa keeps, for the Customer's data, at least the safeguards rule 6(1) lists. Schedule 1 maps each clause of rule 6(1) to what the service does today and to what Lingsaa still has to confirm in operation.
4.2 Sealed keys. Every secret the service keeps for the Customer (app keys, mailbox and app passwords, two-step secrets, keys of connected services) is sealed in the database with Lingsaa's data key, never kept in plain text: the key is a list so it can be rotated (older values are sealed again by a rotation job), and each use has its own key derived from it (HKDF), so a key for one purpose never opens another's. Passwords and recovery codes are kept only as one-way hashes. Keys to outside services are kept by reference in Lingsaa's key store, never in the code (docs/OUTSIDE-SERVICES.md).
4.3 The Customer's own key. For a Customer on a dedicated copy, Lingsaa plans to offer encryption of that copy's database and files with a key the Customer holds in the hosting provider's key service (the CCC's data key wrapped by the Customer's key; the Customer may revoke it, and the copy then stops). It is not built or offered yet; when it is, its terms go in the Customer's order form (docs/TRUST.md, "Bring your own key"). [lawyer to confirm the wording once it exists]
4.4 Lingsaa reviews these safeguards at least once a year and after any personal data breach, and does not reduce them during the agreement.
4.5 Logs (rule 6(1)(e) and rule 8(3)). Lingsaa keeps the logs of processing it holds for the Customer (the audit trail of who did what, sign-in records, and the access logs of documents) for at least one year, and, for logs of its ICT systems, at least the 180 days within India that the CERT-In Directions require. The CCC's audit trail is tamper-evident (each entry sealed into a hash chain, each chain's last entry signed once a day: docs/AUDIT.md) and kept for 10 years by Lingsaa's setting (never less than one year). [lawyer to confirm: whether rule 8(3)'s one-year minimum applies to every Data Fiduciary using the service, given its reference to the Seventh Schedule's purposes; and how it combines with rule 6(1)(e)]
Engineering note, to confirm before signature: the Documents app deleted sign-in attempt records after 30 days (crud/login_throttle.purge_old); that must keep at least one year, or those records must be copied into a log kept that long.5. Personal data breaches (rule 7)
5.1 Lingsaa tells the Customer without undue delay, and in any case within 24 hours of becoming aware of a personal data breach affecting the Customer's data, so that the Customer can meet its own duties. [lawyer to confirm: the period to commit to. The Rules set none for a Data Processor; 24 hours leaves the Customer room within the Board's 72 hours]
5.2 Lingsaa's notice includes, as far as it knows at the time, what the Customer needs for rule 7(1) (to each affected Data Principal: the nature, extent and timing of the breach, its likely consequences, the measures taken, the safety steps they can take, and a contact) and for rule 7(2) (to the Data Protection Board: a description without delay, and within seventy-two hours of becoming aware, or such longer period as the Board allows on a written request, the detailed facts, causes, mitigation, findings about who caused it, remedial measures, and a report on the intimations to Data Principals). Lingsaa updates the notice as it learns more.
5.3 The Data Fiduciary (the Customer) makes the intimations to the Board and to Data Principals (section 8(6) of the Act). Lingsaa does not notify them itself unless the Customer asks it to or the law requires it to. [lawyer to confirm]
5.4 CERT-In. Separately, Lingsaa reports cyber incidents of the kinds listed in the CERT-In Directions to CERT-In within 6 hours of noticing them, as those Directions require of service providers and body corporates. [lawyer to confirm: how this report and the Customer's DPDP intimation fit together, and what Lingsaa may tell CERT-In about the Customer]
5.5 Lingsaa takes reasonable steps at once to contain the breach and limit its effects, keeps the evidence, and helps the Customer's investigation.
6. Sub-processors
6.1 The Customer authorises Lingsaa to use the sub-processors in Schedule 2. Lingsaa gives the Customer at least 30 days' notice of a new sub-processor (by email to the Customer's admins and in the CCC); the Customer may object on reasonable data-protection grounds, and if the parties cannot resolve it the Customer may end the affected service. [lawyer to confirm: notice period and remedy]
6.2 Lingsaa puts each sub-processor under written terms that protect the data at least as well as these terms, and stays responsible to the Customer for them.
6.3 Optional services the Customer switches on. Some features send data to a provider only when the Customer chooses to use them: each AI feature has its own switch on the Customer's AI rules page, and every use is in the Customer's AI log (docs/AI-RULES.md); a provider the Customer connects with its own account and key (for example its own WhatsApp number or mailbox) acts for the Customer. [lawyer to confirm: whether such providers are sub-processors of Lingsaa or processors engaged by the Customer]
7. Where the data is kept, and transfers outside India
7.1 Data region. Each organization, and each company inside it, has a data region; it is India (in) by default and today the only region offered (core.tenant.data_region, companies.data_region). The service runs on Lingsaa's hosting provider, Utho, in India. [to be confirmed by Lingsaa operations: the Utho data centre(s) in use for every app, every database and every backup]
7.2 Some sub-processors in Schedule 2 may process limited data outside India (for example a messaging provider's servers). Section 16 of the Act allows transfer outside India except to countries the Central Government restricts by notification, and rule 15 requires meeting any requirements the Government specifies by order about making data available to a foreign State or its agencies. Lingsaa will not transfer the Customer's data to a country so restricted and will follow any such order. [lawyer to confirm: whether any notification under section 16(1) or order under rule 15 is in force, and sector rules such as the RBI's on payment data that may apply to the Customer]
8. Export, deletion and return
8.1 Export at any time. The Customer's main admin (Client Super Admin) can download a full export of the organization's records at any time, after confirming it is them and where the organization's own download rule allows it: every table holding the organization's records and its audit trail, one CSV each, and every stored file, in a zip encrypted as it is written, ready for 24 hours and at most 3 downloads; personal details are masked as on screen unless the admin holds the right to see them in full; passwords, keys, tokens and biometric templates are never exported. Every admin is told of each export (docs/TRUST.md, "Your data, any time"). Each Lingsaa app exports its own records itself.
8.2 A person's erasure. When a person's erasure is confirmed (clause 3.5), the CCC erases their account's personal details at once and keeps, under "Erased person", only what a law makes the Customer keep, each listed with its reason in the answer (docs/PRIVACY-REQUESTS.md). Each Lingsaa app erases its own records and says what it kept and why.
8.3 When the agreement ends, the organization becomes "leaving" first: for 30 days only its main admins can sign in, everything is read-only, and the full export stays available. Nothing is deleted in that time.
8.4 Deletion. After the 30 days, the Customer's records are deleted from the live systems: one Lingsaa person asks (after a dry run that counts what is deleted and kept, table by table) and a second, different Lingsaa person approves; every rule is checked again at the approval; a legal hold (the Customer's or Lingsaa's) or a wallet not yet settled stops it. The deletion runs table by table and Lingsaa issues a deletion certificate (its number, the organization, the date, both people, what was deleted and what is kept and why). Copies in backups age out within 12 months on their normal cycle and are never restored except to recover the service as a whole. This also meets section 8(7)(b) of the Act, under which the Data Fiduciary must cause its Data Processor to erase data made available to it. The Customer may ask in writing for the deletion sooner. [lawyer to confirm: the 30 days and the 12 months]
8.5 What the law makes Lingsaa keep after deletion, each listed on the certificate (docs/TRUST.md, "When a client leaves"): Lingsaa's tax invoices to the Customer and the buyer's details on them (CGST Act 2017, s.36; Companies Act 2013, s.128(5); the contact person's name, email and phone are blanked), the wallet's ledger and refunds, the organization's own row (its name blanked), the audit trail, the deletion's own record, and the record of who accepted Lingsaa's terms. [lawyer to confirm each period]
8.6 Each Lingsaa app deletes its own records of the Customer on Lingsaa's request when the CCC's deletion runs. [to be confirmed by Lingsaa operations: today the apps' part is started by Lingsaa's staff; the CCC sending it to every app by itself is planned]
9. Information and audits
9.1 Lingsaa makes available the information needed to show it meets these terms: this document, the security documentation (the Trust centre, docs/SECURITY.md and Schedule 1), and summaries of independent security assessments as Lingsaa has them.
9.2 The Customer, or an independent auditor it appoints under confidentiality, may audit Lingsaa's compliance once a year on 30 days' notice, and after a personal data breach, without disturbing other customers' data or Lingsaa's operations. Each party bears its own costs unless the audit finds a material breach by Lingsaa. [lawyer to confirm]
9.3 The Customer can see much of this itself, at any time, in the CCC: its audit trail (filters, and a download with the proof that nothing was changed), every Lingsaa support access grant and its use, its consent records, its AI log and its security rules.
10. General
10.1 If these terms and the rest of the agreement conflict about personal data, these terms win.
10.2 These terms last as long as Lingsaa processes the Customer's personal data.
10.3 If the law changes (for example a new notification under the Act or the Rules), the parties will amend these terms in good faith to keep them lawful. A new version is accepted as the Terms of Service (section 14) describe.
10.4 Liability under these terms follows the agreement's liability clause. [lawyer to confirm: penalties under the Schedule to the Act fall on the Data Fiduciary; how indemnities between the parties should reflect that]
Schedule 1: rule 6 safeguards, mapped to the service
Rule 6(1) of the Rules, clause by clause. "Does today" is what the software does as documented; "To confirm" is what Lingsaa must confirm in operation before signature.
| Rule 6(1) | Does today | To confirm |
|---|---|---|
| (a) Encryption, obfuscation, masking or virtual tokens | Secrets sealed with the CCC's data key (a rotating list, one derived key per purpose); passwords and recovery codes only as hashes; backups encrypted (AES-256-GCM, in parts that show any change); the full export encrypted as it is written; personal details masked on screen and in exports unless a person holds the right to see them in full; Aadhaar-like numbers masked before any AI call; sign-in tokens between the CCC and the apps signed (RS256) and short-lived. | HTTPS (TLS) on every public address; encryption at rest of every database, file store and backup on Utho. |
| (b) Access control | Roles and rights per organization, screen by screen; each app's role capped by the CCC's; two-step sign-in (required for admins by default); account lock after repeated failures; optional "sign in only from our places or networks"; no standing Lingsaa access (support access only as the Customer's admin grants it, 24 hours at most, look-only by default); view-only when a plan ends or support is look-only. | Administrative access to the hosting for Lingsaa staff: named accounts, two-step sign-in, least privilege, reviewed every quarter. |
| (c) Visibility through logs, monitoring and review | A tamper-evident audit trail of sign-ins, refusals, changes, exports, support access, security-rule changes and printing; every download carries an id and its SHA-256 in the trail; a watermark with the viewer's name and time on every screen; each app keeps its own trail and sends it to the CCC; alerts to the Customer's admins for refused sign-ins and support access. | Central collection of hosting logs; who reviews them, and how often. |
| (d) Continued processing, such as backups | A daily encrypted backup, restored into a separate test database and checked the same day; 7 daily, 5 weekly and 12 monthly backups kept; Lingsaa's Master Admins told at once when a backup or its check fails (docs/BACKUP.md). | Restore time and the most data that may be lost after a serious failure; a written recovery plan. |
| (e) Keep logs and personal data one year for investigation | The CCC's audit trail is kept 10 years (never less than one year). | The Documents app's 30-day purge of sign-in attempts (clause 4.5); hosting logs kept at least one year, and at least 180 days within India for CERT-In. |
| (f) Safeguards in the contract with the Data Processor | These terms (clause 4 and this Schedule). | Lawyer's review. |
| (g) Technical and organisational measures | Security rules each Customer sets (docs/SECURITY.md); security fixes reviewed and tested before release; a public page to report a security issue, with a reply within 3 working days. | A named security owner at Lingsaa; staff confidentiality and training; an incident runbook matching clause 5. |
Schedule 2: sub-processors
| Sub-processor | What for | Data | Where | Notes |
|---|---|---|---|---|
| Utho | Hosting, databases, file storage, backups | All service data | India [to be confirmed by Lingsaa operations, per app and backup] | |
| Email delivery provider (SMTP relay; Brevo is the configured relay for the Documents app) | Sending the email the service sends (sign-in codes, invitations, notices, documents shared) | Email addresses, names, message contents | [to be confirmed by Lingsaa operations] | Mail between colleagues inside the CCC never leaves the CCC (docs/MAIL.md) |
| MSG91 | SMS (sign-in codes and notices, DLT-registered templates) | Mobile numbers, message text | [to be confirmed by Lingsaa operations] | |
| Meta (WhatsApp Cloud API) | WhatsApp messages, where the person chose WhatsApp | Mobile numbers, message text | [to be confirmed by Lingsaa operations]; likely outside India | |
| Exotel (recommended) or Twilio | Phone calls (alert calls) | Mobile numbers, call records | Exotel: India (Mumbai) or Singapore by setting; Twilio: [to be confirmed by Lingsaa operations] | |
| Payment gateways (Razorpay, Cashfree, ICICI/CCAvenue) | Paying Lingsaa's invoices | Billing contacts and payment data | [to be confirmed by Lingsaa operations] | Lingsaa acts as Data Fiduciary here (clause 1.3) |
[to be confirmed by Lingsaa operations: the live list (only providers actually used in production belong here) and each provider's processing locations and terms]
Sources
| Short name | What | Official source |
|---|---|---|
| the Act | The Digital Personal Data Protection Act, 2023 (No. 22 of 2023) | India Code: https://www.indiacode.nic.in/handle/123456789/22037; Gazette of India: https://egazette.gov.in/WriteReadData/2023/248045.pdf; MeitY copy: https://www.meity.gov.in/static/uploads/2024/06/2bf1f0e9f04e6fb4f8fef35e82c42aa5.pdf |
| the Rules | The Digital Personal Data Protection Rules, 2025, notification G.S.R. 846(E) of 13 November 2025 | Gazette of India, Extraordinary, Part II, Section 3(i): https://egazette.gov.in/WriteReadData/2025/267650.pdf |
| Commencement | Notification G.S.R. 843(E) of 13 November 2025 under s.1(2) of the Act | https://egazette.gov.in/WriteReadData/2025/267647.pdf |
| CERT-In Directions | CERT-In directions under section 70B(6) of the Information Technology Act, 2000, No. 20(3)/2022-CERT-In, 28 April 2022 | https://www.cert-in.org.in/PDF/CERT-In_Directions_70B_28.04.2022.pdf |
Read from the Gazette text on 6 October 2026:
- When the Rules apply. Rule 1(2) to (4): rules 1, 2 and 17 to 21 from 13 November 2025; rule 4 from one year after publication; rules 3, 5 to 16, 22 and 23 from eighteen months after publication, that is from 13 May 2027. The security, breach, retention and transfer rules these terms rely on (rules 6, 7, 8 and 15) are in that last group. These terms commit Lingsaa to them from the start of the agreement, ahead of that date.
- When the Act applies. G.S.R. 843(E): s.1(2), s.2, ss.18 to 26, 35, 38 to 43 and s.44(1) and (3) from 13 November 2025; s.6(9) and s.27(1)(d) one year after publication (13 November 2026); ss.3 to 5, s.6(1) to (8) and (10), ss.7 to 17, s.27 except s.27(1)(d), ss.28 to 34, 36, 37 and s.44(2) eighteen months after publication, that is from 13 May 2027. So the duties these terms rely on (ss.5, 8, 11 to 14 and 16) start on the same day as the rules that go with them.
- Who is who. Section 2 of the Act: a *Data Fiduciary* (s.2(i)) decides the purpose and means of processing; a *Data Processor* (s.2(k)) processes personal data on its behalf; a *Data Principal* (s.2(j)) is the person the data is about; a *personal data breach* is defined in s.2(u).
- The contract. Section 8(2): a Data Fiduciary may involve a Data Processor "only under a valid contract". Section 8(1): the Data Fiduciary stays responsible for processing done for it. Rule 6(1)(f): the contract must provide for reasonable security safeguards.