Skip to content

Compliance and governance

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.

Tophhie Cloud is the brand. The company is the party your organisation contracts with, which is why every published agreement names it in full at the top rather than leaving it to the branding. If you are reconciling the company against another record, it is the same identity that appears on the Companies House register, on the Microsoft Publisher Attestation, and on the invoices Stripe issues.

Sigil keeps two separate append-only records.

The change log covers what was done to your organisation. It is not confined to templates: publishes and rollbacks, the whole template lifecycle from create to permanent deletion, assignment rules, banners, footers, link tracking, image uploads and deletions, test emails, and changes to who has access and at what role, each with who and when. The portal’s Audit log view shows all of it, filterable by half, by who and by action, with each entry opening into what it changed.

It also covers what Tophhie Cloud staff did on your organisation. Those entries are badged as support and read “Sigil operator” rather than naming the member of staff, so the log answers whether Sigil touched your data without your having to ask. See actions taken by Tophhie Cloud support.

The operator audit log is the second record. It spans every organisation rather than one, which is why it is Tophhie Cloud’s copy rather than yours, and it is retained indefinitely and can be exported. Keeping both is deliberate: your copy is deleted with your data, and a record of an operator action that a purge destroys would evidence nothing about that purge.

Neither is pruned and neither can be edited.

Sigil can export everything held about a single mailbox, which is what a subject access request under GDPR or similar regimes needs. Request it through support.

One file answers the request. It carries that mailbox’s signature telemetry, the values the person entered in your profile fields, their portal role, any exclusion covering them and the note written against it, and the record of them signing in before your organisation connected. The full list, and what is deliberately left out of it, is in data and privacy.

Erasure of an individual mailbox is deliberately not offered. Removing one person’s entries from an append-only audit trail would undermine the trail, so the available erasure path is a full tenant purge.

For your directory data, your signature content and your usage telemetry, your organisation is the controller and Tophhie Cloud is the processor. Sigil acts on your documented instructions, on the terms of the DPA below. Deciding the lawful basis for that processing is your organisation’s job, not Sigil’s.

Tophhie Cloud is the controller for a narrower set of records it holds in its own right, and the published privacy policy states the basis for each: your tenant, subscription and billing records, on the contract with you and on the tax and accounting law that governs the financial part of it; portal access records, on that same contract and on the legitimate interest in keeping the portal secure and giving your administrators an audit trail; and the sign-up diagnostics, on the legitimate interest in telling a real administrator apart from the crawlers that follow a public sign-up link. The campaign tags recorded on a sign-up rest on the same basis, as a legitimate interest in measuring Tophhie Cloud’s own advertising.

Product update emails to administrators and partner staff are Tophhie Cloud’s own processing too, on the legitimate interest in keeping existing customers informed about the service they use. The list of addresses that have opted out of them is kept on the legal obligation to honour an objection. Every product update carries a link that stops them for the recipient’s address, and an administrator can switch them off for the whole organisation. See emails Sigil sends.

Questions typed into Ask the documentation are processed on the legitimate interest in answering them from the documentation. Neither the question nor the answer is kept.

The privacy policy sets out the rights a person in the UK or the EEA has over their data: to be informed, of access, to rectification, to erasure, to restriction, to portability, and to object. It names the Information Commissioner’s Office as the UK supervisory authority for a complaint, and the authority for the person’s own country in the EEA.

Requests about your directory data, signature content and telemetry go to your own administrators, because your organisation controls that data. Tophhie Cloud assists as processor and can locate an individual’s records by their email address. Requests about the records Tophhie Cloud controls go to privacy@usesigil.app, and are answered within one month.

Sigil makes no decision about a person by automated means. It does not profile individuals, score them, or decide anything about them without a human, so the right not to be subject to a solely automated decision has nothing to bite on here. That is worth stating plainly in a review, because a product that reads a directory and renders per-person output invites the question.

The DPA is published at portal.usesigil.app/dpa. Acceptance can be recorded against your organisation, with the accepted version tracked, so there is a record of what was agreed and when rather than an assertion that something was.

Accepting it in the portal also writes an entry to your own change log, deliberately, so you can evidence your acceptance from your own records rather than asking Tophhie Cloud for it.

Accepting records who accepted and when, against your organisation, and the confirmation says so before you agree rather than after.

You need the Admin role in the organisation itself. Staff at a provider who manage your organisation for you cannot accept it on your behalf.

  1. Open Billing in the portal sidebar.
  2. Choose the DPA tab.
  3. Choose Read the agreement to open the published text.
  4. Choose Accept on behalf of your organisation. The button names it.
  5. Choose Accept in the confirmation, which says which version you are accepting and that your name and the time will be recorded.

The card then shows an Accepted badge with the version, the date and who accepted it. When the prompt at the top of a portal page is showing, its Accept button does the same thing, and Remind me later puts it off for the rest of the browser session.

The agreement is versioned. When a revised version is published, an organisation whose record still names the earlier one is prompted at the top of every portal page until the version on record is the one in force.

The prompt is a prompt rather than a gate. Nothing stops working while it is outstanding, and it can be put off for the rest of the browser session, but it returns on the next sign-in. Putting off one version’s prompt does not suppress the next, since the dismissal is keyed to the version being asked about.

Only the people who can act on it see it: an administrator of the organisation itself. A managed service provider looking in at a client is not one of them, because the client is the controller and only a controller can give Article 28 instructions. For everybody else, the Billing page still explains who has to act.

What the agreement commits Tophhie Cloud to

Section titled “What the agreement commits Tophhie Cloud to”

Some of the processor obligations in the agreement are worth reading on their own, because nothing you can see in the portal evidences them.

Sigil processes your data only on your documented instructions, and the agreement defines what those are rather than leaving it vague: the agreement itself, the terms of use, and the configuration you make in the portal. Nothing you have not asked for is a lawful instruction. If law compels processing beyond that, you are told before it happens unless the law forbids the telling. An instruction that Tophhie Cloud believes breaks data protection law is raised with you rather than carried out quietly.

Staff authorised to handle your data are under a duty of confidentiality that outlasts their engagement, and access is limited to the people who need it to run or support the service. See operator access for the controls behind that second half.

The Article 32 security measures are documented across this section of the site rather than listed in one place: tenant isolation, authentication through Entra ID with roles you set, read-only Graph permissions your own administrator grants and can revoke, the change log, and the separation of operator access from customer access. The one measure not covered elsewhere is encryption: data is encrypted in transit with TLS, and encrypted at rest where it is stored.

Three companies process data on Sigil’s behalf, and the data processing agreement names all three rather than reserving the right to add more quietly.

Sub-processor What it does Where
Microsoft Identity through Entra ID, and directory data through Graph Your own tenant’s region
Cloudflare Application hosting, storage and caching Stored data in the EU, with cached copies on its global network
Stripe Subscription billing and card processing UK, EU and US

Your directory data and the content you author are stored in the United Kingdom or the European Economic Area. The databases, the uploaded images, the nightly database backups and the caches all sit in storage created in Cloudflare’s EU jurisdiction, which Cloudflare enforces as a limit on where the data may be kept rather than treating as a preference. The caches joined them on 27 October 2026.

Read copies of cached entries are the exception the agreement names in its own words. To serve a signature quickly wherever the person composing it happens to be, Cloudflare keeps short-lived copies of rendered signatures, and of the directory details they are built from, near whoever reads them on its global network, so those copies can sit outside the UK and EEA for as long as they live. They expire on their own and are never the record: the record is in the EU, and the caches are rebuilt from it. Retention for each is in the table below.

That caching, and any other movement of personal data outside the UK or EEA by a sub-processor, runs on an adequacy decision or on the UK Addendum to the EU Standard Contractual Clauses, which the agreement incorporates.

Microsoft appearing on that list is worth reading carefully, because it is not Sigil choosing a supplier. Your directory already lives in your own Microsoft tenant, in whichever region you chose when you bought Microsoft 365, and Sigil reads it there. Nothing about connecting Sigil moves it.

Adding or replacing a sub-processor carries 30 days’ notice. If you object on data protection grounds inside that window, you can end the affected part of the service without penalty and get a pro-rata refund of anything prepaid. That is a term of the agreement rather than a courtesy, which is the point of writing it down.

The notice reaches your administrators as an announcement from Tophhie Cloud, whatever their product update setting, and the 30 days are enforced when it is sent: a sub-processor change with less than that to run is refused. See emails Sigil sends.

The agreement commits Tophhie Cloud to telling you about a personal data breach affecting your data without undue delay, and in any event within 48 hours of becoming aware of it.

The notice has to say what happened rather than that something happened. It describes the nature of the breach, the categories and approximate number of people and records involved, the likely consequences, and what has been done or is proposed about it. Where all of that is not known at once, it is sent in phases rather than held back until the picture is complete, because a controller deciding whether to notify anybody needs the first facts early.

Forty-eight hours is deliberately shorter than the seventy-two your organisation has to notify its own supervisory authority, and the reason is arithmetic. Your clock starts when you are told, so a processor that took the full seventy-two would leave you none. Sigil is a processor here and the obligation to notify a regulator or the people affected stays with your organisation, which is the reason the notice is written to be usable as the basis for that decision.

The notice is an email to every administrator of your organisation, with the subject “Personal data breach notice from Sigil”. It comes from the usual sending address, and the text of it is written by a person at Tophhie Cloud, stating what is known at the time. Questions go to privacy@usesigil.app, or by replying to it. Tophhie Cloud records a first notice and the particulars that follow it under one reference, so the phases stay together in its own record.

Each one also leaves an entry in your change log reading “Sent your admins a data breach notice”, and Tophhie Cloud keeps its own record of the date and the addresses it went to. That gives your organisation evidence of when it was told, which is when your own 72 hours started.

Where your organisation is managed by an IT provider in the partner programme, the same arithmetic is applied once more. The provider is told what is known within 24 hours and given the full particulars within 48, because the chain has one more link in it and your 72 hours have to survive the extra hop. Where the provider asks for it, or cannot be reached, Tophhie Cloud notifies your own administrators directly rather than letting the notice stall with them.

Most compliance reviews are answered on paper, and the agreement says so rather than treating a questionnaire as a favour. Tophhie Cloud will make available the information reasonably necessary to demonstrate compliance with Article 28, and will complete one reasonable security questionnaire in any twelve-month period.

Where that is genuinely not enough to satisfy a supervisory authority, you have a right to audit. It runs on 30 days’ notice, no more than once a year unless a breach or a regulator requires otherwise, during business hours, subject to confidentiality, and without access to any other customer’s data. That last condition cuts both ways and is the point of stating it: the same term protects your organisation from somebody else’s audit.

If you are working through a procurement review, most of what a questionnaire asks for is already written down. This page and data and privacy cover the processing, the security model covers the controls, and the published agreements carry the commitments themselves. Ask support for the questionnaire route when you need something answered on your own form rather than found on a page.

Document Where
Privacy policy portal.usesigil.app/privacy
Terms of use portal.usesigil.app/terms
Data processing agreement portal.usesigil.app/dpa
Support portal.usesigil.app/support
Partner agreement portal.usesigil.app/partner-agreement

Tophhie Cloud staff can reach customer tenants for support, and that access is constrained rather than assumed.

Access is an explicit list rather than something implied by working at Tophhie Cloud, with two tiers. Support staff get a read-only console plus support tooling: tenant overview, exceptions, health, preview, audit, notes, read-only impersonation, messaging a tenant’s administrators, resending consent, and export. Operators additionally get mutations such as suspending, reprovisioning and deprovisioning.

Read-only impersonation is a session that expires on the server after 30 minutes, so a replayed request stops working once the window elapses rather than relying on the interface to stop offering it.

Read-only is enforced by the server rather than by the interface: while such a session is in force, every request that would change something is refused. The single exception is rendering a signature preview, which is a read that has to send the template in the body of the request rather than in its address. Without it an operator looking at a reported rendering fault would see an empty preview pane, which is the one thing they opened the session for.

In the console, a destructive action asks for a fresh interactive sign-in first. On the server, every destructive action is refused to anyone without the operator tier.

The operator list cannot lock itself out: the last operator cannot be removed or demoted.

Every operator action is written to the audit log, and every action taken on your organisation is written to your own change log as well. Segregating operator access from customer access is only half a control if the customer cannot see when it was used, so the visible half is what makes the separation checkable from your side rather than assertable from Tophhie Cloud’s.

A daily scan reconciles every tenant against Graph and billing and reports anything needing attention: directory access that has lapsed, past-due billing, trials ending within seven days, unfinished provisioning, seat drift, and a suspended tenant whose subscription is still charging.

The last of those is a safeguard rather than a health check. Suspending an organisation sets its billed seats to zero, so it stops accruing charges, but it does not cancel the subscription, which stays open so the suspension can be lifted without reprovisioning anything. The scan surfaces the open subscription so an operator either restores the organisation or closes it properly, rather than leaving one standing indefinitely against a tenant nobody can use.

Lapsed directory access is the one worth knowing about as a customer, because it breaks signatures quietly. The template is still there; there is simply no data to personalise it with. The scan catches it, and Tophhie Cloud can email your administrators a re-consent link.

Data Retention
Directory attributes read from Microsoft Graph Never stored as a record of their own. Held inside a rendered signature for at most a day (refreshed hourly while in use), in a lookup cache for seven days after it was last read from Microsoft 365 (fresh for fifteen minutes, then refreshed in the background), which a nightly pass keeps topping up for about a week after the mailbox last composed, so up to about two weeks in all, and in a photo cache for up to seven days (fresh for a day, then refreshed in the background). On the device, the add-in keeps the last signature it applied for about 45 days after the mailbox last composed
Template version history Last 10 published bodies per template
Preview pictures of a version, for signature previews As long as the version they show. They depict a sample person rather than anybody in your organisation
Deleted templates 30 days in Recently deleted, then purged by a daily sweep
Change log For as long as your organisation uses Sigil
Record of the notices the agreements require Tophhie Cloud to send you, such as a breach notice or notice of a change to an agreement For as long as your organisation uses Sigil. Holds what was sent, when, and to which addresses
Record of the emails Sigil sends about your organisation’s account For as long as your organisation uses Sigil. Holds what each email was, when it was sent, to which addresses, and whether it was delivered. A copy of the email itself is kept for 90 days, so support can see what you were sent when you ask about it, and is then removed
Operator audit log Indefinite
Tophhie Cloud’s own tenant, subscription and billing records For as long as your organisation uses Sigil, then for as long as tax and accounting law requires the financial records to be kept
Individual signature requests and apply outcomes 90 days, then purged by a nightly sweep
Per-mailbox activity rollup and daily apply totals For as long as your organisation uses Sigil
Daily click totals per tracked link For as long as your organisation uses Sigil
Per-click records behind the analytics splits 90 days, then purged by a nightly sweep
Onboarding attempt records Indefinite, and outside the tenant’s own data
Sign-up diagnostics held on those records 90 days, then cleared while the attempt stays
Campaign tags on a sign-up The utm_ tags stay with the attempt. The Microsoft Advertising click id is cleared at 90 days with the diagnostics
Sign-ins from an organisation that never connected 90 days from the last sighting, then removed in full
Recent changes behind the portal’s live updates The last 200 or the last 24 hours, whichever is less. Ids, statuses and the acting administrator’s address only
Addresses opted out of product update emails Until that person opts back in. Holds the address and the date only

Deprovisioning a tenant purges all of it except the onboarding attempt records and the diagnostics on them, which describe an attempt to connect rather than a live organisation, the operator audit log, a managed service provider’s own event history, and the product update opt-outs, which belong to a person rather than to an organisation. That includes every row above marked “for as long as your organisation uses Sigil”: the change log, activity rollups and daily totals have no expiry of their own, and go when the organisation does. A sign-in recorded before an organisation connected is purged with that organisation too, since the whole record is personal data rather than an account history.

The coverage of that purge is checked automatically rather than maintained by hand, so anything Sigil starts storing against an organisation has to be either purged or recorded as a deliberate exception. See data and privacy.

Deletion on termination, and what backups mean for it

Section titled “Deletion on termination, and what backups mean for it”

You can export your templates, images and activity data yourself at any time from the portal, and nothing about ending the service is a precondition for getting them.

Cancelling your subscription does not start deletion. Your data is kept so that, if you come back, your signatures are restored as you left them. Once you ask for deletion, in writing to privacy@usesigil.app or through support, your organisation’s data is deleted within 30 days, except where law requires it to be kept. The purge itself is described in data and privacy, which is about the live systems: the records, the stored images and the cached entries all go when it runs.

Backups are the part that a purge cannot reach, and the agreement says so rather than letting “everything is deleted” imply otherwise. A backup holding your data is overwritten on its normal cycle, within 90 days, and stays covered by the data processing agreement until it is. So the honest answer to “when is it all gone” is that the live systems are cleared on the purge and the last copy expires inside 90 days, not that both happen at once.

This matters for one kind of request in particular. If you are answering an erasure request by deprovisioning, the date you can commit to is the backup expiry rather than the purge, and it is better to say so than to discover the distinction afterwards.

Sigil does not sit in your mail flow. It writes into the compose window, so it never sees, stores or processes the content of the messages people send.

That is a meaningful distinction for a compliance review, and it is a different architecture from server-side signature products that rewrite mail in transit.