Data Processing Agreement

Last updated: 2026-08-18

1. Parties, Scope, and Roles

This Data Processing Agreement ("DPA") is between Tessora LLC, a Wyoming limited liability company ("Tessora", "Processor", "we", or "us"), and the Business Customer identified in the organization account or applicable Order Details ("Customer"). It supplements the Terms of Service for the managed Notavia service.

An Authorized User accepts this DPA for the Customer, not in a personal capacity. The Terms' definitions of Authorized User, Business Customer, Customer Data, Order Details, Recipient, and Service apply here.

This DPA applies worldwide where Tessora processes Customer Personal Data on the Customer's behalf through the Service. It does not make any law apply where that law would not otherwise apply, provide legal advice, or establish that the parties' processing is sufficient under every law. The Service remains a worldwide business-to-business managed service; this DPA does not create a country allow-list, an EEA or UK exclusion, or a legal-region selection.

For Customer Personal Data:

• Customer is a controller and Tessora is its processor; or
• where Customer processes for another controller, Customer is that controller's processor and Tessora is Customer's subprocessor. Customer confirms that the relevant controller authorized Customer's instructions and Tessora's appointment.

Customer Personal Data means personal data contained in Customer Data or generated by the Service solely to carry out Customer's instructions. It includes Recipient information, message and template content, preferences, suppressions, tracking data, delivery and Recipient events, and connected-provider configuration described in Schedule 1.

Tessora acts separately as a controller for business-account administration, its own service security, billing administration, support, legal compliance, and other purposes described in the Privacy Notice. Those controller activities are outside this DPA. Customer's agreement with Tessora is not Tessora's Article 6 legal basis for processing Customer Personal Data for Customer's purposes, and it is not Customer's legal basis for contacting or tracking Recipients.

No data protection officer has been appointed by Tessora. No EU or UK representative has been appointed. Contact support@saas-infrastructure.com for this DPA and security@saas-infrastructure.com for a suspected security incident.

2. Formation, Evidence, Duration, and Precedence

2.1 Acceptance and version evidence

This DPA takes effect when an Authorized User affirmatively accepts this identified version for the Customer, or when a signed Order Details document expressly incorporates it. The acceptance record must identify, as applicable:

• the Customer organization identifier and organization name;
• the Authorized User identifier and account email;
• the dpa document slug, DPA version, and effective version;
• the Terms version, the transfers document version, selected EU SCC module or modules, UK Addendum applicability, and any incorporated order-form version;
• the exact attestation presented, or an immutable reference or hash that reconstructs it;
• the acceptance timestamp, surface or context, and affirmative action; and
• the IP address and user agent if retained for contract evidence.

Checkout evidence may additionally identify Paddle transaction facts, including billing country and actual transaction currency. Those facts do not select a legal regime or change the DPA's worldwide scope.

Tessora must preserve the accepted document version and associated evidence. Where the Data Transfer Addendum applies, its completed Organization Transfer Record is part of this evidence and must preserve the party, role, module, mandatory-clause, annex, immutable-copy or hash, and acceptance fields specified there. A materially revised DPA or Transfer Addendum requires new affirmative organization-level acceptance before the revised version governs existing processing, unless a change is required sooner by law and the law permits another method. DPA reacceptance and transfer-package reacceptance are not in the same position, so they are stated separately. DPA reacceptance is a gate: the application blocks organization dashboard entry until an Authorized User who can bind the organization has accepted the current DPA version, and the acceptance record binds the Schedule 2 and Schedule 3 versions accepted as well as the DPA's own. Transfer-package reacceptance is detected and required at the transfer surface, not at the door: a change to the Transfer Addendum version, the DPA version or either frozen schedule version is treated as material and calls for a new affirmative organization-level acceptance there, which is not the same as blocking the rest of the Service, and this DPA does not claim that it is. The Organization Transfer Record written by that acceptance carries every party, role, module, mandatory-clause, annex, hash and acceptance field the Transfer Addendum lists. The door gate, the transfer record, its full-text-and-hash storage and the reacceptance detection are all running in the image the production service serves. One limit remains: no organization has ever accepted this DPA or a transfer package, so there is no acceptance evidence to inspect.

2.2 Duration

This DPA applies while Tessora processes Customer Personal Data, including any period after subscription cancellation needed to return or delete it under Section 11. Duties that by their nature apply after termination, including confidentiality, deletion, audit, and transfer-clause duties, survive for as long as relevant Customer Personal Data remains.

2.3 Precedence

If documents conflict regarding Customer Personal Data:

1. mandatory terms of the UK Addendum control a covered UK Restricted Transfer;
2. the applicable unmodified EU SCC module controls a covered EEA Restricted Transfer;
3. the Data Transfer Addendum controls additional transfer safeguards that do not contradict the mandatory clauses;
4. this DPA controls processing on Customer's behalf;
5. a mutually signed order form controls the commercial, deployment, or service detail it expressly specifies, but does not reduce this DPA's data-protection obligations unless applicable law permits that change and the provision expressly identifies it; and
6. the Terms control other matters.

Order Details presented at checkout do not change this precedence. A link or mention alone does not execute a transfer mechanism. Effectiveness requires the complete attachment, party, module, version and evidence rules in the Data Transfer Addendum.

2.4 Distinct location, currency, and legal facts

The managed Service's intended primary application and database hosting location is Germany. A Customer's billing country, organization USD or EUR billing preference, actual Paddle transaction currency, and a website visitor's local USD or EUR display preference are different facts. None determines the law applicable to a person, creates a legal-region account, or proves that all processing stays in Germany or the EEA.

3. Documented Instructions and Required-by-Law Processing

3.1 Instructions

Customer instructs Tessora to process Customer Personal Data only as needed to:

• provide, secure, support, and maintain the Service under the Terms, this DPA, the applicable Order Details, and Schedules 1 through 3;
• apply Customer's dashboard settings, API calls, templates, workflows, channel choices, Recipient records, preferences, suppressions, and open- or click-tracking settings;
• transmit data to subprocessors in the frozen schedule accepted under Section 7 and to connected providers selected by Customer;
• act on deletion, export, correction, restriction, support, and other documented requests submitted by an Authorized User through an available Service or support channel; and
• follow additional written instructions agreed by authorized representatives of both parties.

An instruction does not authorize Tessora to sell Customer Personal Data, use Recipient data for advertising, combine it across customers for Customer-independent profiles, or use it for Tessora's product analytics.

Tessora will process Customer Personal Data only on documented instructions, including for transfers, unless law binding on Tessora requires other processing. Where legally permitted, Tessora will tell Customer about that requirement before processing. Tessora will promptly tell Customer if, in its opinion, an instruction infringes applicable data-protection law and may suspend only the affected processing while the parties address it.

3.2 Customer responsibilities

Customer is responsible for:

• the lawfulness, fairness, accuracy, quality, and transparency of its processing and instructions;
• establishing and documenting its own legal basis for each purpose and any Article 9 or equivalent condition where special-category or sensitive data is involved;
• providing required notices and honoring consent, objection, opt-out, suppression, and direct-marketing rules, including applicable ePrivacy, communications, and anti-spam law;
• deciding whether open tracking, click tracking, delivery-event processing, Recipient-event processing, and each connected provider are lawful and necessary for its use case;
• responding to data subjects and regulators as controller, or assisting its own controller where Customer is a processor;
• completing any required data protection impact assessment, prior consultation, records, or representative appointment; and
• ensuring its Authorized Users and connected providers have appropriate access and instructions.

The Service is not designed as a dedicated special-category-data service. Customer must not submit data subject to Article 9 or similarly sensitive data unless the processing is lawful, necessary, expressly documented, and supported by safeguards appropriate to the risk. Acceptance of this DPA alone is not that authorization.

4. Processor Duties

Tessora will:

• process Customer Personal Data only as permitted by Section 3;
• ensure that people authorized to process it are bound by confidentiality or an appropriate statutory duty and receive access only for authorized operational purposes;
• maintain records needed to demonstrate its processing obligations;
• apply Section 6 and Schedule 2 to protect Customer Personal Data;
• engage subprocessors only under Section 7;
• provide the assistance described in Sections 8 through 11, taking into account the nature of processing and information available to Tessora; and
• notify Customer if Tessora can no longer meet a material obligation under this DPA.

Tessora remains responsible for its personnel and for each subprocessor's performance of the obligations imposed under Section 7.

5. Privacy by Design, Minimization, and Customer Controls

Tessora will maintain Service controls intended to support data minimization, purpose limitation, confidentiality, integrity, availability, and resilience in proportion to the documented processing and risk. Customer controls the Recipients, message content, templates, attributes, preferences, suppressions, channels, connected providers, and whether available email open and click tracking is enabled.

Email tracking can create Recipient events containing timestamps, machine-detection results, user-agent information, click destinations, and counters. Delivery providers can return delivery, failure, bounce, complaint, delay, and provider identifiers. These remain Customer-controlled processor activities. Customer must disable tracking where it lacks a lawful, necessary instruction.

Recorded because it was once otherwise. Engagement tracking in the managed email provider was enabled at the provider account level, above any Customer setting, from the first production send until 13 August 2026. While it was on, the provider rewrote links and inserted an open-tracking pixel into managed messages regardless of whether the Customer had enabled tracking. It is now disabled account-wide, and no configuration set enables it. No Customer existed and the service was never publicly reachable during that period, so the only messages affected were our own test messages and no Recipient of any Customer was affected. It is recorded here so that the account-level control is understood to exist and so that re-enabling it would require a disclosure rather than a silent change.

Tessora does not use Customer Personal Data for website analytics. Worldwide website PostHog analytics is a separate, opt-in controller activity described in the Privacy Notice. Organization-keyed server-side product analytics is also a separate controller route and must not include Recipient content or identifiers.

6. Security and Technical and Organisational Measures

Taking into account the state of the art, implementation cost, processing nature, scope, context, and purposes, and risks to individuals, Tessora will maintain measures designed to provide security appropriate to the risk under Article 32. The binding baseline is Schedule 2, Technical and Organisational Measures, version 2026-08-15.1.

The public Security page is explanatory material only. It is not incorporated into this DPA and cannot silently add, remove, or change a contractual measure. Tessora may update Schedule 2 through a newly identified DPA version or written amendment and will not materially reduce the overall protection during the processing term without Customer's agreement unless necessary to address an urgent threat or legal requirement while preserving comparable protection.

Customer remains responsible for security within its control, including Authorized User access, API keys, connected-provider credentials, Recipient selection, message content, lawful tracking configuration, exports after download, and its systems receiving Service data.

The Service does not claim ISO, SOC, PCI, or other certification; an independent penetration test; or an independent audit of Tessora's controls. Vendor certifications do not certify Tessora. Encryption at rest and production key control, privileged-access review, vulnerability and patch coverage beyond the dependency gate, restore into production, deletion replay after restoration, recovery point and recovery time objectives, a production tenant-isolation exercise, connected-provider route verification, the off-site storage jurisdiction, and incident operation against a running service remain open launch dependencies identified in Schedule 2.

7. Subprocessors and Connected Providers

7.1 General authorization and frozen schedule

Customer gives general written authorization for the subprocessors in Schedule 3. For this DPA version, Schedule 3 incorporates only the Subprocessor List identified there as version 2026-08-18.1 and last updated 2026-08-18. The accepted version or immutable snapshot must be retained with the acceptance evidence. Later changes to the public page do not silently amend an accepted DPA.

Tessora will authorize a subprocessor to process Customer Personal Data only under a written contract imposing data-protection obligations no less protective, in substance, than the obligations relevant to that processing under this DPA, including appropriate security, confidentiality, assistance, deletion, and audit-evidence duties. Tessora remains responsible to Customer for the subprocessor's performance.

Tessora's internal vendor-verification programme must verify the legal entity, role, location, current terms, data-processing agreement, security material, and transfer route for every launch vendor. That verification is an open gate, and this DPA does not represent that every vendor agreement has already been executed or verified.

7.2 Changes and objections

Tessora will email organization Owners and Administrators at least 14 days before authorizing a new or replacement subprocessor to process Customer Personal Data. The notice will identify the provider, processing purpose, relevant location information then verified, proposed effective date, and an objection channel.

Customer may object during that period on reasonable data-protection grounds. The parties will try in good faith to use a reasonable alternative, restrict the affected feature, or otherwise resolve the objection. If they cannot, either party may end the affected Service under the Terms.

Where Customer ends the Service because an objection could not be resolved, Tessora will refund the prepaid fees for the unused remainder of the then-current billing period, calculated pro rata from the termination date. The refund is processed through the Merchant of Record under the Refund & Cancellation Policy. An objection right whose only exercise costs Customer the rest of a term it has already paid for is not much of a right, which is why this one carries a remedy. It is limited to this case: it does not create a refund for an ordinary cancellation, and it does not apply where the Service is ended for Customer's material breach.

7.3 Customer-selected connected providers

Email, SMS, Slack, Teams, Discord, webhook, or other providers connected or selected by Customer are Customer-authorized recipients or processors, not Tessora-selected subprocessors merely because the Service transmits Customer Personal Data to them. Customer is responsible for selecting them, entering required terms, configuring them, and determining the legal basis and transfer route. Tessora remains responsible for securely executing Customer's documented connection instruction within the Service.

8. Data-Subject Rights Assistance

Taking into account the nature of processing, Tessora will assist Customer through available Service controls and reasonable additional measures with requests for access, correction, erasure, restriction, portability, objection, and rights concerning automated decision-making.

If Tessora receives a request concerning Customer Personal Data directly from a data subject, Tessora will, where reasonably able to identify the Customer, forward it without undue delay and will not substantively respond unless Customer instructs it or law requires it. Tessora may ask Customer to verify the requester's identity and scope. Customer remains responsible for the response and deadline.

The current organization export contains identified account, membership, policy-acceptance, Recipient, preference, suppression, template, and up to the latest 5,000 notification records. It does not establish that every event, tracked link, attachment, workflow, webhook, provider configuration, credential, billing, audit/security, rollup, support, vendor, or older notification record is included. The export artifact expires seven days after the export completes, by a daily job, and only the Authorized User who requested it may download it. Both controls run in the image the production service serves, and both are the behaviour Section 11.2 and Schedule 2 describe. Tessora will perform reasonable additional searches or actions needed for a valid request where available tools are insufficient, following its internal data-subject-request runbook.

9. DPIAs and Prior Consultation

Tessora will provide information reasonably available to it about the Service's processing, subprocessors, locations, security measures, incidents, retention, and deletion to assist Customer with an Article 35 or equivalent assessment. Tessora will also provide reasonable assistance for an Article 36 prior consultation where Customer's completed assessment identifies unmitigated high risk and consultation is legally required.

Customer owns its assessment, legal basis, necessity and proportionality analysis, risk decisions, and consultation. The Service's support for message content, attributes, open and click tracking, delivery and Recipient events, and connected providers is high-risk-capable and is not a blanket approval for profiling, special-category data, monitoring, or decisions producing legal or similarly significant effects. The Service does not itself make such automated decisions about Recipients.

Tessora's current internal screening is a launch record, not legal advice or a regulator-approved DPIA. Material scope, tracking, sensitive-data, integration, or population changes require Customer and Tessora to reassess as appropriate.

10. Security Incidents and Personal Data Breaches

Tessora will notify Customer without undue delay, and in any event within 72 hours of confirming a Personal Data Breach affecting Customer Personal Data, and will provide information in phases as it becomes available. The clock runs from confirmation rather than from first suspicion, because an unassessed alert is not yet a breach; assessment itself is subject to the same without-undue-delay duty and is recorded. Notification will be sent through the operational security route to the Customer's organization Owners and Administrators unless another documented incident contact has been agreed. Public status-page updates and in-product notices are not the contractual breach-notification channel.

Available information will include, where known:

• the nature of the breach;
• affected data categories, data-subject categories, and approximate numbers of individuals and records;
• likely consequences;
• containment, mitigation, remediation, and evidence-preservation measures;
• a contact for follow-up; and
• information reasonably needed for Customer's assessment and notices.

Tessora will investigate, contain, preserve relevant evidence, mitigate, remediate, and reasonably cooperate with Customer. Customer is responsible for deciding whether and when to notify a regulator, its controller, or affected individuals unless law places that duty directly on Tessora. A notification is not an admission of fault or liability.

The incident classification, personal-data-breach assessment, breach-register fields, Customer-notice content, public-versus-private communication rules, and four internal tabletop exercises are recorded in the internal security evidence register. What the process still does not promise, and the distinction is deliberate: no acknowledgement clock, no public on-call guarantee, and no claim that centralized logs provide automated breach detection. A notification bound is a commitment Tessora controls once it knows; an acknowledgement clock would be a commitment about response time that no staffed rota exists to keep, and Tessora will not publish one it would miss. Production escalation, restricted case storage, Customer-audience resolution, private-notice delivery, evidence capture, and post-incident review remain implementation or production-evidence gates.

11. Return, Deletion, Retention, and Backups

11.1 During the Service

Customer may use available exports and controls during the processing term. Customer should export data it wishes to retain before requesting deletion. Tessora will provide reasonable additional return assistance under Section 8 where the current export is incomplete for a valid request.

11.2 End of processing

At the end of the provision of processing services, Tessora will, at Customer's choice, return Customer Personal Data and delete remaining copies, or delete it, unless binding law requires storage. If law requires storage, Tessora will isolate the retained data, limit processing to the legal requirement, tell Customer unless prohibited, and delete it when the requirement ends.

Cancellation or subscription expiry does not trigger the organization-deletion workflow on the day it occurs, and Customer should submit a documented return or organization-deletion instruction rather than relying on inaction. Two mechanisms nevertheless end the retention period without a Customer instruction, and Customer is on notice of both.

First, Tessora may raise a termination through its internal termination procedure, which offers an export, stops processing, and then schedules deletion subject to the same 30-day cancellation window described below.

Second, and automatically: where a subscription has been cancelled and the organization has then been dormant for 180 days measured from the end of that subscription's current period, not from the date of cancellation — no notification sent in that period, the organization itself older than 180 days, no deletion request already pending, and no legal hold in force — Tessora schedules organization deletion and starts the same 30-day cancellation window. Tessora emails the organization's Owners and Administrators the cancellation deadline when it does so. Tessora must not treat an inactive account as indefinite authorization to process Customer Personal Data, and this rule is how that principle is enforced rather than merely stated.

The current organization-deletion workflow allows a 30-day cancellation window and then a daily due-item purge removes the enumerated core workflow, Recipient, notification, event, tracked-link, preference, suppression, template, webhook, integration, credential, environment, membership, local subscription and invoice, and organization-linked policy-acceptance rows. Member user-login accounts are not automatically deleted; they are handled separately where Tessora is controller. The organization tombstone and completed request record remain, and relevant unified-audit actors are pseudonymized rather than deleted. Export artifact bytes are not deleted by the purge but do not survive it indefinitely: a daily job clears them 7 days after the export completed and records when it did. Attachment bytes, some organization-keyed tables, vendor copies and operational logs still need separate verification or action. Backups are a different case and are described in Section 11.3: the backup mechanism is evidenced, but a purge cannot reach into a dump that already exists, so a purged record persists in backup until that dump ages out. For all of these reasons Tessora will not describe the current purge as deletion of every copy.

11.3 Operational retention and backups

Notification retention is plan- and configuration-dependent. The current base values are 1 day for Free and Starter, 7 days for Growth, and 30 days for Pro and Scale. Trial status has no separate value; the organization's current plan supplies it. An organization override replaces the plan value. The extended-retention add-on raises a finite effective value to at least 90 days, while a null custom value remains without a finite notification-reaper period. Notification events, tracked links and attachment metadata follow notification deletion by cascade; stored attachment bytes are separately purged on terminal delivery or after a 72-hour hard TTL. The unified audit-log defaults are 365 days for security, configuration, and billing events, 180 days for lifecycle events, and 90 days for data-access events. Those audit periods do not govern separate authentication, administrator, preference or promotion audit tables, for which no age reaper was found. These values do not override a shorter lawful Customer instruction where the Service can implement it.

Backups are operating. A scheduled nightly job dumps the entire production database, compresses it, validates the artifact rather than the exit code, and uploads it off-site to Cloudflare R2; a failed run alerts an operator rather than passing silently. A restore has been rehearsed from the off-site copy into a scratch database, with the production image booted against it and every outbound credential blanked.

A dump is never edited, so deleting a record from the live database has no effect on a dump that already exists; the record leaves the backup set when that dump ages out. Each copy ages out after 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 script 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 for 14 days and then expires it; that expiry is performed asynchronously by the storage provider and its exact moment is not under Tessora's control. The production host consequently cannot delete or overwrite an off-site backup.

That immutability is a deliberate resilience control, and its consequence for erasure is stated rather than hidden. Fourteen days is a floor on how long a backup is kept, not a ceiling on how quickly a deletion reaches one. A deletion cannot be applied to an existing backup at all, early or otherwise, so the record persists until the last dump containing it ages out — approximately 15 to 16 days after the live deletion, and longer if a nightly run is missed or if the provider's expiry lags. Tessora does not publish a shorter figure and does not represent 14 days as an erasure deadline.

Two limits remain and this DPA does not imply past them. No restore has been performed into production as opposed to a scratch database, and no deletion has been replayed through a restore. Accordingly Tessora does not promise that data covered by a deletion instruction is absent from every backup before the ageing described above has run its course. Any restored copy must remain quarantined from ordinary processing, and all deletion, correction, restriction, objection and suppression instructions created after the backup must be re-applied and verified before return to ordinary service. A legal hold cannot preserve a backup beyond the lifecycle window; preserving backup content under a hold requires an authorized copy taken out of the bucket before it expires.

12. Information, Audits, and Government Requests

12.1 Compliance information and audits

Tessora will make available information reasonably necessary to demonstrate compliance with Article 28 and this DPA. The parties will ordinarily use, in sequence, the completed schedules and operational records, a reasonable questionnaire, a remote evidence review, and then an inspection where the earlier evidence is insufficient.

Customer or an independent auditor bound by confidentiality may conduct an audit, including an inspection, on reasonable advance notice, ordinarily no more than once in a 12-month period. The frequency and notice limits do not apply where a regulator requires an audit, a Personal Data Breach or credible material noncompliance justifies it, or urgent circumstances make ordinary notice impracticable. An audit must avoid exposing other customers' data, secrets, or security-sensitive information and minimize unreasonable disruption. Each party bears its own costs unless the audit identifies Tessora's material breach or the parties agree otherwise.

Tessora will contribute reasonably to a permitted audit and promptly inform Customer if, in Tessora's opinion, an audit instruction infringes applicable data-protection law. Tessora does not currently offer a Tessora SOC report, ISO certificate, independent penetration-test report, or independent audit opinion.

12.2 Government and third-party demands

Unless prohibited by law, Tessora will promptly notify Customer of a legally binding demand for Customer Personal Data. Tessora will review the demand for validity, request clarification where needed, seek to narrow disproportionate demands, challenge a demand where there are reasonable legal grounds, disclose only what it is legally required to disclose, and document the response. If advance notice is prohibited, Tessora will seek permission to notify Customer and provide delayed notice when legally permitted.

This clause is supplemented for covered transfers by the government-demand commitments, technical limits, supplementary measures, residual-risk decisions and re-review triggers in the Data Transfer Addendum and the internal transfer impact assessment. It does not convert an unverified vendor route or an inapplicable instrument into a valid safeguard.

13. International Transfers

This DPA supplies Article 28 processing terms. The separate Data Transfer Addendum, version 2026-08-18.1, completes EU SCC Modules Two and Three and UK Addendum B1.0 selections, party rules, Tables 1 through 4, Annexes I through III, supplementary safeguards, attachment, precedence, retrieval and organization-level acceptance evidence for covered Customer transfers. This DPA alone does not execute that package or declare a transfer route adequate.

Where a restricted transfer requires that package, the parties must attach it through the completed Organization Transfer Record or a signed instrument containing the same fields. The record must identify the Customer organization and full party details, role, applicable module, versions, official mandatory clauses, annexes, effective timestamp, and reconstructable accepted copy or hash. The hierarchy in Section 2.3 then applies.

The Commission SCCs are available where the importer's relevant processing is not itself subject to GDPR. Tessora imports Customer Personal Data as processor or subprocessor, and the Transfer Addendum sets out why that importer processing is not treated as caught by Article 3(2) and what happens if a Customer's own analysis differs. No qualified counsel has reviewed that position. Customer-selected connected providers require Customer's own provider terms and transfer analysis. Tessora-selected subprocessors require separately executed Tessora-vendor terms verified under Tessora's internal vendor-verification programme. Intended Germany hosting, billing country, and currency do not establish an executed safeguard.

14. Controller Instructions and Contact

Customer may submit ordinary instructions through authenticated Service controls and support requests. Formal DPA, rights-assistance, audit, government-request, or deletion instructions should be sent to support@saas-infrastructure.com by an organization Owner or Administrator. Incident reports should be sent to security@saas-infrastructure.com.

Tessora may require reasonable authentication and authority evidence before acting. Neither party is required to follow an instruction from an unverified requester.

Except where a completed transfer mechanism or mandatory law requires otherwise, the Terms' governing-law provision applies to this DPA: the State of Wyoming, United States.

Schedule 1 — Processing Details and Instructions

A. Subject matter, duration, nature, and purposes

B. Categories of data subjects

• Recipients, end users, subscribers, prospects, customers, employees, contractors, or other contacts selected by Customer;
• Customer personnel or other individuals identified in message content, templates, attributes, workflows, support material, or connected-provider configuration;
• Authorized Users to the limited extent their personal data appears in processor-side instructions or Customer content; and
• children, vulnerable individuals, or other protected populations only where Customer has a lawful, documented instruction and safeguards appropriate to that population. The Service is not represented as designed for those populations.

C. Categories of Customer Personal Data

Special-category data, criminal-offence data, government identifiers, payment-card data in message content, biometric data, and precise location data are not intended categories. Customer must not infer authorization to submit them from a free-text field or technical capability.

D. Locations and recipients

Primary application and database hosting is intended in Germany. Processing may involve Tessora's authorized personnel in the United States, vendors and their affiliates or support locations, worldwide Recipients, and connected providers selected by Customer. Schedule 3 identifies the frozen subprocessor schedule. The Data Transfer Addendum establishes the Customer-to-Tessora instrument package and route rules; Tessora's internal vendor-verification programme must verify and execute vendor routes and terms.

E. Retention and deletion

Section 11 governs. The current record-level defaults and incomplete backup facts stated there are part of this schedule. Customer instructions cannot require retention or processing that is unlawful, unavailable in the Service, or inconsistent with a binding legal hold; Tessora will identify such a conflict under Section 3.

F. Documented instruction channels

Instructions may be expressed through the accepted DPA and Terms, applicable signed Order Details, authenticated dashboard configuration, API requests under Customer credentials, Recipient preference actions exposed by Customer, and verified written requests from organization Owners or Administrators. Customer-selected tracking and connected providers are instructions only while enabled or invoked.

Schedule 2 — Technical and Organisational Measures

Schedule version: 2026-08-15.1

This schedule is the stable contractual baseline for this DPA version. “Source-evidenced” means the control is present in reviewed repository material; it does not claim production deployment proof, independent testing, or certification. “Deployment-evidenced” means the control was measured on the production deployment and the measurement is recorded; the managed service on that deployment is not publicly reachable and has never processed Customer Personal Data, so a deployment-evidenced measure is not a claim about behaviour under public traffic. Neither term claims independent testing or certification.

This version supersedes Schedule 2 version 2026-08-14.1. No measure changed and none was added or removed. The only edit is to the definition of “deployment-evidenced” above, which said "that deployment is not yet publicly reachable" and now says the managed service is not. That was a statement about the whole host and it stopped being true on 15 August 2026, when this website and the documentation site began to be served publicly from it while the application, its API, the preference centre, the tracking endpoints and the operator consoles stayed reachable only over a private network. The schedule moves because a fact stated inside it changed, not because a measure did.

Version 2026-08-14.1 was itself the one that recorded measures moving from intended to operating — production transport verification, backup scheduling, off-site backup immutability, restore rehearsal, a production log destination with configured retention, and operator alerting — together with the data-lifecycle controls described in Section 11, and added the optional authenticator-app multi-factor authentication and federated sign-in that the identity system already provides. All of that carries forward unchanged.

No measure and no disclosed limit in any previous version is withdrawn by this one. The first draft of version 2026-08-14.1 did drop three: the connected-provider transport clause and its open route-verification limit, and the separate-audit-tables and production-job-evidence entries in the data-lifecycle limit. All four are restored above and remain. That correction is recorded rather than made silently, because a disclosed limit removed while it is still open makes a schedule read stronger than it is, which is the direction that matters.

Tessora will assess these measures when processing or risk materially changes. Tessora's internal security evidence register maps every measure to its evidence and records the four tabletop results. The activation, data-lifecycle and security gates that remain open — encryption at rest and production key control, privileged-access review, scanning and patch coverage beyond the dependency gate, restore into production and deletion replay, no published or measured recovery point or recovery time objective, a production tenant-isolation exercise, connected-provider route verification, the off-site storage jurisdiction, incident operation against a running service, and independent assurance — remain open, and are published here as open rather than resolved. This list is the reader's index of what is open; a gate named in a row above and missing here is an error in this list, not a closed gate.

Schedule 3 — Authorized Subprocessor Schedule

For this DPA version, the authorized schedule is the Subprocessor List identified as:

• document slug: subprocessors;
• version: 2026-08-18.1;
• last updated: 2026-08-18; and
• vendors listed: Amazon Web Services (Amazon SES), Cloudflare (R2 and authoritative DNS), GitHub, Google (Sign in with Google), Hetzner, PostHog, Tailscale, and UptimeRobot.

Paddle is not in this schedule. It is an independent controller for payment processing under section 4 of the Subprocessor List, not a subprocessor authorized under this DPA.

The Subprocessor List names two entries this schedule does not authorize: Volentio JSD (jsDelivr) and Cloudflare's cdnjs, both removed from the product on 15 August 2026 and recorded there under removed dependencies. A vendor that receives nothing is not authorized to receive anything, so they are absent here while remaining on the list as inventory. This narrows the authorized schedule and widens nothing.

The schedule is incorporated as that frozen version, not as a dynamically changing webpage. The acceptance record must retain its version or an immutable snapshot. Section 7 governs changes. Customer-selected connected providers are not included merely because Customer routes messages to them.

The listed entity details, terms, processing locations, security materials, and transfer routes remain subject to Tessora's internal vendor-verification programme. In particular, an intended or configured region is not proof of an actual processing route. The Data Transfer Addendum's Annex III records the route and dependency for each frozen entry, but neither schedule claims execution of Tessora-vendor international-transfer terms.

VERSION MOVE 2026-08-15.7 -> 2026-08-16.1, CITATION-ONLY. No processing term, role, safeguard, schedule of measures or transfer position in this DPA changed. This document moved because the Subprocessor List moved 2026-08-15.7 -> 2026-08-16.1 to record that the UptimeRobot availability monitor is now live rather than planned, and the same THREE citations had to move with it: Section 7.1's in-body citation, Schedule 3's version: and last updated: lines, and Section 13's citation of the Transfer Addendum, which moved for the same reason. Schedule 2 did NOT move and remains 2026-08-15.1, so the Transfer Addendum's Annex II baseline citation is untouched. UptimeRobot was already named in Schedule 3's vendor list, so no vendor was added to this schedule.

VERSION MOVE 2026-08-16.1 -> 2026-08-16.2, CITATION-ONLY. No processing term, role, safeguard, schedule of measures or transfer position in this DPA changed. This document moved because the Subprocessor List moved 2026-08-16.1 -> 2026-08-16.2 to record that two further UptimeRobot monitors now exist, one of them paused, and that the read key is account-scoped rather than scoped to a single monitor. The same three citations moved with it. Schedule 2 did NOT move and remains 2026-08-15.1.

VERSION MOVE 2026-08-16.2 -> 2026-08-18.1, CITATION-ONLY. No processing term, role, safeguard, schedule of measures or transfer position in this DPA changed. This document moved because the Subprocessor List moved 2026-08-16.2 -> 2026-08-18.1 to record PostHog activation on both analytics routes after the vendor gates were verified by the accountable owner on 2026-08-18. Section 5's position is unchanged and remains true: Customer Personal Data is not used for website analytics, and both PostHog routes are separate controller activities. The same three citations moved with it. Schedule 2 did NOT move and remains 2026-08-15.1.