MMersal Legal OSPractice management for law firms
Back to the websitePrivacyTerms
EN·عربي·FR

Privacy Policy

How Mersal Legal OS collects, uses, stores, shares and deletes personal data - including data accessed from your Google Account when you connect a Gmail mailbox.

Effective 28 August 2026 · Last updated 6 October 2026

Contents
  1. 01Who this policy covers
  2. 02Controller and processor
  3. 03Data we collect
  4. 04Google user data (Gmail)
  5. 05Limited Use disclosure
  6. 06How we use data
  7. 07Legal bases
  8. 08Sharing and sub-processors
  9. 09Retention
  10. 10Deleting your data
  11. 11Security
  12. 12International transfers
  13. 13Cookies
  14. 14Your rights
  15. 15Children
  16. 16Changes and contact

1. Who this policy covers

Mersal Legal OS (“Mersal”, “we”, “us”) is practice-management software for law firms: clients, matters, documents, tasks and hearings, billing and receipts, conflict checking, firm memos, a client portal, and an optional connected mailbox. It is operated by Mersal Legal OS, based in the Republic of Lebanon, and served from https://mersal-os.vercel.app.

This policy applies to everyone whose personal data passes through the service: lawyers and staff who hold an account, clients of a subscribing firm who are given portal access or receive an invoice link, and any person named in the material a firm stores. It also applies to the data we receive from Google when a user chooses to connect a Gmail mailbox.

2. Controller and processor

A law firm that subscribes to Mersal decides what client and matter information it puts into the service and why. For that information the firm is the data controller and we act as its processor, handling the data on the firm’s documented instructions. For account registration data, billing for the subscription itself, security logs and product telemetry, we act as controller.

If you are a client of a firm using Mersal and want your information corrected or removed, contact that firm first - it controls the record. We will help the firm act on your request.

3. Data we collect

CategoryWhat it includesWhere it comes from
AccountName, work email address, hashed authentication credentials, role within the firm, language and display preferences, firm name, currency and plan.You, at sign-up and in settings.
Firm and matter recordsClients and their contact details, matters, hearings and deadlines, tasks, notes and memos, conflict-check entries, uploaded documents and their metadata, and the text read out of those documents (see below).Entered or uploaded by firm users.
Billing recordsInvoices and pro-forma invoices, line items, payments recorded against them, receipts, and firm bank details printed on invoices.Entered by firm users.
Connected mailboxSee section 4 - this is the Google (or Microsoft) data, and it is described separately and in full.Google or Microsoft APIs, only after you connect.
Mailbox on your own serverThe address, the IMAP and SMTP server names, ports and encryption setting, the login name, and the mailbox password - held encrypted, see section 11. The messages it retrieves are stored exactly as described in section 4 for a connected mailbox.You, when you connect a mailbox that is not Gmail or Outlook.
Connected calendarEvents from the Google or Outlook calendar you choose to connect: their title, location, start and end, and the provider's own identifier for them. Visible only to the person who connected the calendar.Google or Microsoft APIs, only after you connect and switch the calendar on.
NotificationsWeb Push subscription endpoints and keys for the devices you enable notifications on, plus the notices shown in the app.Your browser, when you switch notifications on.
TechnicalSession cookies, IP address and request metadata at the hosting layer, server error logs, and an in-app audit log of significant actions (who did what, when).Automatically, as you use the service.

We do not collect special-category data deliberately, but a legal matter may of course contain it. Treat everything you store here as confidential material and apply your own professional obligations to it.

A firm may choose to hold its own encryption key (Security → the firm's own key). Once it does, every matter or client DOCUMENT uploaded afterwards — and the text read out of it — is encrypted in the browser of the person uploading it, before anything is sent to us. What reaches our servers is ciphertext we hold no key to: not our staff, not an administrator, and not anyone who obtains a copy of the database. Only a key holder in that firm can open those documents, and if every holder is lost the documents cannot be recovered by anyone, ourselves included. Documents stored before the key was turned on stay readable to us until the firm converts them, which it does from the same screen — and that screen says how many are left, including any the person converting cannot open themselves.

What holding your own key does NOT cover, so that nobody is surprised later: the names, dates, amounts and matter titles described in section 2; files attached to a conversation with a client or between colleagues; photographed expense receipts; files attached to internal notices; and the subject lines and bodies of email we sync on your firm's behalf. Those remain readable to us exactly as described elsewhere in this policy.

And a limit we would rather state than imply: we write and serve the software itself. For documents ALREADY sealed we cannot produce the key, because we do not have it and no later change of ours alters that. We cannot make the same promise about documents sealed in the future, because the code doing the sealing is code we ship to your browser. A firm that needs a stronger guarantee than that should not rely on software it does not host itself.

When a document you upload carries a text layer - most PDFs produced by a computer do - that text is read in your browser as the file is uploaded and stored alongside the document, so that you can search inside your own files. It is held in our database in readable form and is covered by the same access rules, retention and deletion as the document itself. Scanned paper has no text layer and nothing is read from it. If this matters to your firm, it can keep its own encryption key: see the paragraph above.

4. Google user data (Gmail)

Connecting a mailbox is optional. Nothing in this section happens unless a user explicitly starts the connection from Settings and completes Google’s consent screen. The service is fully usable without it.

Scopes we request, and why

ScopeWhy we ask for it
openidConfirms the identity of the Google Account completing the connection.
emailReads the mailbox address so we can label the connection and match sent mail to the right account. This address is stored.
profileBasic profile information returned with the identity response during connection.
gmail.readonlyReads your recent messages so the firm inbox inside Mersal can show them and so a message can be filed against a matter. Read-only: we never modify, label, archive or delete anything in your Gmail account.
gmail.sendSends a message you compose in Mersal from your own mailbox - a reply to a client, or correspondence attached to a matter. We only send messages you write and submit yourself.

We request the narrowest scopes that support these features. We do not request gmail.modify, gmail.compose, gmail.settings.* or full mail.google.com access, and we do not read Google Drive, Calendar or Contacts.

What we store, and what we deliberately do not

When a sync runs, we store the following for each retrieved message:

  • Provider message and thread identifiers.
  • Sender address, recipient addresses, subject, and Gmail’s snippet.
  • The plain-text body of the message.
  • Folder, labels, read/unread state, direction, and the received timestamp.
  • For attachments: filename, MIME type, size and the provider’s attachment identifier - metadata only.

We do not store:

  • HTML message bodies. The reading pane renders plain text only, so a stranger’s markup is never executed and their tracking pixels never load.
  • Attachment file contents. Only the metadata listed above is copied; the file itself stays in your mailbox unless a user separately downloads it and uploads it as a matter document.
  • Your Google password. We never see it - authentication happens entirely on Google’s pages.

How access tokens are held

Google’s access and refresh tokens are encrypted (AES) with a server-side key before they are written to the database, and are decrypted only inside server code that is about to call the Gmail API. They are never sent to a browser, never exposed to other members of your firm, and are never readable through the application’s data API. The OAuth state parameter is HMAC-signed and time-limited, so a mailbox cannot be bound to anyone but the user who started the connection.

When we access your mailbox

  • When you press Sync now.
  • On a scheduled daily job, which fetches up to the 100 most recent messages per connected mailbox.
  • When you send a message you have composed in the app.

Access is limited to the mailbox of the user who connected it. Stored messages are visible only to that user’s own account; they are not pooled into a shared firm-wide inbox.

Calendar, if you connect one

Connecting a calendar is a separate, optional step with its own consent screen: connecting a mailbox never grants access to your calendar, and connecting a calendar never grants access to your mail. Two switches control it, both off until you turn them on.

ScopeWhy we ask for it
calendar.events.readonly (Google) / Calendars.Read (Microsoft)Reads the events in the calendar you choose, so your own appointments appear beside your hearings inside Mersal. They are stored with their title, location, start and end, and are visible only to you - not to your colleagues, not in the firm’s reminder emails, and not in the daily summary.
calendar.events (Google) / Calendars.ReadWrite (Microsoft)Requested only if you ask Mersal to put your hearings into your calendar. We create a calendar of our own in your account and write only to that one; we never modify or delete anything you or anyone else created.

We do not request the full calendar scope, which would let us manage your calendars themselves, and we do not read your contacts or your files.

What a pushed hearing says leaves our control. An event written into your Google or Microsoft calendar is stored by them. By default we write only the court’s case number and the court; naming the client is a choice you make per connection, in Settings, next to the switch that causes it.

Turning the calendar off deletes the imported events from Mersal. Disconnecting deletes them and our copy of the tokens; with Google we also call its revocation endpoint. Microsoft provides no revocation endpoint, so for Outlook you should also remove Mersal yourself at myaccount.microsoft.com. Hearings we previously wrote into your calendar are left where they are - they are yours, and removing court dates from your telephone is not ours to do.

The calendar subscription address

You can generate a private web address that serves your own hearings and deadlines in the standard calendar format, so any calendar application - including Apple Calendar, which offers no other route - can subscribe to it. It is fetched without a login, so the address itself is the credential: anyone holding it can read that list. It contains each hearing’s case number and court, never your client’s name. Replacing the address from Settings revokes the old one immediately.

5. Limited Use disclosure

Mersal Legal OS’s use and transfer of information received from Google APIs to any other app will adhere to the Google API Services User Data Policy, including the Limited Use requirements.

Concretely, and without exception:

  • We use Google user data only to provide and improve the mailbox features described in section 4 - the in-app inbox, filing correspondence to a matter, and sending mail you compose.
  • We do not sell, rent or licence Google user data to anyone, ever.
  • We do not use Google user data for advertising, retargeting or audience building.
  • We do not use Google user data to develop, improve or train generalised or non-personalised artificial-intelligence or machine-learning models, and we do not transfer it to any third party for that purpose.
  • No human at Mersal reads your Gmail data, except: with your explicit prior consent (for example, to investigate a support issue you have reported); where narrowly required to investigate abuse or a security incident; where required by law; or on data that has been aggregated and de-identified for operational statistics.
  • We transfer Google user data to others only where necessary to run the service (see section 8), to comply with applicable law, or as part of a merger or acquisition after giving notice and obtaining consent where the law requires it.

6. How we use data

  • To operate the features you use: matters, documents, calendar, billing, portal, inbox.
  • To send transactional email on your instruction - invoices to clients, teammate and client invitations, hearing and deadline reminders.
  • To deliver device notifications you have switched on.
  • To keep the service secure and accountable: authentication, per-firm access control, audit logs, abuse and fraud prevention.
  • To diagnose faults and improve reliability and performance.
  • To meet our own legal and accounting obligations.

We do not use your data, or your firm’s client data, for advertising, and we do not sell it.

7. Legal bases

We process personal data under Lebanese Law No. 81/2018 on Electronic Transactions and Personal Data and, where it applies to a user or a firm’s clients, the EU/UK GDPR. Our grounds are:

  • Contract - to provide the service you or your firm signed up for.
  • Consent - for optional features you switch on, in particular connecting a mailbox and enabling device notifications. You can withdraw consent at any time by disconnecting or switching them off.
  • Legitimate interests - securing the service, preventing abuse, and keeping records of what happened in it.
  • Legal obligation - where retention or disclosure is required of us by law.

8. Sharing and sub-processors

We do not sell personal data. We share it only with the providers that run parts of the service, each bound to process it only on our instructions:

ProviderRoleData involved
SupabaseDatabase, authentication and file storageAll application data, including uploaded documents and synced messages.
VercelApplication hosting and edge networkRequest metadata and server logs.
ResendTransactional email deliveryRecipient address and the contents of invoices, invitations and reminders you send.
GoogleGmail API, if you connect a mailboxThe mailbox access described in section 4.
MicrosoftOutlook / Graph API, if you connect a mailboxThe equivalent mailbox access for Microsoft accounts.
Browser push servicesDelivery of device notificationsThe push endpoint of the device you enabled, and the notification text.

We may also disclose data where we are legally required to, or to establish or defend legal claims. If we are ever acquired, data may transfer with the business, and we will give notice before it becomes subject to a different policy.

9. Retention

  • Firm and matter records are kept for as long as the firm’s account is active, because a legal file has its own retention duty that belongs to the firm, not to us.
  • Synced messages are kept while the mailbox stays connected. Disconnecting deletes them (section 10).
  • OAuth tokens are kept only while the connection exists, and are deleted with it.
  • Audit logs are retained for security and accountability, and are intentionally append-only.
  • Backups roll off on the hosting provider’s schedule after deletion from the live system.

10. Deleting your data

Disconnecting a mailbox

Open Settings → Connected mailboxes and remove the account. This deletes the stored connection record, its encrypted access and refresh tokens, and - by database cascade - every message and attachment record we synced from that mailbox. Nothing in your actual Gmail account is touched.

You can additionally revoke Mersal’s access from your Google Account at myaccount.google.com/permissions. Doing so immediately invalidates any token, and we recommend it whenever you want access to end at Google’s side as well as ours.

Deleting an account or a firm

Write to legalmersal@gmail.com from the address on the account. We will verify the request, delete the account and its data, and confirm when it is done - normally within 30 days. Where a firm administrator asks us to delete a whole firm, we will notify the account owner first. We may retain the minimum needed to meet a legal obligation or to resolve a dispute, and will say so if that applies.

11. Security

  • All traffic is served over HTTPS/TLS.
  • Every firm’s data is isolated at the database level by row-level security, so a query made with one firm’s credentials cannot return another firm’s rows.
  • Mailbox tokens are AES-encrypted at rest with a key held only in the server environment.
  • The password of a mailbox on your own server is encrypted at rest with AES-256-GCM, under a separate key from the one that protects mailbox tokens, and is held in a table that carries no read policy at all - so it is unreadable through the application's data API, by anyone, including other members of your own firm. It is never returned to a browser and there is no feature anywhere that displays it.
  • Privileged keys are server-side only and never shipped to the browser; sessions are carried in HttpOnly cookies and verified against the auth server on each request.
  • OAuth state is HMAC-signed and expires, preventing forged or replayed callbacks.
  • Significant actions are written to an append-only audit log.
  • Uploaded documents are stored in access-controlled storage, not on a public URL.

No system is perfectly secure. If we become aware of a breach affecting your personal data, we will notify you and any regulator as required, without undue delay.

12. International transfers

Our providers operate globally, so your data may be processed in a country other than your own, including the United States and the European Union. Where data leaves a region whose law restricts transfers, it is protected by the receiving provider’s standard contractual clauses or an equivalent approved mechanism.

13. Cookies

We set only what the service needs to work: session cookies that keep you signed in, and local storage for preferences such as language and theme. We do not use advertising cookies, third-party trackers, or cross-site analytics profiling.

14. Your rights

Under Lebanese Law No. 81/2018 on Electronic Transactions and Personal Data - and under the GDPR or a comparable regime where you live - you may have the right to access the personal data we hold about you, to correct it, to have it deleted, to restrict or object to processing, to receive it in a portable format, and to withdraw consent. To exercise any of these, write to legalmersal@gmail.com. We answer within 30 days and do not charge for a first request.

If your data was entered by a law firm using Mersal, we will forward your request to that firm as controller and support it in responding. If you live under the GDPR or a comparable regime, you also have the right to complain to your local data-protection authority. Lebanon has no such authority, and saying otherwise would send you looking for a body that does not exist: Lebanese Law No. 81/2018 on Electronic Transactions and Personal Data places the register of declared processing with the Ministry of Economy and Trade, and gives you the right to apply to the competent courts - in particular the judge of urgent matters - to enforce access and correction.

Heirs. Lebanese Law No. 81/2018 on Electronic Transactions and Personal Data gives a person's heirs the same rights over their data: to ask whether it is held, to receive a copy of it - in an intelligible form, even where it is encrypted - to have it corrected or erased, and to apply to the courts if that is refused. Write to legalmersal@gmail.com with evidence of the death and of your standing as an heir. Where the record was entered by a law firm using Mersal, that firm is the controller and the decision is theirs: we will forward the request and support them in answering it.

15. Children

The service is for legal professionals and their clients and is not directed at children under 16. We do not knowingly collect data from children through account registration. Information about a minor may appear inside a matter file; that material is the firm’s to control and is handled under section 2.

16. Changes and contact

We may update this policy as the service changes. The effective date at the top always reflects the current version, and we will notify account holders in the app or by email before a material change takes effect. Continuing to use the service after that means you accept the updated policy.

Questions, requests and privacy complaints: legalmersal@gmail.com
Mersal Legal OS · https://mersal-os.vercel.app

Mersal Legal OS · legalmersal@gmail.com

Back to the website · Sign in · Privacy Policy · Terms of Service