Privacy Policy
Last updated: 29 September 2026
Sigil personalises email signatures from your organisation's Microsoft 365 directory. This policy explains what data the service processes, why, and what it never touches.
Who we are
Sigil is a product of Tophhie Cloud Ltd, a company registered in England and Wales under number 17393069, whose registered office is at 21 Manor Way, Hoyland, Barnsley, England, S74 9QX ("we", "us"). When you use Sigil, your organisation is the data controller for its directory data and we act as a data processor on your behalf; the terms of that processing are set out in our Data Processing Agreement. For our own account, billing and sign-up records we act as a controller. You can reach us about anything in this notice at privacy@usesigil.app, or by post at the address above.
What Sigil processes
Directory attributes (to build signatures)
To render a personalised signature, Sigil reads user attributes from your Microsoft 365 directory through the Microsoft Graph API, using permissions your administrator grants at onboarding. These include name, job title, department, company, email address, phone numbers, office and address, manager details, and any on-premises extension attributes your organisation uses. Sigil only reads the directory and never writes to it. These attributes are already visible to colleagues in the address book.
Templates and images you create
Signature templates, compliance footers, campaign banners and the images you upload are stored so the service can render and manage them.
Usage telemetry (to show the service is working)
Sigil records metadata about signature activity so administrators can see whether signatures are reaching users: which mailbox requested a signature, which template version was served, the compose type, and whether the add-in applied it. This telemetry contains no IP addresses, no recipient identities, and no message content or rendered signature HTML. It is counts and metadata only.
Sigil also records clicks on tracked links in signatures and banners. Each click is stored as the link that was clicked, the time, and three coarse descriptors derived from the request at that moment: a device class (desktop, mobile or tablet), a browser family (such as “Chrome” or “Safari”, with no version number), and the host name of the referring page where one is sent — never its full address. The underlying user-agent string and referring URL are discarded immediately and never stored, and no IP address is recorded at any point. Links containing per-recipient values are never tracked at all. These descriptors are reported only in aggregate and cannot be used to identify or profile an individual recipient. The per-click records are deleted after 90 days; only daily click totals are kept beyond that.
Account and billing data
We store your organisation's tenant record and subscription details. Payment card handling is performed by our payment processor; we do not store card numbers.
Sign-up diagnostics
When an administrator connects an organisation to Sigil, we record what that sign-up request looked like: the browser's user-agent string, the network and country it came from, and an automated-traffic score. We do this to tell a real administrator apart from the crawlers and mail-security scanners that follow the public sign-up link, and to diagnose a sign-up that failed. No IP address is recorded, and this applies only to our own sign-up flow — never to your users. These details are deleted after 90 days; the record that a sign-up happened, and how it ended, is kept.
If the link the administrator arrived by carries campaign tags (the
utm_* parameters, or the msclkid click id that
Microsoft Advertising adds), we record those tags on the same sign-up record,
so we know which of our own adverts or listings brought the sign-up. That is
the whole of it: no advertising cookie is set, no tracking pixel is loaded,
and nothing about the sign-up is reported back to the advertising platform.
The click id is deleted after 90 days with the details above. The campaign
name is kept with the record.
What Sigil never does
- It does not read, store or transmit the content of your emails.
- It does not track individual recipients or log who received what.
- It does not sell or share personal data for advertising.
Why we process it, and on what basis
For your organisation's directory data, signature content and usage telemetry, your organisation is the controller and decides the lawful basis for that processing. We process it only on your organisation's documented instructions, on the terms of our Data Processing Agreement.
For the data we hold in our own right, as controller:
| What | Why | Lawful basis |
|---|---|---|
| Tenant, subscription and billing records | To provide and administer the service your organisation signed up for, communicate with administrators about their account and use of Sigil, take payment, and keep our accounts. | Performance of a contract (Article 6(1)(b)); legal obligation, for the tax and accounting records (Article 6(1)(c)) |
| Portal access records — who signed in, and with what role | To secure the portal and give your administrators an audit trail of who changed what | Performance of a contract (Article 6(1)(b)); legitimate interests in securing the service (Article 6(1)(f)) |
| Sign-up diagnostics, and the campaign tags on the link a sign-up arrived by | To tell a real administrator apart from the crawlers and mail-security scanners that follow our public sign-up link, to diagnose a sign-up that failed, and to know which of our own adverts or listings brought a sign-up | Legitimate interests in the security and reliability of our own sign-up flow, and in measuring our own advertising (Article 6(1)(f)) |
| Product update emails to the administrators of organisations using Sigil and to MSP partner staff, and the list of addresses that have asked not to receive them | To tell the people who run Sigil for their organisation what has changed in the service, and to make sure nobody who asked us to stop is sent another | Legitimate interests in keeping existing customers informed about the service they use (Article 6(1)(f)); legal obligation, for keeping the list of objections (Article 6(1)(c)) |
| Questions typed into "Ask the documentation" in the portal's Help dialog | To answer them from the Sigil documentation. The question is sent to Cloudflare's AI service together with the matching documentation pages, and the answer is shown to the person who asked. Neither the question nor the answer is kept by Sigil or by Cloudflare, and neither is used to train any model. | Legitimate interests in helping the people who administer Sigil find their way round it (Article 6(1)(f)) |
Where we rely on legitimate interests, we have weighed those interests against your rights and freedoms. You can object to that processing at any time — see Your rights below.
Every product update email carries a link that stops them for your address, with no sign-in needed, and an administrator can switch them off for their whole organisation in Settings. Stopping product updates does not stop the emails about your organisation's own account that providing Sigil involves, such as billing notices and changes an administrator needs to act on.
Sub-processors
Sigil relies on the following providers to deliver the service:
| Provider | Purpose |
|---|---|
| Microsoft | Identity (Microsoft Entra ID) and directory data (Microsoft Graph) |
| Cloudflare | Application hosting, storage and caching |
| Stripe | Subscription billing and payment card processing |
Retention and deletion
How long each kind of data is kept:
| Data | How long we keep it |
|---|---|
| Directory attributes read from Microsoft Graph | Never stored as a record of their own. Read on demand and then held in short-lived caches: inside a rendered signature for at most 24 hours, re-read from the directory once it is an hour old, which is how a change to someone's job title reaches Outlook by itself; a profile photo for at most 24 hours; and the directory record behind a signature for up to 7 days after that mailbox last composed a message, so that the first message of the day is not held up by a directory look-up. On the device, the Outlook add-in keeps a copy of the last signature it applied for up to 45 days after that mailbox last composed a message. |
| Templates, footers, banners and uploaded images, and the preview images Sigil generates from them | For as long as your organisation uses Sigil. Deleted items sit in a recycle bin for 30 days and are then removed. Preview images show a sample person, never your staff, and go when the version they depict does. |
| Per-click records for tracked links | 90 days. Only daily click totals are kept beyond that. |
| Sign-up diagnostics (user-agent, network, country, automation score, and the Microsoft Advertising click id where the link carried one) | 90 days. The record that a sign-up happened, how it ended, and the campaign name on the link it arrived by, is kept as part of our own business records. |
| Addresses that have opted out of product update emails | For as long as the objection stands. An address stays on the list until that person opts back in, because removing it any sooner would mean emailing somebody who asked us to stop. The list holds the address and the date, nothing else. |
| Signature activity telemetry | 90 days for the individual request and outcome records. The per-mailbox summary and the daily totals built from them are kept for as long as your organisation uses Sigil, so its administrators keep their historical adoption reporting, and are deleted when the organisation is deprovisioned. |
| The administrative change log | For as long as your organisation uses Sigil, as its audit trail of who changed what. Deleted when the organisation is deprovisioned. |
| Tenant, subscription and billing records | For as long as your organisation uses Sigil, and then for as long as tax and accounting law requires us to keep the financial records. |
When an organisation is deprovisioned, its data is held for a 30-day grace window — so an accidental disconnection can be undone — and is then permanently deleted: templates, images, cached signatures, activity telemetry, the change log, profile values and the tenant record itself.
Your rights
If you are in the UK or the European Economic Area, you have the following rights over your personal data:
- To be informed — to know what is processed and why, which is what this notice is for.
- Of access — to obtain a copy of your personal data.
- To rectification — to have inaccurate data corrected.
- To erasure — to have your personal data deleted, where there is no overriding reason for us to keep it.
- To restriction of processing — to have processing paused while a dispute is resolved.
- To data portability — to receive the data you provided in a structured, commonly used, machine-readable format, or to have it transmitted to another provider.
- To object — to object to processing we base on legitimate interests, and to object to direct marketing at any time.
- Not to be subject to a decision based solely on automated processing, including profiling, that produces legal or similarly significant effects. Sigil makes no such decisions. It does not profile individuals, score them, or decide anything about a person automatically.
Because your organisation is the controller of its directory data, signature content and usage telemetry, please send requests about that data to your own administrator; we will assist them as processor, and we can locate an individual's records by their email address. For the data we control — your tenant, subscription and billing records, and sign-up diagnostics — write to privacy@usesigil.app. We respond within one month.
Where we rely on your consent you may withdraw it at any time, without affecting processing already carried out. If you are unhappy with how we have handled your data, you can complain to a supervisory authority: in the UK, the Information Commissioner's Office (ico.org.uk); in the EEA, the authority for your country of residence.
Changes to this policy
We may update this policy as the service evolves. Material changes will be reflected in the "last updated" date above.