SavonAI — Data Processing Agreement (DPA)

Processor: Resolud Oy (business ID 3271825-2), Merikasarminkatu 6, 00160 Helsinki, Finland ("Resolud", "Processor")

Controller: the SavonAI customer that accepts this DPA ("Customer", "Controller")

Version: 1.2 · Effective date: 19 October 2026 · Language: This is a translation; the Finnish version (*Tietojenkäsittelysopimus*) prevails in case of conflict.

---

1. Purpose and scope

1.1 This DPA governs the processing of personal data by Resolud on behalf of the Customer in the course of providing the SavonAI service (the "Service"), and implements Article 28 of the GDPR (Regulation (EU) 2016/679).

1.2 The Customer is the controller and Resolud is the processor with respect to personal data contained in Customer Content (as defined in the Terms of Service) and any personal data Resolud processes on the Customer's documented instructions. For clarity, Resolud is an independent controller for the data described in its Privacy Policy (account, billing, prospect and analytics data); that processing is outside this DPA.

1.3 If there is a conflict between this DPA and the Terms of Service on the processing of personal data, this DPA prevails.

1.4 Reservations, the guest register, loyalty and gift cards. When the Customer uses the Service's reservation book («Varaukset»), guest register («Vieraat»), loyalty programme («Kanta-asiakkuus», once available) or gift cards («Lahjakortit»), the Customer is the controller and Resolud the processor of the personal data of the guests, members and buyers processed there. The guests are the Customer's own customers. Resolud does not use their data for its own purposes, and no guest's data of one Customer is combined with another Customer's data. The Customer is responsible for its own documents, and Resolud does not author them on its behalf:

• a privacy notice that covers bookings, the guest register, no-show history and the right to object, and, once switched on, allergy data and loyalty;
• a legitimate-interest assessment (LIA) before the guest register is switched on;
• its own data-protection impact assessment (DPIA);
• its booking and loyalty terms.

Resolud's own demonstration project is outside this DPA; there, Resolud is the controller.

1.5 Before real guest data. A venue takes real guest data only once (a) version 1.2 or later of this DPA has been accepted under Section 8, (b) Resolud has recorded that the Customer's privacy notice covers the matters listed in Section 1.4 (the notice's address is stored), and (c) Resolud has recorded that the Customer's own DPIA has been carried out (its date and reference are stored). Until then a venue may be in a test state, in which the Customer enters test data only (Annex 1).

1.6 Settings as instructions. The settings the Customer chooses in the Service are documented instructions under Section 3.1. Examples are retention periods, switching on the guest register and the marketing question, and asking for allergy data. Asking for allergy data is switched on only by the Customer's owner or «Pääkäyttäjä» (manager), never by Resolud's personnel. When Resolud's personnel change a retention period or switch on a new purpose of processing at the Customer's request, who asked, how and on which day is recorded.

2. Details of processing (Annex 1)

The subject-matter, duration, nature and purpose of the processing, the types of personal data, and the categories of data subjects are set out in Annex 1.

3. Processor obligations

Resolud will:

3.1 Instructions. Process personal data only on the Customer's documented instructions (including with regard to international transfers), as set out in this DPA, the Agreement, and the Customer's use and configuration of the Service, unless required to process by EU or member-state law, in which case Resolud will inform the Customer first (unless the law prohibits it on important grounds of public interest). Resolud will inform the Customer if, in its opinion, an instruction infringes data-protection law.

3.2 Confidentiality. Ensure that persons authorised to process the personal data are bound by confidentiality obligations and process only as instructed.

3.3 Security. Implement appropriate technical and organisational measures under Article 32 GDPR, as described in Annex 3, taking into account the state of the art, costs, and the nature, scope, context and purposes of processing and the risks to individuals.

3.4 Sub-processing. Engage sub-processors only in accordance with Section 4.

3.5 Data-subject requests. Taking into account the nature of the processing, assist the Customer by appropriate technical and organisational measures, insofar as possible, to fulfil the Customer's obligation to respond to data-subject requests (access, rectification, erasure, restriction, portability, objection). If a data subject contacts Resolud directly about Customer Content, Resolud will refer them to the Customer and, where appropriate, inform the Customer.

3.6 Assistance. Assist the Customer, taking into account the nature of processing and the information available to Resolud, in ensuring compliance with Articles 32–36 GDPR (security, breach notification, data-protection impact assessments and prior consultation).

3.7 Personal-data breach. Notify the Customer without undue delay after becoming aware of a personal-data breach affecting Customer personal data, and provide information reasonably available to enable the Customer to meet its notification obligations (Arts. 33–34).

3.8 Deletion or return. At the Customer's choice, delete or return all Customer personal data after the end of the provision of the Service, and delete existing copies, unless EU or member-state law requires storage. The Service's export features (site and Brain) support return/portability; Resolud uses cryptographic erasure where applicable. Backups are purged on the ordinary backup cycle. The length of that cycle (the backup tail) and the steps after a restore are described in Annex 1.

3.9 Records and demonstrating compliance. Make available to the Customer information necessary to demonstrate compliance with Article 28, and allow for and contribute to audits, including inspections, conducted by the Customer or an auditor it mandates (Section 6).

4. Sub-processors

4.1 The Customer gives general written authorisation for Resolud to engage sub-processors to provide the Service. The current sub-processors are listed in Annex 2 (and maintained at https://savon-ai.com/legal/sub-processors).

4.2 Resolud will impose data-protection obligations on each sub-processor that are no less protective than those in this DPA, and remains fully liable to the Customer for the performance of each sub-processor's obligations.

4.3 Resolud will notify the Customer of any intended addition or replacement of a sub-processor at least 30 days in advance (by email and/or in-app), giving the Customer the opportunity to object on reasonable data-protection grounds. If the parties cannot resolve a reasonable objection, the Customer may terminate the affected part of the Service; see Section 8.

5. International transfers

5.1 Resolud will not transfer Customer personal data outside the EEA except in accordance with Chapter V GDPR. Where a sub-processor processes data outside the EEA, transfers are safeguarded by an adequacy decision (including the EU-US Data Privacy Framework where the recipient is certified) and/or Standard Contractual Clauses with supplementary measures. Annex 2 notes each sub-processor's location and safeguard.

5.2 To the extent required, the parties will enter into the applicable SCC modules; this DPA's Annexes provide the information needed to complete them.

6. Audit

Resolud will make available the information necessary to demonstrate compliance and, on reasonable prior notice (at least 30 days), no more than once per 12 months (unless required by a supervisory authority or following a breach), allow the Customer or its mandated auditor to audit the processing, subject to confidentiality and to not compromising other customers' security. Resolud may satisfy audit requests by providing up-to-date certifications, reports, or completed security questionnaires where these reasonably address the request.

7. Liability

Liability under this DPA is subject to the limitations and exclusions in the Terms of Service, to the extent permitted by law. Nothing limits either party's liability to data subjects or supervisory authorities under the GDPR.

8. Term and termination

This DPA takes effect when accepted and remains in force for as long as Resolud processes Customer personal data under the Agreement. Termination of the Agreement terminates this DPA, subject to Section 3.8. This DPA survives to the extent Resolud still holds Customer personal data.

Acceptance and its record. This DPA is accepted on the Customer's behalf by the holder of the Customer's owner account in the Service, or by a «Pääkäyttäjä» (manager) the Customer has named who has accepted their own invitation. The accepter types their name, their position and the Customer's business ID, and confirms that they accept the agreement on the Customer's behalf. The Service records the acceptance unalterably. The record holds:

• the accepter's name, position, e-mail address and role (and, for a «Pääkäyttäjä», who granted the role);
• the Customer's business ID;
• the time and the version accepted;
• the SHA-256 hash of the accepted Finnish document.

A receipt is sent to the accepter's own e-mail address. Resolud's personnel cannot accept this DPA on the Customer's behalf. Acceptance cannot be given from an account that belongs to Resolud's personnel or is an alias of such an account's address, nor from an address on Resolud's mail domain.

---

Annex 1 — Details of processing

Subject-matter: provision of the SavonAI service (website analysis, rebuild and hosting; AI CMS; the Brain knowledge base and customer-facing AI agent; reports; the reservation book «Varaukset», the guest register «Vieraat», loyalty «Kanta-asiakkuus» and gift cards «Lahjakortit»; related support).

Duration: for the term of the Agreement, plus any period until deletion/return under Section 3.8.

Nature and purpose: collection, storage, organisation, structuring, analysis, generation, adaptation, retrieval, transmission, hosting, display and erasure of personal data, by automated means (including generative-AI processing), for the purpose of building, hosting and maintaining the Customer's web presence and knowledge base, and producing content, agent responses and reports for the Customer. Photos the Customer uploads are in addition subject to automatic face detection in photos (no recognition): the Service detects whether faces appear in a photo so that it can ask the Customer for the permission of the people who appear in it. Faces are not recognised, and no face templates or other biometric identifiers are created from them. In the reservation book and its related functions, processing also covers:

• taking table bookings from the Customer's booking page, by phone, at the door and from the Customer's website form;
• confirming, changing and cancelling bookings by the Customer's staff or by a rule the Customer set;
• booking e-mails to the guest;
• recording arrivals and no-shows;
• keeping the guest register;
• loyalty stamps and member mails the Customer has approved (when switched on);
• recording gift-card orders, cards and redemptions;
• producing person-free counts for the Customer's Brain.

No payment is involved in a booking.

Types of personal data (as determined by the Customer's content and configuration), which may include:

• contact and identity data present on the Customer's website or provided to the Brain (names, business and personal contact details, roles);
• content of documents, notes, voice memos and forwarded emails the Customer ingests into the Brain;
• data from a connected Google Search Console account (if the Customer connects it);
• photos the Customer uploads to the Service (people may appear in them);
• data of the Customer's guests, loyalty members and gift-card buyers, if the Customer uses «Varaukset», «Vieraat», «Kanta-asiakkuus» or «Lahjakortit» (itemised in the table below);
• any other personal data the Customer chooses to include in Customer Content.

The Customer must not submit special categories of personal data (Art. 9) or criminal-offence data (Art. 10) except where the Service is explicitly configured and agreed for it; the Customer is responsible for redacting third-party personal data it does not need. The Service flags and can redact certain third-party PII on ingest, and excludes content marked pii from external exposure unless the Customer consents. The only processing configured for Art. 9 data and agreed by this DPA is the reservation book's allergy data (table below). The Customer's owner or «Pääkäyttäjä» switches it on explicitly for a venue. No health data is to be entered anywhere else in the reservation book; this covers the booker's own note, staff notes and the guest register, and those fields carry a hint saying so. If a booker writes health data into their own note, it is destroyed with that note 7 days after the service day.

Categories of data subjects: the Customer's own personnel and representatives; the Customer's customers, prospects and correspondents; individuals mentioned in ingested materials or appearing on the Customer's website; website visitors and agent users; individuals who appear in photos the Customer uploads; the Customer's guests: people who make table bookings and the members of their party (allergy data concerns the whole party), guests in the guest register and people who give a marketing consent; members of a loyalty programme; gift-card buyers and the recipients named on cards.

Reservations, the guest register, loyalty and gift cards — data and retention. Periods run from the venue's service day unless stated otherwise. They are defaults the Service offers, and the Customer's privacy notice must state the periods in force for the venue. A change of a retention period or of the privacy notice's address clears the record of Section 1.5 (b) until it is made again.

Category	Data	Retention
Bookings	The booker's name, e-mail and phone number, with their hashes and the booking's linking identifiers; party size, time, table, status and channel. In addition: the booker's own note, the staff note, and the free text of a request that came from the Customer's website form.	The name, contact details, hashes and identifiers are removed, and the booking is detached from the guest register, 90 days after the service day (default; the Customer may set 30–730 days per venue). The staff note is removed after 30 days. The booker's own note and the form's free text are sealed under a per-service-day key and destroyed after 7 days. The form submission's own copy is emptied when the booking is filed and removed within the same period. A person-free remainder row (day, period, party size, channel, status, table) is deleted after 3 years. The mailer's copy of a sent booking e-mail is removed from the send queue no later than the end of the person-data period.
Allergy data (health data, Art. 9) — only if the Customer has switched it on for the venue	Party-level choices from the 14 EU allergens and «muu» (other; at most 60 characters, no names). In addition: the booker's explicit consent, whose text names the purpose (preparing the food and handling complaints), and the SHA-256 hash of that text. Asked only at a venue in use, never in the test state, and only once the record of Section 1.5 (b) covers allergy data.	Sealed under a per-service-day key. The data is destroyed with its key 7 days after the service day, and the guest can remove it at any time. It never reaches an export, an e-mail, a log, the Brain or the floor device. It is shown only in the booking's details to the Customer's owner and «Pääkäyttäjä» and on the kitchen sheet.
Guest register «Vieraat» — only if the Customer has switched it on for the venue after its LIA	The guest's name, e-mail, phone number, language, tags (regular, VIP, business), staff note and the bookings attached to the card. In addition: visit and no-show counts derived from the bookings, which never decide a booking.	A card is deleted after 90 days without activity (the default equals the bookings' period; the Customer may set 30–730 days; for a card spanning venues the shortest applies). The card's note is removed 30 days after it was written. When a guest objects, the card is deleted at once and their bookings are no longer attached to the register.
Marketing consents (e-mail)	The venue, the address hash, the consent text as shown and its hash, the time and the source; withdrawals. In addition: a suppression list holding only the address hash. The consent is asked with an unticked box, and the text names the venue.	A consent record is kept while the consent is in force and for 3 years after. A suppression entry is kept so that a withdrawal or an objection stays effective, also after erasure. The Service sends no marketing on the basis of bookings; member mails are sent only within loyalty.
Record of rights requests	Hashes and identifiers of erasure, objection and withdrawal requests (no addresses).	217 days (the backup tail + 1 month), so that requests can be re-applied after a backup is restored.
Loyalty «Kanta-asiakkuus» — later, once the Customer switches it on	The member's first name, e-mail and language; the loyalty terms accepted; stamps and rewards; joining and leaving times; the marketing choice per venue; send records of member mails, with no address and no text. In addition: an age confirmation, which is 18 years in a programme limited to adults and otherwise at least 13 years for a marketing consent.	Kept while the membership lasts. A membership ends when the member or the Customer ends it, or when no stamp has been earned within the period the Customer sets (default 365 days, 90–730). On leaving, the name, address, register link and visit history are removed at once, and a person-free remainder is deleted after 3 years. An unconfirmed join request is deleted after 24 hours, and stamp events after 400 days.
Gift cards «Lahjakortit»	The buyer's e-mail, a hash of the IP address, the recipient's name and the greeting text; the Customer's user who recorded a redemption. Payment takes place on the payment provider's page under the Customer's own payment-provider agreement, and Resolud receives no card or bank details.	An unpaid order is deleted 7 days after it was opened (30 days while the payment provider's answer is pending). A paid order's buyer data is removed 24 months after the card's last valid day, or earlier at the Customer's request. Amounts, codes and events are the Customer's bookkeeping records and are deleted 7 years after the card's last valid day.
Test-state bookings	Test data only: an e-mail address only of a project member or on a test domain, and no phone number. The Customer does not enter real guests' data in the test state.	Erased when the venue leaves the test state, and in any case 14 days after the booking was made.

The backup tail. The periods above apply to the Service's live database. An encrypted backup of the Service is taken every night. Backups are kept as 7 daily, 4 weekly and 6 monthly archives, so data may remain in a backup for at most 6 months after its period above has ended or it was erased. Day keys are never backed up. For that reason, data sealed under a per-service-day key (allergy data, the booker's own note, a form's free text) cannot be read from a backup once its day key has been deleted. If a backup is restored, Resolud does two things before the reservation book takes new bookings: it runs every removal above on the restored data, and it re-applies the erasure, objection and withdrawal requests recorded since the backup. If a server is lost entirely, requests carried out after the last nightly backup (at most about one day's) are not part of the restore and must be carried out again.

Annex 2 — Approved sub-processors

The current sub-processor list is maintained in the Sub-processor List document (and at https://savon-ai.com/legal/sub-processors). As at the effective date:

Sub-processor	Service provided	Processing location	Transfer safeguard (if outside EEA)
Anthropic, PBC	Generative-AI (LLM) inference for analysis, content generation and the customer agent	USA	SCCs / EU-US DPF (if certified); contractual no-training commitment
Stripe (Stripe Payments Europe, Ltd.; Stripe, Inc.)	Payment processing, subscriptions, EU VAT	Ireland (EU); USA	SCCs; PCI-DSS
Cloudflare, Inc.	CDN, DNS, TLS, DDoS, custom hostnames, R2 object storage (EU jurisdiction), access/tunnel	USA (EU-localised) / EU	SCCs; EU data-localisation
Hetzner Online GmbH	Virtual-server hosting of the application and data	Helsinki, Finland (EU)	N/A (within EEA)
Scaleway SAS	Transactional email delivery	France (EU)	N/A (within EEA)
Google (Google Ireland Ltd)	Google Search Console integration via OAuth — only if the Customer connects it	Ireland (EU) / USA	SCCs / DPF

Public registers PRH/YTJ (Finnish Business Information System) and VIES (EU VAT validation) are consulted to verify company data; they are data sources, not sub-processors.

Annex 3 — Technical and organisational security measures (Art. 32)

Resolud maintains, and keeps under review, measures including:

• Hosting in the EU/EEA (Finland/EU); no customer server-side code executes on the platform. Hosted sites are served as pre-built files; where the Customer enables a form, the platform receives the submission at the edge and stores it in the same EU region until it is collected for delivery to the Customer.
• Encryption in transit (TLS) for all traffic.
• Encryption at rest: per-tenant envelope encryption (unique data key per tenant, wrapped by a master key held outside the data store) for Brain/knowledge-base data; cryptographic erasure ("crypto-shred") as a deletion primitive.
• Photos: photos the Customer uploads are stored on the Service's server in the EU unencrypted — the envelope encryption above covers Brain/knowledge-base data, not photos. They are protected by access control and tenant isolation. Location and other metadata (EXIF/GPS) are removed from photos stored in the photo library («Kuvat»), and staff access to the library's photos is restricted and logged.
• Per-project sealing of the reservation book: each of the Customer's projects has its own reservation-book file and its own data key. The key is wrapped by a master key held outside the data store. Guests' names, contact details and notes, and the personal data of the guest register and of loyalty, are stored encrypted under that key. Only one part of the Service writes to the reservation book, and no reservation book is carried into a copy of a project.
• Per-service-day keys: the booker's own note, allergy data and a form's free text are sealed under that service day's own key. The key is deleted 7 days after the service day, which makes the data unreadable (cryptographic erasure); the data is also deleted from the database. Day keys are excluded from the Service's backups, so restored data does not become readable again: after a restore an allergy entry shows as «allergiatieto ei luettavissa — kysy vieraalta» ("allergy data not readable — ask the guest"). The promise holds where no provider-level disk image or snapshot of the server keeps the day keys for longer than 7 days. Asking for allergy data can be switched on only on a server for which this has been established.
• Per-project address hash: the reservation book finds and matches e-mail addresses and phone numbers by an HMAC-SHA-256 hash. The hash key is derived from the project's own data key. The same guest therefore has different hashes in different Customers' books, so a guest cannot be linked across projects. Once the project's key is deleted, the hashes can no longer be recomputed.
• Reservation-book roles: every Customer user with access to the reservation book sees the name, party size, time, table and status. Contact details, notes, allergy data, the guest register, export and erasure are available only to the Customer's owner, its «Pääkäyttäjä» and Resolud's expert personnel (whose reads are ledgered, see the next item). The floor device (when in use) shows today only: the first name and the surname's initial, party size, time, table and status. A venue may have at most two devices, and each can be revoked.
• Ledger of staff reads: reads by Resolud's personnel are written to an append-only ledger in the reservation book. Ledgered reads are a guest's contact details, a booking's private details, searches, the guest register, exports, erasures and kitchen-sheet prints. Each entry holds who, in which role, when, what and how many rows. For exports, erasures and retention changes, the Customer's instruction is ledgered too: who asked, how and when. The Customer sees the ledger under «Tietojen käyttö». An erasure never removes it, and rows are kept for 3 years.
• AI boundary: the Brain and the customer-facing AI agent receive from the reservation book only person-free counts under closed keys (for example booked covers per period). Counts below three are folded together, and a folded count still below three is suppressed; test bookings are never counted. The Brain never sees a guest's name, contact details, notes or allergy data, nor a loyalty member's address, and no personal data of the reservation book is sent to an AI model. No AI creates, changes or cancels a booking, or writes to a guest. Loyalty member mails (when switched on) work as follows: the AI writes the message person-free, the Customer approves it word for word, and the Service picks the recipients only at the moment of sending. The Brain gets counts back, and every mail carries a one-click unsubscribe that needs no login. The reservation book's program modules are separated from the AI modules, and the separation is enforced by tests.
• Access control: role-based access control; least-privilege staff access; passwords stored only as salted hashes (argon2/bcrypt); signed-session authentication.
• Tenant isolation: structural (not merely path-based) tenant scoping enforced by a central guard that rejects and logs cross-tenant access; origin isolation for served sites (cookieless, app-isolated origin).
• Segregation of planes: separation of the serve, control, data and build environments; the AI build worker runs with restricted egress and no data-volume mounts.
• Backups: regular, tested backups with restore verification. Backups are encrypted, and their retention and the steps after a restore are described in Annex 1. A backup holds the reservation book together with its key, so data sealed under the project key can be restored for as long as the backup is kept. A backup holds no day keys.
• Logging & monitoring: application and access logging; an append-only AI-usage ledger; alerting on tenant-isolation violations.
• Confidentiality: staff bound by confidentiality; secrets kept out of the code base and in restricted configuration.
• Breach management: procedures to detect, assess, and notify personal-data breaches without undue delay.

These measures may evolve; Resolud will not materially reduce the overall level of protection during the term.

---

Contact for data-protection matters: Resolud Oy · [email protected] · Merikasarminkatu 6, 00160 Helsinki, Finland