Skip to main content

Legal

Law Enforcement and Government Requests

How we handle requests for user data, what we actually hold, and the large amount that we do not hold at all.

Effective: July 25, 2026Last Updated: July 25, 2026

SO Labs Inc. is a Canadian company based in Calgary, Alberta. We assess every request from law enforcement or a government agency under Canadian law. This page sets out what we hold, what we do not hold, how to make a request, and what we require before we disclose anything. It is written for investigators, for counsel, and for the users whose data is being asked about.

Read this first: we cannot produce what we do not retain. Email content is analysed in memory and is not written to persistent storage. There is no archive of message bodies to search, disclose, or preserve. A request for the contents of a user's email will return nothing, because there is nothing to return. Section 02 explains this in full.

01Who We Are and the Law We Apply

  • ▸SO Labs Inc. is incorporated in Canada and operates from Calgary, Alberta. We remain a Canadian entity.
  • ▸We assess every request under Canadian law, including our obligations under the Personal Information Protection and Electronic Documents Act (PIPEDA).
  • ▸The governing law and dispute resolution terms for our services are set out in our Terms of Service. Nothing on this page changes them.
  • ▸Publishing this policy is not consent to disclose anything. It is not a waiver of any right, privilege, objection, or defence available to us or to our users, and it does not create obligations on us beyond those the law imposes.
  • ▸How we handle personal data generally is set out in our Privacy Policy.

02What We Hold and What We Do Not Hold

2.1 What we may hold

Subject to valid legal process, the categories below are what could realistically exist for an account:

  • ▸Account information. The name on the account, the email address, the subscription tier, and timestamps such as when the account was created and when it was last active.
  • ▸Analysis verdicts and metadata. The result of an analysis, for example a risk score or a verdict, together with metadata such as the time of the analysis and which check was run. This is the outcome of the analysis, not the message that was analysed.
  • ▸Breach monitoring results. Whether an email address appeared in a known public data breach. Only the email address is checked against the breach data source. No passwords and no message content are involved.
  • ▸Limited billing records. Plan and subscription records. Card details are held by Stripe, our payment processor, and not by us.

2.2 What we do not hold

  • ▸Email content. Message bodies, subject lines, headers, and attachments are analysed in memory and are not written to persistent storage. We hold no archive, no copy, and no backup of them.
  • ▸Content submitted to the Ṣọ Shield API. Content submitted by API customers is analysed in memory and is not stored. It also never leaves our own infrastructure, because the API calls no external third parties.
  • ▸A searchable message archive of any kind. There is no index of past messages to run a query against, whether by keyword, sender, recipient, or date.

2.3 What this means for a request

  • ▸We cannot produce what we do not retain. This is a fact about how the system is built, not a position we have taken about a particular request.
  • ▸An order requiring us to disclose email content will be met with a response explaining that no such records exist. We will say so in writing.
  • ▸We cannot preserve message content that was never stored, and a preservation demand cannot create records that do not exist.
  • ▸If an investigation needs the contents of a person's mailbox, the mailbox provider or the account holder is the right party to approach. We are not a mail host and we do not keep a copy of the mailbox.

03How to Submit a Request

Send requests to privacy@soemailsecurity.com, with the signed legal process attached. Your request should include:

  • ▸The legal basis. The statute, rule, or authority you are relying on, and a copy of the legal process itself.
  • ▸The requesting agency. The agency name, the name and rank or title of the officer making the request, an agency badge or identification number, and an official agency email address and phone number we can use to verify it.
  • ▸The specific account identifier. Normally the email address on the account. A person's name alone is not enough for us to identify an account reliably.
  • ▸The specific data sought. Which categories from Section 2.1 you are asking for, and the date range. Requests for “all data” are not specific enough.
  • ▸A response address. An official agency address or email for our reply, and any deadline set by the legal process.

We do not accept requests by phone. We will not confirm or deny the existence of an account over the phone, and we will not disclose data on a verbal request. This protects users against anyone impersonating an officer. We may telephone the agency using a publicly listed number to verify a request we have received in writing.

We aim to acknowledge a properly submitted request promptly. Processing time depends on the scope of the request and on whether we need clarification or legal advice.

04What We Require

  • ▸Valid legal process, matched to the data sought. The process must be issued by a body with authority over us and must be appropriate to the category of data requested. More sensitive data requires stronger legal process.
  • ▸We reject overbroad requests. Requests that sweep in accounts, categories, or date ranges beyond the investigation are refused or sent back to be narrowed.
  • ▸We reject unclear requests. If we cannot tell which account or which data is being asked for, we will ask for clarification before we do anything.
  • ▸We reject requests without proper legal authority. An informal letter, a request on agency letterhead alone, or a voluntary request unsupported by legal process is not sufficient for us to disclose user data.
  • ▸Foreign requests come through Canadian channels. We are a Canadian company. Requests from agencies outside Canada should generally come through a Canadian legal channel, such as a Mutual Legal Assistance Treaty (MLAT) request or a Canadian court order. We are not obliged to act on foreign legal process served directly on us, and we generally will not.
  • ▸We may take legal advice and object. We may seek advice, ask for a request to be narrowed, or challenge a request we believe is unlawful, overbroad, or improperly issued.
  • ▸We disclose the minimum. Where we are required to disclose, we produce only the specific records covered by the process, and nothing beyond them.

05Notice to Affected Users

  • ▸We notify before we disclose. Our default is to tell the affected user about a request for their data before we produce anything, so they have the chance to seek their own legal advice.
  • ▸Two exceptions. We will not give notice where we are legally prohibited from doing so, for example under a non-disclosure or sealing order, or where we reasonably believe notice would create a risk to someone's life or safety.
  • ▸Delayed notice. Where a non-disclosure period expires or is lifted, we will notify the affected user after the fact, where we are permitted to and where we can still reach them.
  • ▸Indefinite gag orders. If a request comes with an open-ended prohibition on notice, we may ask the requesting agency or the court to set a time limit on it.
  • ▸Business customers. Where the data belongs to an enterprise, API, or partner customer, we will notify that customer unless the law forbids it, so they can respond on their own users' behalf.

06Emergency Requests

There is a narrow path for genuine emergencies, meaning a situation involving a risk of death or serious physical harm to a person. It is not a way to skip legal process for an ordinary investigation.

  • ▸Email privacy@soemailsecurity.com with EMERGENCY DISCLOSURE REQUEST in the subject line.
  • ▸Describe the nature of the emergency, the harm you are trying to prevent, and why it is immediate rather than general.
  • ▸Give the specific account identifier, the specific data you need, and explain how that data will help prevent the harm.
  • ▸Give the requesting officer's name, agency, identification number, and an official agency contact so we can verify the request.

We assess emergency requests in good faith and as quickly as we can. Any disclosure is voluntary, is limited to what is needed to address the emergency, and does not waive our position on any other request. The retention facts in Section 02 still apply, so an emergency request cannot produce email content that was never stored. We treat misuse of this channel seriously and may refuse future requests from a requester who has abused it.

07Transparency Reporting

  • ▸We intend to publish a periodic transparency report showing aggregate counts of the government and law enforcement requests we receive, how many we complied with in whole or in part, and how many we rejected or challenged.
  • ▸We have not published a transparency report yet. We are not going to publish invented or estimated historical numbers, so the first report will cover the period from its own start date forward.
  • ▸Reports will show aggregate figures only. They will not identify individual users, individual accounts, or specific investigations, and they will exclude anything a non-disclosure obligation prevents us from reporting.
  • ▸When the first report is published, it will be linked from this page.

08Contact

This page explains our process. It is not legal advice, it is not a substitute for legal process, and it does not create obligations on us beyond those imposed by law.