Data processing agreement

This data processing agreement (the “DPA”) forms part of the agreement between the customer and MYLABS AI SOLUTIONS (OPC) PRIVATE LIMITED (“MYLABS”) under the terms of service. It governs how MYLABS processes personal data of the customer’s employees, contractors and users through ClearHours: the agent, the cloud service, the API, the dashboard and, where the customer enables it, the AI assistant (a preview).

The customer accepts this DPA together with the terms when it signs up; the sign-up form asks for acceptance of both. A customer that needs a countersigned copy, for example for its vendor records or with an Enterprise order form, can ask us for one.

The customer decides whether to record activity, for which teams, which data and for how long, and is the Data Fiduciary. MYLABS processes personal data on the customer’s behalf and is the Data Processor. The settings the service offers (Annex A.4) are means the customer selects.

MYLABS is the Data Fiduciary only for the administrator and billing contact data it uses to manage the account, issue GST invoices and keep the records required by the CERT-In Directions (clause 12). Our privacy policy covers that data, not this DPA.

The customer chooses the lawful basis for its processing. The terms of service require it to tell the people it enrols what is recorded and why; ClearHours cannot be run covertly (Annex A.5) and provides notice templates.

This DPA applies from the day the customer accepts it, including where the provisions of the Act and the Rules that it reflects come into force later.

MYLABS processes personal data only on the customer’s documented instructions: this DPA and Annex A; the customer’s configuration in the service (capture policy, notice, retention, teams and roles); and written instructions from an authorised administrator. We tell the customer if, in our opinion, an instruction would breach the Act or the Rules, and may hold that instruction until the customer confirms it in writing.

We do not process personal data for our own purposes, sell or share it, use it to train models, or combine it with the data of other customers. Figures about the running of the service that cannot identify anyone, such as request counts, error rates and storage volumes, are not personal data for this clause.

The customer uses the service only for the purposes in Annex A.2 and within the law. ClearHours supports decisions; it does not make them. The customer will not use it as the only basis for decisions about discipline, termination or pay.

On a computer with several people signed in at the same time, such as a remote desktop server, activity is attributed to the computer, not the person. The customer installs the agent on single-user computers or accepts figures per computer for shared ones.

We limit access to personal data to the personnel who need it to operate the service, who are bound by written confidentiality obligations. Every look at a named person’s data is recorded in the append-only audit log (Annex C.5).

Our support staff open a workspace’s personal data only with a support case reference recorded in the audit log, through the same role-based access the customer uses (with no direct database access in normal operation), and from India unless the customer has agreed another location in writing.

We maintain the technical and organisational measures in Annex C. The parties agree that they are the reasonable security safeguards required by Rule 6(1) of the Rules and the reasonable security practices and procedures referred to in section 43A of the Information Technology Act 2000. Each item of Rule 6(1) is served by:

(a) Encryption, masking

Annex C.1, encryption; Annex C.3, minimisation on the device (titles as a one-way code or not at all, redaction rules).

(b) Access control

Annex C.2, workspace isolation and roles; Annex C.4, identity.

(c) Logs and review

Annex C.5, audit log; Annex C.6, platform logging.

(d) Continued processing

Annex C.7, backups and continuity.

(e) One-year retention

Clause 7 and Annex C.5.

(f) Contract provision

This DPA.

(g) Organisational measures

Annex C.8, governance.

We may update Annex C as long as the overall level of protection does not fall, and we give the customer 30 days’ notice of material changes.

MYLABS does not hold a SOC 2 report or an ISO/IEC 27001 certificate today, and no third-party penetration test has been carried out. A SOC 2 control mapping is in progress and a penetration-test scope is written. If an order form names a certification and a date and the certification is not achieved by that date, the customer may end the agreement under clause 14.

After a personal data breach the customer, as Data Fiduciary, must tell each affected person and the Board without delay and give the Board a detailed report within 72 hours (Rule 7). The CERT-In Directions also expect the customer to report an incident affecting its data held by a vendor within 6 hours. Our commitments below are timed so that the customer has what it needs in time.

From the moment we notice an incident, or are told of it, we provide:

1. Within 4 hours A first notice to the customer’s security contact, or to its administrators where none is named: incident reference, nature, workspaces affected, suspected time window, data involved, containment so far and our point of contact.
2. Within 6 hours Our own report to CERT-In, filed, with its reference shared with the customer.
3. Within 24 hours The list of affected people and a statement of the data concerned: the facts for the customer’s notice to them.
4. Within 48 hours A detailed incident report: events and circumstances, cause, measures taken or proposed, findings about the person responsible where known, steps to prevent a recurrence and a record of the notifications we made. We update it until the incident is closed.
5. Within 15 business days A post-incident review with corrective actions, owners and dates.

We do not notify the customer’s Data Principals or the Board on the customer’s behalf unless the customer instructs us in writing. On instruction, we provide the text of a notice and deliver it through the agent or the dashboard.

As a body corporate and a cloud service provider, MYLABS reports the incidents listed in the CERT-In Directions to CERT-In within 6 hours, keeps the logs of its systems for a rolling 180 days, synchronises its clocks as the Directions require and maintains a point of contact. Because both parties may have to report, we share incident references so that the filings agree. A customer regulated by the Reserve Bank of India must also notify the RBI.

We do not publicly attribute an incident to the customer without its consent, and we disclose no more of the customer’s personal data in a CERT-In filing than the form requires. Annex D lists the contents of our notices.

Rule 8(3) requires a Data Fiduciary to keep personal data and the logs of its processing, including processing by its processor, for at least one year. In ClearHours the customer sets how long activity data is kept, from 30 to 3,650 days, and a one-year minimum for India is on by default; while it is on, the database refuses a shorter period. The customer may switch the minimum off only for a workspace that is not subject to the Act, and confirms that in writing when it does.

Every day the service deletes activity data older than the customer’s period: the recorded activity files, the daily activity totals, and the daily timesheet and shift-adherence records derived from them. Attendance records, timesheet periods, work logs and the audit log are kept as records and are not deleted by age. They are removed for one person by an approved erasure request (clause 7.3) and for everyone when the agreement ends (clause 7.4). Audit entries are kept with the person’s name removed.

An erasure request for a person is filed by that person or by an administrator, and the customer’s administrator approves or rejects it. An approved request is carried out at once: the person’s name and sign-in are removed, device links and history are deleted, the audit log is anonymised and the person’s activity files are deleted at the next daily pass. Records the customer must keep, such as approved time on client projects, remain without the person’s name. The customer receives a proof of erasure with counts for each store.

The service does not hold an approved request back until the one-year minimum has run. The timing is the customer’s decision as Data Fiduciary: where it takes the minimum to apply, it approves the request on or after the date the minimum ends for the records concerned. Every approval, rejection and retry is recorded in the audit log.

When the agreement ends we return the workspace’s data in open formats (CSV, JSON and Parquet) if the customer asks within 30 days, then erase it once the one-year minimum has run, and confirm the erasure in writing. During an agreed transition period we do not erase, purge or alter the customer’s data.

Every employee can see what is recorded about them, download it, ask for erasure and raise a grievance from the My data pages of the dashboard; administrators can file the same requests on their behalf. Each grievance gets a respond-by date 90 days after filing and is flagged when overdue. Corrections to a person’s name, team or device assignment are made by an administrator and recorded in the audit log.

If we receive a request directly from one of the customer’s Data Principals, we forward it to the customer within 5 business days and do not answer it ourselves. When the customer asks, we supply the data for an access request within 10 business days; the export in the dashboard is immediate for one person.

The customer publishes its grievance-response period, which Rule 14(3) limits to 90 days, and its contact person in its notice. We answer the customer’s questions needed to resolve a grievance within 5 business days.

The customer authorises the sub-processors in Annex B. We give at least 30 days’ written notice, or 60 days where an order form says so, before we add or replace one. The customer may object on reasonable data-protection grounds and, if we cannot resolve the objection, end the affected service without penalty.

We impose on each sub-processor obligations no less protective than this DPA and remain responsible to the customer for its sub-processors. For a customer regulated by the Reserve Bank of India, sub-contracting needs the customer’s prior consent.

Personal data is stored and processed in Microsoft Azure Central India, in Pune. Database backups are kept in the same region; geo-redundant backup is not used.

The exceptions are listed in Annex B: the e-mail the service sends is delivered by Resend outside India and carries the recipient’s address and name and the message, never activity data; the website and the dashboard’s static files are served from another Azure region and hold no customer data.

We do not otherwise transfer the customer’s personal data outside India without its written instruction, and we comply with any restriction the Central Government notifies under section 16 of the Act.

We make available the information the customer reasonably needs to show compliance with section 8 of the Act and Rule 6: this DPA and Annex C, the data inventory and data-flow document, a DPIA template, penetration-test summaries and certification reports when they exist, and the workspace’s audit log.

If the customer is notified as a Significant Data Fiduciary, we cooperate with its Data Protection Officer, its independent data auditor and its annual data protection impact assessment and audit, and provide the information it needs to check that the service poses no risk to the rights of Data Principals.

Once every 12 months, or after a breach, the customer or an independent auditor bound by confidentiality may audit our compliance on 30 days’ notice, during business hours and without access to other customers’ data. For a customer regulated by the Reserve Bank of India, this right extends to the RBI and its nominees.

If a government authority asks us for the customer’s data, we tell the customer before we respond unless the law forbids it, disclose only what is required and record the request.

Liability under this DPA is subject to section 13 of the terms of service.

Section 8(1) of the Act keeps the Data Fiduciary responsible for processing done on its behalf, whatever a contract says. Nothing in this DPA changes the customer’s responsibility towards the Board.

The customer is responsible for its instructions and for using the service within clause 3.3; MYLABS is responsible for its breach of this DPA.

This DPA lasts as long as MYLABS processes personal data for the customer, and its clauses on retention, erasure, customer records and audit continue after the agreement ends.

The customer may end the agreement without penalty if (a) an objection under clause 9.1 is not resolved, (b) MYLABS materially breaches this DPA and does not put it right within 30 days, or (c) a certification date in an order form is missed (clause 5.3).

If this DPA conflicts with the terms of service, this DPA prevails for personal data. Annex A prevails over Annexes B to E. An order form may shorten, but not lengthen, a deadline in clause 6.2.