Security & Trust

Last updated: 2026-10-15

This page explains the security measures Notavia operates, what the evidence for each one actually is, and which measures are still intentions rather than operating controls. It is not a certification, audit report, penetration-test report, or guarantee.

Two words are used deliberately throughout. Source-evidenced means the control is implemented in the reviewed application source; it says nothing about whether it is running in production. Deployment-evidenced means the control was measured on the production deployment and the measurement is recorded. Everything else is stated as an open gate, with what would have to be produced to close it.

For Customers whose processing is covered by our Data Processing Agreement, the binding technical and organisational measures are the separately versioned measures in DPA Schedule 2. This page does not silently amend an accepted DPA.

Deployment Status

Notavia is deployed. The managed service runs on a dedicated Hetzner server in Falkenstein, Germany, and the application, its PostgreSQL database, the administrative console and the log store all run on that single host.

The managed service is generally available. Since 31 August 2026 the application, its API, the preference centre and the tracking endpoints have been reachable from the public internet, alongside this website and the documentation site, which are served from that same host. The operator consoles are the exception: they are not publicly reachable, as described below. As of the date of this page, no Customer organisation, other than Tessora's own test organisations, has accepted the Data Processing Agreement.

The payment-provider webhook path is public by necessity, because the payment provider has to be able to deliver to it from its own infrastructure. That endpoint authenticates every request by signature and fails closed on each path: an unconfigured signing secret is refused rather than trusted, an absent or invalid signature is rejected, and a timestamp check bounds replay.

The operator consoles — the administrative console and the log store — are not reachable from the public internet. Their hostnames share the public edge listener with the rest of the service, so what holds them is not the address they are served on but an edge rule: any HTTPS request for them that does not arrive over our private network is refused, and the connection is closed without a response rather than answered with an error. Their original port-based listeners are published only on the private-network address. Every deployment of the managed service checks this from a source outside the private network: both consoles must be refused on their hostnames, their port-based listeners must not answer on the public address, and the public hostnames must answer that same source, so that a source unable to reach the server at all cannot pass as a refusal. Using the administrative console additionally requires the operator privilege described under Privileged access below.

Two consequences follow, and both matter when reading the rest of this page. First, every deployment-evidenced measurement on this page was recorded before general availability, while the managed service was reachable only over a private network, so none of them is evidence of behaviour under public traffic; controls that can only be evidenced against real traffic, real Customers, or a public attack surface are not evidenced, and are stated below as gates. Second, because no Customer organisation other than Tessora's own test organisations has accepted the Data Processing Agreement, no Customer has yet relied on any measure described here.

What is Operating

Hosting and location

Deployment-evidenced. The production host is in Falkenstein, Germany, inside the European Union. The database is not a managed third-party service; it runs on the same host as the application.

Transport security

Deployment-evidenced. Public certificates are issued automatically over ACME using DNS-01 validation, and issuance was verified from an independent machine over public DNS with default certificate verification — that is, the whole chain from name resolution to certificate validation, not the server's own opinion of itself. The edge terminates TLS. The database, the administrative console and the log store publish no public port.

The application source emits content-security, anti-framing, content-type, referrer, permissions, cross-origin-opener, and HTTPS-only HSTS headers. That is source-evidenced and covered by tests. Equivalent content-security and frame-ancestors policies are configured for the non-application hostnames at the edge, but we have not verified that they are being served there, and a policy that is fully wired and silently inert is a failure mode this project has already met more than once — so it is listed here as configured, not as operating. A response-header check against each hostname is what would close it.

Outbound mail transport

Deployment-evidenced, including its limit. Mail sent through the managed sender uses opportunistic STARTTLS: the connection to the receiving server is encrypted where that server offers encryption, and delivery is not refused where it does not. That is a deliberate setting rather than an oversight. Enforcing TLS would convert a receiving mail server's outdated configuration into a bounce, and bounces feed suppression, so enforcement would silently and permanently block legitimate recipients whose own providers are behind. TLS is hop-by-hop in any case, so no configuration of ours can promise encryption on every hop to a Recipient.

Sender authentication is verified rather than assumed: SPF, DKIM and DMARC all pass and both align, read from a receiving server's own message headers rather than from a sending console. That measurement was taken on live messages sent through the production system-email credentials. Both sending identities carry the same DKIM signing and the same custom envelope domain, so the result applies to the managed sender too — but it was not separately measured on a managed send, and the distinction is recorded rather than smoothed over.

Identity, authentication, and authorization

Source-evidenced. Account passwords are handled by ASP.NET Core Identity. The application does not store plaintext passwords and exposes no function that recovers an existing password. Users can enable authenticator-app TOTP multi-factor authentication; MFA is not mandatory for every Customer or operational account.

Sign in with Google is available on the production login page. Where a Customer's user signs in that way, the identity rests on the verified email address the provider asserts, which means the security of that Google account becomes part of the security of the Notavia account.

Application access uses organization roles. API keys are generated from cryptographic randomness, stored as SHA-256 hashes, scoped by environment and permission, and revocable.

Tenant isolation

Source-evidenced and test-evidenced, not production-exercised. The application applies organization and, where relevant, environment query filters to tenant-owned data. Tenant-context checks fail when required tenant context is absent, and focused isolation tests cover representative cross-tenant routes. These are application-layer controls. They are not an independently audited isolation boundary, and because the deployment has never held more than one organization's real data, no production isolation exercise has been performed.

Logs, monitoring, and alerting

Deployment-evidenced, with stated limits. Application logs and traces are collected to a log store that runs on the production host and is reachable only over the private network. They are not exported to a third-party log processor, which was chosen deliberately: application logs carry organization identifiers and Recipient addresses, and exporting them would place a third party in the processing chain. Log retention is configured — 30 days for application logs, with a shorter 3-day window for high-volume database-polling noise.

The application also emits metrics, but no production metrics backend is configured, which is why operator alerting evaluates database state directly instead of metrics.

Four operator signals run every five minutes in production — failed sends, webhook delivery backlog, permanent webhook failures, and past-due subscriptions. They were confirmed to be reaching an operator by observing the delivery response, not by the absence of complaints.

A separate outbound heartbeat is intended as a dead man's switch: it is sent as the last step of a successful alerting run, so if the process, the container, the scheduler or the database fails, the pings stop. What is evidenced is the sending of that heartbeat, not the alarm. Whether the external check receiving it is currently armed is operator-maintained state that we have not independently verified, and a paused check never alerts — so this page does not claim that the absence of a heartbeat currently raises an alarm. Confirming the check is active, with its period and grace recorded, is what would close that.

The limits are as important as the controls. These are service-health signals, not security detection: there are no security-event detection rules. There is no running external uptime monitoring of the managed service. No staffed on-call rota exists. One alert route shares fate with the email channel it may need to report on. Audit data is not append-only or tamper-evident, and direct administrative reads of the database are not comprehensively captured in product audit logs.

Backups and restore

Deployment-evidenced. A scheduled nightly job dumps the entire production database, compresses it, validates the artifact itself rather than the exit status of the command that produced it, and uploads it off-site to object storage. A failed run alerts an operator rather than passing silently.

The off-site bucket was created with a European location hint. That hint is best-effort and is not a residency guarantee; no storage jurisdiction is contractually verified, and the credentials the production host holds cannot read the bucket's own settings to confirm where the objects sit. We state the hint because it is what was requested, not because it is proof.

Two of the three unverified facts on this page name the check that would close them, and this one did not. It does now, and it takes two steps because one is not enough. An account-scoped read of the bucket's own settings, which the production host's object-scoped credentials cannot perform, recorded as evidence of what the provider's account reports. Then a contractual data-location commitment from the provider for that bucket. The read alone narrows the uncertainty without closing it — a hint read back from an account is still a hint — so it is the commitment that closes this, and until both exist the sentence above stands as written.

A restore has been rehearsed from the off-site copy — the copy that survives losing the host — into a scratch database, with the real production image booted against the restored data and every outbound credential blanked. Blanking is not a formality: a restored dump contains queued work, so an application booted against it believes that work is still pending and is one scheduler tick from re-sending real messages.

A dump is never edited. Deleting a record from the live database therefore has no effect on a dump that already exists; the record leaves the backup set when that dump ages out. Each copy is kept at least 14 days, by a different mechanism. The copy on the production host is pruned by age by the backup script, on the first nightly run at which a dump is more than 14 whole days old, so in practice on its fifteenth day. The off-site copy is not pruned by the production host at all: a bucket-level retention lock with a 14-day age, combined with a 14-day lifecycle rule, refuses both deletion and overwrite of an object and then expires it, and that expiry is carried out by the storage provider at a moment we do not control.

The production host consequently cannot delete or overwrite an off-site backup. That immutability is a deliberate control against ransomware and against a compromised host, and its cost is stated rather than hidden: a deletion cannot be reached into a backup and applied early.

Fourteen days is the floor on how long we keep a backup, not a deadline by which a deletion clears one. A record deleted from the live database is absent from the whole backup set only once every dump containing it has aged out, which is about 15 to 16 days after the deletion, and longer if a nightly run is missed or the provider's expiry lags. We do not publish a shorter figure.

Two limits remain, and they are stated as limits.

No restore has ever been performed into production, as opposed to into a scratch database.
No deletion has ever been replayed through a restore. There is no evidence that a restored copy would be returned to a state consistent with deletions made after the backup was taken.

No recovery point objective and no recovery time objective are published. Backups are nightly, and because no restore into production has been performed, no recovery time has been measured. A published objective that has never been rehearsed would be a number, not a commitment.

What is Not Operating

Each item below is a gate. It states what is missing and what would close it.

Encryption at rest

Connected-provider secrets supported by the reviewed code are protected at the application field level using ASP.NET Core Data Protection. Deployment configuration supplies other application secrets. Beyond that, this page does not claim encryption at rest. No full-disk, database-level, or Tessora-controlled object encryption has been evidenced for the production host or for backup artifacts, and the source does not establish who controls a production data-protection key, how it is backed up, or how it is rotated. Closing this requires a recorded encryption configuration for the host volume, the database and the backup objects, plus a key-control, rotation and recovery record.

Privileged access

Administrative access to production is standing rather than just-in-time, and it is manually granted. Administrative interfaces are not reachable from the public internet and require an operator privilege that no ordinary account holds, and denial was verified before the privilege was granted rather than only after. But no least-privilege review, approval record, expiry, revocation record, enforced operational MFA, or comprehensive privileged-read log exists. Closing this requires an approved access model with grant, read, export and revocation records, and a periodic review.

Vulnerability scanning and patching

The current CI workflow contains a blocking known-vulnerability check for direct and transitive NuGet dependencies in the shipped application project, followed by project-scoped automated tests. There is no equivalent evidence for container images, base images, operating-system packages, the production host, dynamic application scanning, or infrastructure scanning, and no production patch cadence or emergency-patching record has been produced. Closing this requires scanning coverage for each of those layers together with a risk-based remediation record.

Incident operation

The classification, assessment and communication procedure below is written and was table-topped against the source, the configuration and the deployment. What has not happened is an exercise against a running service: no security incident, personal data breach notice, administrator-access request or restore into production has been carried out. There is no restricted immutable case store, no evidence of private-notice delivery, and no staffed rota. Closing this requires an exercised end-to-end incident, with the case record and delivery evidence retained.

Independent assurance

Notavia has not commissioned or supplied a Tessora SOC report, ISO 27001 certificate, independent security audit, or independent penetration-test report. No such work has been performed at all, so there is no report to withhold. Vendor certifications certify those vendors; they do not certify Tessora or Notavia. Closing this requires commissioning the work and publishing that it happened.

Incident and Breach Communications

A service incident is an availability or performance event. A security incident is an event that may affect confidentiality, integrity, or availability. A personal data breach is a security incident involving accidental or unlawful destruction, loss, alteration, unauthorized disclosure of, or access to personal data. One event can fall into more than one category.

Generic availability information may be posted to the status page. The status page will not identify a Customer, affected person, confidential investigation detail, exploit path, or personal data. It is not the contractual channel for a security incident or personal data breach.

For a confirmed personal data breach affecting Customer Personal Data, Tessora will notify affected Customer organization Owners and Administrators through a private security route without undue delay and in any event within 72 hours of confirming the breach, and provide available information in phases. That bound is contractual: it is DPA section 10.

No acknowledgment clock is promised, and that remains deliberate rather than an omission. The distinction is worth being precise about. A notification bound is a commitment about something Tessora controls once it knows — writing to the affected Customers. An acknowledgment clock would be a commitment about how fast a person answers, and no rota is staffed to keep one, so publishing it would be publishing a number we would miss. Customers remain responsible for their own controller notifications; where GDPR or UK GDPR applies, a controller may need to notify its competent supervisory authority within 72 hours after awareness where the breach is likely to risk individuals' rights and freedoms, and affected individuals without undue delay where high risk is likely. Tessora separately assesses any duty it has as controller for its own processing.

Every suspected personal data breach must be recorded with the known facts, effects, assessment, decisions, notices, evidence, and remedial action, including a documented reason when a regulator or individual is not notified. The current procedure is documented in the internal security evidence register. Operator alerting for selected service-health conditions now runs in production and reaches a person, but private-notice delivery, evidence capture, breach-register operation and post-incident review have not been exercised against a running service.

Reporting a Vulnerability

Report a suspected vulnerability to security@saas-infrastructure.com. Include the affected service or URL, a concise impact description, reproducible steps, and any supporting evidence that can be shared lawfully. Do not include unnecessary personal data, access other Customers' data, disrupt the service, use denial-of-service testing, or publicly disclose an unresolved issue in a way that increases harm.

Reports are triaged according to the evidence and potential impact. We may ask for more information and will coordinate remediation and disclosure where practicable, but we do not promise an acknowledgment or remediation time that is not staffed and measured. We do not currently publish a /.well-known/security.txt file or offer an encrypted submission channel. No paid bug-bounty program is offered.

What This Page Does Not Claim

Stated together so that a reader does not have to infer a claim from a silence:

no certification, independent audit, or penetration test — none has been performed;
no encryption at rest below the application field level;
no off-site backup residency guarantee. A European location hint was specified; it is best-effort, it is not a guarantee, and no storage jurisdiction is contractually verified;
no dead-man's-switch alarm. The heartbeat is sent; the external check's armed state is not independently verified;
no verification that the edge content-security policies are live on the non-application hostnames;
no verification of Customer-selected connected-provider transport routes;
no acknowledgment, response, or remediation clock. A breach-notification bound does exist — 72 hours from confirmation, in DPA section 10 — and is the one clock on this page;
no staffed on-call coverage and no security-event detection;
no recovery point objective and no recovery time objective;
no restore into production and no deletion replayed through a restore;
no independently audited or production-exercised tenant-isolation boundary;
no scanning coverage beyond the dependency gate described above;
no deployment-evidenced measurement on this page was recorded under public traffic, other than the per-deployment console check described under Deployment Status, whose individual results are not recorded here;
no representation that a measure evidenced before general availability behaves identically now that the service carries public traffic.

Data Portability and Switching

You can ask to leave Notavia, or to move to another provider, at any time, and we make no switching, data-export, or data-egress charge. The contractual terms are in Section 15 of the Terms of Service, under "Switching and Data Portability". This section summarises them and does not change them.

Self-service export. An organization Owner or Administrator can request an organization export in Settings. The export is a single JSON file that lists its own coverage and any collection limit. Only the person who requested it can download it. The download is refused 7 days after the file is produced, and a daily job then deletes the file unless a legal hold applies to the organization.
Self-service limits. The self-service file holds the most recent 20,000 notifications, 50,000 notification events, 50,000 tracked links, 20,000 webhook deliveries, 20,000 workflow runs, 50,000 workflow step runs, 50,000 audit log entries, and 50,000 preference audit log entries, and every other collection in full. Where a collection is larger than its limit, the file records the limit, and on request we export the complete collection at no charge.
Switching, porting, and complete exports. Email support@saas-infrastructure.com to ask to switch to another provider or to your own infrastructure, to port your data, or to have your exportable data erased on termination, or to ask for a complete export of any collection that the self-service file limited. The notice period ends on the date you name in the request, no later than two months after we receive it, or on receipt if you name no date. A transitional period of up to 30 calendar days follows; if 30 days is technically unfeasible, we tell you within 14 working days after the request and state an alternative transitional period of no more than seven months, and you may extend the transitional period once. When we receive a switching or porting request we produce a complete export of the exportable data, and at the end of the transitional period we produce a final export of the data as it then stands. We keep that switching export until the data-retrieval period ends, which is at least 30 calendar days after the final export is delivered, or, if you choose erasure on termination, until deletion starts. During the transitional period we continue to provide the Service and give reasonable assistance to you and to any provider you authorize. A request to delete data without switching or porting follows the deletion terms earlier in the same Section.
Format. The self-service export file is UTF-8 JSON, with one named array per data collection alongside the file's coverage record. Field names follow the product's internal data model. Provider credentials, API key material, signing secrets and other secrets are not exported; the related configuration is exported without the secret. Section 15 of the Terms lists every exported category, covering the self-service file and the categories provided on request, and every excluded category.
Where the infrastructure is. The production host and its database are in Falkenstein, Germany, in the European Union. Mail sent through the managed sender is relayed through Amazon Simple Email Service in its Frankfurt region, and off-site backups are held in Cloudflare R2 under a European location hint that is not a residency guarantee; the Subprocessor List records each vendor's location and contract position. Tessora LLC is a company organized under the laws of the State of Wyoming, United States, so United States law also applies to Tessora itself. Amazon Web Services and Cloudflare are also United States companies.
Requests from public authorities. For a legally binding demand for Customer Personal Data, Section 12.2 of the DPA applies: unless the law prohibits it, we promptly notify the Customer, and we review the demand for validity, seek to narrow a disproportionate demand, challenge it where there are reasonable legal grounds, disclose only what we are legally required to disclose, and document the response. These commitments do not promise that we will prevail against a lawful demand or that no government can access data. They are made for Customer Personal Data. For Customer Data that is not personal data, Section 9 of the Terms treats it as the Business Customer's Confidential Information: we may disclose it where lawfully compelled, provided we give advance notice where legally permitted and reasonably assist with protective measures. The Terms do not add the validity-review, narrowing, challenge, or documentation commitments of DPA Section 12.2, and Section 11 of the Terms allows us to report suspected illegal activity to competent authorities.

Governance and Contact

The role-based Owner approved this evidence-bounded page and accepted the current unavailability of qualified legal review as a launch risk. Qualified counsel has not approved it. Tessora has not appointed a Data Protection Officer, an EU representative, or a UK representative.

Security incidents and vulnerabilities: security@saas-infrastructure.com

Privacy and data-protection questions: support@saas-infrastructure.com