1. How this DPA works
This Data Processing Addendum (the "DPA") is between the institute or organisation that uses MDESK ("Customer", "you") and Margintop Solutions Pvt. Ltd. ("Margintop Solutions", "Provider", "we", "us", or "our").
It forms part of the Terms of Service (the "Agreement"). If you use MDESK, this DPA applies automatically — you do not need a separate signature unless we have agreed otherwise in a written order. If this DPA conflicts with the Agreement on the processing of Personal Data, this DPA controls. The Privacy Policy describes our practices in plain language; this DPA is the processor contract.
This DPA covers Personal Data that Customer (or a person acting for Customer) enters into MDESK, or that we process on Customer’s documented instructions, in order to provide the Service. It does not cover account, billing, website, or support data for which we are an independent controller — that is described in the Privacy Policy.
2. Definitions
Capitalised terms not defined here have the meaning in the Agreement.
Terms we use
- Applicable Data Protection Laws: Nepal’s Individual Privacy Act, 2018 (व्यक्तिगत गोपनीयता ऐन, २०७५), the Electronic Transaction Act, 2063 (2008), and any other privacy or data-protection law that actually applies to Provider’s Processing of Personal Data under the Agreement.
- Customer Data: information Customer provides, or makes available, for Processing on Customer’s behalf to perform the Service.
- Data Subject: the identified or identifiable natural person the Personal Data relates to — for example a student, inquiry, parent, teacher, or staff member whose record Customer stores in MDESK.
- Information Security Incident: a breach of Provider’s security that results in accidental or unlawful destruction, loss, alteration, unauthorised disclosure of, or access to, Personal Data in Provider’s possession. Unsuccessful attacks (failed logins, pings, port scans, or similar) that do not compromise Personal Data are not Information Security Incidents.
- Personal Data: Customer Data that is personal information under Applicable Data Protection Laws. It does not include information about Customer’s own business contacts that we hold as a controller, or information we collect independently of the Service.
- Process / Processing: any operation we (or a Subprocessor) perform on Personal Data for Customer — including storage, access, transmission, and deletion.
- Service: MDESK as defined in the Agreement, including optional modules Customer enables.
- Subprocessor: a third party we engage to Process Personal Data in relation to the Service. Platforms Customer connects itself (for example a Facebook Page) are Customer’s processors or controllers, not our Subprocessors, except for the limited processing we do to send content Customer submitted.
3. Roles and duration
For institute records (students, inquiries, attendance, fees, teacher profiles Customer maintains, documents Customer uploads, and similar), Customer is the data controller (or equivalent under Applicable Data Protection Laws) and Provider is the data processor.
Customer decides what to enter, who on Customer’s team may see it, and how long to keep it. Provider hosts and processes that data only to provide, maintain, secure, and support the Service, as instructed by Customer and as described here.
This DPA stays in effect for as long as we Process Personal Data, including any short period after the Agreement ends that is needed to return or delete data as Section 11 describes.
4. Customer instructions
We will Process Personal Data only on Customer’s documented instructions: this DPA, the Agreement, the product’s ordinary operation, any written order, and other written instructions that are consistent with the Agreement.
By using MDESK, Customer instructs us to Process Personal Data to provide the Service — including hosting, backups, role-based access for users Customer invites, spreadsheet import (including sending headers and sample rows to an AI provider for mapping suggestions Customer must review), optional modules Customer enables, and support Customer requests.
If an instruction would require us to change the Service in a material way or to do work the Agreement does not cover, we will say so. We may refuse an instruction that we reasonably believe is unlawful; we will tell Customer unless the law forbids that notice.
Details of the Processing are in Annex 1.
5. Customer’s responsibilities
Customer is responsible for having a lawful basis to collect and use Personal Data it puts in MDESK, including consent from the person (or a parent or guardian, where the person is a minor) where Nepali law requires it.
Customer must
- Use the Service in a way that is appropriate to the sensitivity of the data (roles, passwords, who is invited, which modules are on)
- Keep account credentials and devices secure, and deactivate logins when people leave
- Not submit Restricted Data except as Section 8 allows
- Respond to Data Subjects (students, parents, inquiries, staff) who ask to access, correct, or delete their records — those people should contact the institute first
- Back up or export data Customer needs, using the product’s export tools while the account is active
Customer acknowledges that it has evaluated the Service and the Security Measures and that they are adequate for Customer’s use, including any duty Customer has under Applicable Data Protection Laws.
6. Security
We will implement and maintain technical and organisational measures designed to protect Personal Data against accidental or unlawful destruction, loss, alteration, unauthorised disclosure, or access, as described in Annex 2 (the "Security Measures"). We may update those measures so long as the overall protection of Personal Data is not materially decreased.
Personnel who may access Personal Data are bound by confidentiality obligations. Access by our team is limited to support, operations, security, billing, abuse prevention, or legal compliance — not unrelated commercial use of institute records.
Information Security Incidents
- We will notify Customer without undue delay after we become aware of an Information Security Incident, and will share details then known (what happened, what we are doing, and what we recommend Customer do)
- Notification is not an admission of fault
- We will reasonably cooperate, within our control, to help Customer investigate
- Customer is responsible for any notices to regulators, Data Subjects, or the public that the law requires of Customer. If such a notice will name Provider, Customer will, where the law allows, tell us first and consider reasonable clarifications we request
7. Data Subject requests
Taking into account the nature of the Processing, we will give Customer assistance that is reasonably necessary and technically feasible so Customer can respond to requests from Data Subjects to access, correct, or delete Personal Data in our possession.
If we receive a request that is clearly about Customer’s records, we will (unless the law forbids it) point the person to Customer and notify Customer. Customer handles the request. We may need Customer to confirm that the requester is entitled to the change.
If the assistance goes beyond ordinary product features (for example a custom extract), we may charge our then-current professional-services rates after a good-faith estimate.
8. Restricted Data
The Service is operational software for teaching institutes. It is not designed as a hospital system, a statutory school information system, or a card-holder data environment.
Do not submit without our prior written agreement, except where a module is expressly built for it and Customer has a lawful basis
- Health, genetic, or biometric data collected to uniquely identify a person
- Payment-card PAN/CVV (pay through the payment provider we enable; do not type card numbers into notes)
- Government identity-document scans or visa files, unless Customer uses a document module with appropriate access control and is allowed to hold those files
- Data Customer obtained by deception, or another organisation’s database Customer is not allowed to store
Student records may identify a minor. Customer must obtain any parent or guardian consent the law requires and must not post a student’s image, name, or story to a social network through MDESK without a lawful basis. We process that data only as Customer’s processor.
9. Subprocessors
Customer authorises us to engage Subprocessors to provide the Service. Current categories (and, where we name them, providers) are listed in Annex 3. We will impose data-protection terms on Subprocessors that are no less protective of Personal Data than this DPA, in light of the services they provide.
We may update Annex 3 when we add or replace a Subprocessor. For a material new Subprocessor that will Process institute Personal Data, we will update this page. If Customer objects on reasonable data-protection grounds within 15 days, we will discuss alternatives in good faith. If we cannot reasonably accommodate the objection, Customer may stop using the affected module or close the workspace as the Agreement allows.
Optional connections Customer turns on (Google Sign-In for a user, Facebook / Instagram / TikTok / LinkedIn for the marketing module, a payment provider Customer uses to buy credits) are Customer’s choice. Those companies process data under their own terms for the part they receive.
10. Information and audits
On written request, and no more than once per year except after an Information Security Incident or where the law requires, we will make available information reasonably necessary to demonstrate compliance with this DPA — including this DPA, the Privacy Policy, and a written summary of Security Measures.
We do not currently publish a SOC 2 or ISO 27001 report. If that changes, we will say so here.
On-site or intrusive audits of our infrastructure are not part of the standard Service. They are available only if required by Applicable Data Protection Laws or after an Information Security Incident, on reasonable notice, during business hours, in a way that does not compromise other customers, and (unless the incident was our proven fault) at Customer’s expense.
11. Return and deletion
While the account is active, Customer may export supported records (typically CSV) from the Service and may delete records in the product according to Customer’s permissions.
After termination or closure of an institute workspace, Customer should request any remaining export within 30 days. After that we may delete or irreversibly anonymise remaining Personal Data, except a subset we must keep for tax, accounting, security, dispute, or other legal duties.
Deletion of a teacher or staff login does not automatically erase historical attendance or payment rows they created; those remain institute records until Customer deletes them.
Backups may retain residual copies for a limited rotation period, after which they expire.
12. International processing
Margintop Solutions is based in Nepal. Some Subprocessors — including Google (sign-in and, if enabled, push notifications), email delivery, AI providers used for import mapping, cloud infrastructure, and social networks Customer connects — may Process data in other countries.
Where data is processed outside Nepal, we take contractual and practical steps that are reasonable for a service of this kind, including using reputable providers and limiting what we send (for example, sample rows for import mapping rather than an entire student database, where that is sufficient).
By using the Service, Customer instructs and acknowledges that this cross-border Processing is necessary to provide parts of the Service.
13. Other data-protection laws
MDESK is offered primarily to institutes in Nepal. This DPA is drafted for Nepali law. It is not, by itself, GDPR Standard Contractual Clauses, a UK International Data Transfer Agreement, or a CCPA “service provider” addendum.
If Customer is established in the EEA, UK, Switzerland, or another jurisdiction that requires extra transfer terms, or if Customer will store personal data of people in those places, Customer should tell us in writing before relying on MDESK for that processing. We will discuss additional terms in good faith. Enabling the Service without that discussion does not mean we have agreed to those extra regimes.
14. Liability
Liability under this DPA is subject to the limitations and exclusions in the Agreement, including the liability cap in the Terms of Service. Nothing in this DPA excludes liability that Applicable Data Protection Laws do not allow to be excluded.
15. General
Other terms
- This DPA, the Agreement, and any signed order are the entire agreement on Processing of Personal Data
- A signed order controls over this DPA to the extent it conflicts; this DPA controls over the Privacy Policy on processor obligations
- We may update this DPA as described in the Agreement for changes to Terms. Material reductions of Customer’s protection will be notified to the administrator where practicable at least 15 days in advance
- Governing law and courts are those in the Agreement (Nepal)
- Notices about this DPA: hello@mdesk.net with the subject [MDesk Legal Notice] or [MDesk Privacy]
Annex 1 — Details of Processing
Subject matter and nature
- Hosting and operation of MDESK so Customer can manage inquiries, students, courses, classes, teachers, attendance, fees, optional documents, optional advanced finance, and optional social publishing
Duration
- For the life of the institute workspace, then the export/deletion window in Section 11, then any legally required residual retention
Purpose
- To provide, maintain, secure, and support the Service on Customer’s instructions
Categories of Data Subjects
- Prospective students and walk-in inquiries
- Enrolled students (including minors where Customer enrols them)
- Teachers and staff whose profiles Customer maintains
- People named in notes, payments, documents, custom fields, or social posts Customer creates
- Users Customer invites (owners, administrators, teachers, staff)
Categories of Personal Data
- Identity and contact: name, phone, email, address, photos Customer uploads
- Institute operations: course, class, shift, attendance, fees, payment history, notes, custom fields Customer defines
- Account: login identifiers, role, institute affiliation
- Technical: IP address, device/browser data, logs, PWA cache, notification tokens where enabled
- Marketing module (if enabled): captions, media, schedule, publish results, and tokens for connected accounts
Sensitive data
- None as a default. Customer must not submit Restricted Data except as Section 8 allows. Custom fields may contain whatever Customer types; Customer is responsible for that content
Annex 2 — Security Measures
These measures match what we describe in the Privacy Policy and may be updated under Section 6.
Measures we use
- TLS encryption for data in transit between the user’s device and our servers
- Hashed password storage — we do not store passwords in plaintext
- Role-based access so institute users see only what their role allows
- API authentication tokens, session expiry, and logout invalidation
- Social-network access tokens stored as secrets; they are not shown in full in the product
- Activity logging for sensitive actions such as student and payment changes
- Access by our personnel limited to support, operations, and security needs
- Logical separation of institute workspaces in the ordinary operation of the product
- Vendor and hosting controls appropriate to a cloud service of this kind (firewalls, monitoring, backups, and patching as implemented by us and our infrastructure providers)
No method of transmission or storage is perfectly secure. Customer must use strong unique passwords, keep logins private, and tell us at hello@mdesk.net if unauthorised access is suspected.
Annex 3 — Subprocessors and optional connections
Customer authorises the following. Exact infrastructure regions may change as we operate the Service; we will keep this annex aligned with the Privacy Policy.
Subprocessors we use to run MDESK
| Provider / category | What they do | Where (typical) |
|---|
| Cloud hosting, database, file storage, and backups | Host the Service and Customer Data, including files Customer uploads | As used to operate the Service; may include locations outside Nepal |
| Email delivery | Transactional mail (OTP, welcome, similar). The marketing-site contact form is sent via EmailJS so we can reply | As operated by the email provider |
| AI providers (import mapping) | Column-header and sample-row mapping suggestions when Customer imports a spreadsheet. Customer must review the mapping | May be outside Nepal |
| Push notifications (if enabled) | Deliver device notifications via FCM / similar infrastructure | Global |
Optional — only if Customer (or a user Customer invited) turns them on
| Provider | What happens | Where (typical) |
|---|
| Google | Google Sign-In for users who choose it | Global (Google) |
| Payment provider | Collects payment details if Customer buys credits through that provider. We do not collect card numbers on MDESK itself | As operated by the provider |
| Meta (Facebook, Instagram), TikTok, LinkedIn | Marketing module: we send the content and tokens Customer authorised so a post can be published or scheduled. Those platforms then process the post under their own terms | Global |
16. Contact
Margintop Solutions Pvt. Ltd. — Privacy Officer
- Email: hello@mdesk.net
- Phone: +977-9845926945
- Subject: [MDesk Privacy] or [MDesk Legal Notice]
- Registered jurisdiction: Pulchowk, Lalitpur, Nepal