Security

Where we start

Both of our products sit next to somebody's business email. Footersly can change what every message from an organisation says; MailAuthInspector knows which of a company's domains are weakly protected. Neither is a place for optimism about security.

So the design starts from what we can avoid holding, moves to what we must hold and how little of it, and only then to controls. The paragraphs below describe what is actually in place. We have deliberately not claimed a certification we do not hold.

Data, and what we never have

• We do not read message content. Footersly applies templates and needs directory fields; MailAuthInspector reads public DNS and the aggregate reports you choose to send it. Neither product is granted access to mailbox contents, and neither needs it.
• We never see your password. Account holders authenticate through Microsoft Entra ID. We receive an identity token, not a credential, and we store no passwords at all.
• Data in transit is encrypted with TLS 1.2 or better, with modern cipher suites and HSTS on every site we run.
• Data at rest is encrypted in our hosting provider's managed storage, including databases and backups.
• Secrets — API keys, connection strings, signing material — are held in a managed secret store, never in source control, and are rotated on a schedule and on any suspicion of exposure.
• Residency. Customer data is held in UK or EEA regions. Every sub-processor is named on the sub-processors page.

Access to your organisation

This is the control customers ask about most, so it is worth being specific. Nobody here browses a customer's tenant out of curiosity.

• Production access is limited to the engineers who need it to run the service, requires multi-factor authentication, and is reviewed quarterly.
• Support access to a customer organisation is granted by that customer, is time-limited, and ends automatically.
• Every administrative action is written to the change log the customer can read — including actions by a provider's delegate who holds no account in the tenant and appears in no user list. If we look, you can see that we looked.
• Within a customer organisation, rights are granted one area at a time, and only an organisation admin can change somebody's role. A view-only right is enforced at the HTTP verb, not merely by hiding buttons.
• Staff are bound by confidentiality, trained on data protection at induction and annually, and have access removed the day they leave.

Infrastructure

• Services run on managed cloud infrastructure in UK and EEA regions, behind a provider-managed edge with TLS termination and denial-of-service protection.
• Environments are separated: development, staging and production share no data and no credentials.
• Production data is never copied into a development environment. Test data is synthetic.
• Administrative interfaces are not exposed to the public internet.
• Platform patching follows the provider's managed cadence; our own images and dependencies are rebuilt and redeployed on a regular schedule and out of cycle for a critical fix.
• Logging and alerting cover authentication, authorisation failures and administrative actions, with alerts routed to the engineers on call.

How we build

• Every change is code-reviewed before it is merged. Nobody deploys straight to production.
• Automated tests run on every change, and a build that fails does not ship.
• Dependencies are scanned for known vulnerabilities on every build, and a known-vulnerable package either gets updated or the build stays red.
• Our web applications send a closed Content Security Policy, along with X-Content-Type-Options, Referrer-Policy and Permissions-Policy. This brochure site loads nothing from any other origin at all.
• Input is validated on the server, output is encoded by the framework, queries are parameterised, and state-changing requests carry an anti-forgery token.
• Changes to authentication, authorisation or data handling get a second pair of eyes specifically for the security question, not just for correctness.

Identity and authentication

Sign-in is federated to Microsoft Entra ID, which means your own conditional access policies, multi-factor requirements, device compliance rules and sign-in risk policies apply to our products without us having to reimplement any of them. Disabling a user in your directory removes their access here. Sessions expire, and privileged actions re-check rights at the time they are performed rather than trusting a token issued earlier.

Backups and continuity

• Databases are backed up daily with point-in-time recovery, and backups are encrypted.
• Restores are tested, because an untested backup is a hope rather than a control.
• Deleted customer data ages out of backups within 35 days of deletion from the live systems.
• Infrastructure is defined as code, so a region or an environment can be rebuilt rather than recovered by hand.

Incidents and breach notification

We have a written incident response procedure. In outline: contain, assess, notify, fix, then write down what we learned and change something so it cannot happen the same way twice.

• Where we are the controller and a personal data breach is likely to risk people's rights and freedoms, we report it to the Information Commissioner's Office within 72 hours of becoming aware of it.
• Where we are a processor, we tell the affected controller without undue delay so that they can meet their own duty, and we give them what they need to do it.
• Affected customers get a factual account — what happened, what data was involved, what we have done, and what we recommend they do — not a holding statement.

Reporting a vulnerability

If you have found a security problem in this website, in Footersly or in MailAuthInspector, please tell us.

Coordinated disclosure

Where to send it	security@trustlayertechnologies.com
Acknowledgement	Within 2 working days
Triage and initial assessment	Within 5 working days
Fix target	Critical within 7 days; high within 30 days; everything else at the next reasonable release
Credit	Offered if you want it, and declined gracefully if you do not. We have no bug bounty and will not pretend otherwise

Helpful reports include the affected URL or endpoint, the steps to reproduce, what you were able to achieve, and anything about the impact that is not obvious. Please give us a reasonable opportunity to fix the issue before publishing it, and we will keep you informed rather than leaving you waiting.

Testing scope and safe harbour

Research that stays within the boundaries below is authorised. We will not pursue legal action, and we will say so in writing if anybody else suggests we should.

In scope: this website, and the Footersly and MailAuthInspector applications, tested against your own account, your own tenant and your own domains.

Out of scope — please do not:

• run denial of service or volumetric load tests;
• access, modify or delete data belonging to anybody but you;
• social engineer our staff, customers or suppliers, or attempt physical access;
• test our suppliers' own systems — Microsoft and our hosting provider have their own disclosure programmes, and their infrastructure is theirs, not ours;
• use automated scanning that degrades the service for other users, or spam the contact form as a test;
• publish customer data you encounter, in a write-up or anywhere else.

If you are not sure whether something is in scope, ask first at security@trustlayertechnologies.com. Asking is never the wrong move.

Assurance, and documents for procurement

We are a small company and we are straight about what that means: we hold no ISO 27001 or SOC 2 certification today, and we will not imply one. What we can provide, on request and under NDA where appropriate:

• a completed security questionnaire, or our answers to your own standard form;
• our data processing agreement, including the sub-processor list and transfer mechanisms;
• a description of our incident response procedure and escalation contacts;
• architecture and data flow diagrams for the service you are buying;
• the results of the most recent penetration test, where one has been carried out.

Ask at security@trustlayertechnologies.com and tell us what your review needs; we would rather answer the real question than send a brochure.

Questions about this document

Write to privacy@trustlayertechnologies.com for anything about data protection, or hello@trustlayertechnologies.com for everything else. Post reaches us at the registered office: to be confirmed.