Security
Read-only where possible. In-region. No mailbox content, ever.
This page is written for the person doing the security review. It says what we access, why, where it lives and what we don’t hold. If something is missing, email us and we will add it.
Last updated 27 September 2026
No message bodies stored
Mail is processed in transit and not written to disk.
Region you choose
US, Australia or EU. Data does not leave it.
Least-privilege scopes
Read-only directory access; you can revoke it any time.
Data residency
Each account is pinned to one region at sign-up. Directory data, templates, assignment rules, audit logs and backups all stay inside that region. Support staff access is logged and limited to the region’s environment.
United States
N. Virginia (us-east-1)
For US, Canadian and Latin American customers.
Australia
Sydney (ap-southeast-2)
For Australian and NZ customers.
European Union
Frankfurt (eu-central-1)
For EU and UK customers.
Every plan chooses its region at sign-up; there is no surcharge for any of the three. Moving regions later is a supported, assisted operation.
How tenant connection works
You connect by signing in as an administrator and consenting to a fixed set of scopes. We never ask for a service account password, and nothing is installed on endpoints. Consent can be withdrawn from your admin console at any time, which immediately stops all access.
Microsoft 365
Directory access is via Microsoft Graph with application permissions granted by admin consent. Signature injection uses an outbound connector and a transport rule in Exchange Online, created in your tenant with your credentials during setup.
- User.Read.All
- Read user profiles to populate signature fields.
- Group.Read.All
- Read group membership for assignment rules.
- Organization.Read.All
- Read tenant name and verified domains.
- Exchange: connector + transport rule
- Created in your tenant by you, during setup, to route outbound mail through the signature service. You can inspect and remove them at any time.
Google Workspace
Access is through a service account with domain-wide delegation, restricted to the scopes below. Signatures are written to each user’s Gmail settings; Google then renders them in every client.
- admin.directory.user.readonly
- Read user profiles for signature fields.
- admin.directory.group.readonly
- Read group membership for assignment.
- admin.directory.orgunit.readonly
- Read OU structure for assignment.
- gmail.settings.basic (domain-wide delegation)
- Write the signature setting for each user. This scope cannot read message content.
What we never store
Message bodies or attachments. For Microsoft 365, mail passes through the signature service in memory, has the signature appended, and is returned to Exchange Online. It is not written to disk or logged. For Google Workspace, mail never touches us at all.
Mailbox contents. We have no scope that can read a mailbox. The Google Gmail settings scope cannot read messages; the Graph scopes we request are directory-only.
User passwords. Authentication is OAuth consent or SSO. There is no service account password to rotate.
Recipients of individual emails. Click analytics records that a link in a signature was clicked, by template and campaign, not who received the email.
What we do hold: the directory fields you map into signatures (name, title, phone and similar), group and OU membership, your templates and images, assignment rules, the audit log and billing contact details.
Encryption
In transit
TLS 1.2 or higher on every connection, including between our service and Exchange Online (connector configured to require TLS) and to Google APIs. HSTS is enforced on all our domains.
At rest
Databases, object storage and backups are encrypted with AES-256 using provider-managed keys. Directory tokens are additionally encrypted at the application layer with keys held in a hardware-backed KMS in your region.
Certifications and standards
Plain statement of where we are. UnifySig does not currently hold a SOC 2 report or ISO 27001 certification. Our controls are designed to align with SOC 2 Trust Services Criteria and ISO 27001 Annex A, and a SOC 2 Type I engagement is in progress. We will publish the report here when it is issued and will not describe ourselves as certified before then.
- Hosted on AWS infrastructure that holds SOC 1/2/3, ISO 27001, IRAP (Australia) and other attestations. Provider attestations cover the infrastructure layer, not our application.
- Annual third-party penetration test of the application and tenant connection flow; summary letter available under NDA.
- Designed to support customers’ obligations under the Australian Privacy Act, the NZ Privacy Act 2020 and the GDPR.
- Security questionnaires (SIG Lite, CAIQ, your own) answered for Enterprise prospects.
Sub-processors
Third parties that may process customer data on our behalf. We give 30 days’ notice by email before adding one.
| Provider | Purpose | Location |
|---|---|---|
| Amazon Web Services | Application hosting, database and object storage | Region you select (AU, EU or US) |
| Cloudflare | DNS, TLS termination, DDoS protection, this website | Global edge; no customer data stored at rest |
| Stripe | Billing and card processing | US / AU |
Data processing agreement
A DPA covering the GDPR, UK GDPR and the Australian Privacy Principles is available on request for Business plans and is included in Enterprise agreements. It sets out our role as processor, the sub-processor list above, breach notification within 72 hours, and deletion of all tenant data within 30 days of termination. We also sign customer paper on Enterprise when the terms are reasonable.
Request the DPAReporting a vulnerability
Use the contact form and mention security in the message; it reaches the engineering team directly. We acknowledge within two business days and will not take legal action against good-faith research that respects customer data.
Still have questions for the review?
Send the questionnaire. We reply with answers and evidence, not a sales deck.