Data Processing Agreement (DPA) — Typelessity

Between Data Controller and Data Processor

Effective Date: the date the Controller accepts this agreement in the Webappski Client Portal Document version: 2026-09-25 Last Updated: September 25, 2026

This agreement covers Typelessity, the AI booking and request assistant. It is a separate agreement from the TypelessForm DPA; if you use both products, each is governed by its own document.

PARTIES

DATA CONTROLLER ("Client", "you"):

• The business that embeds the Typelessity widget on its website and decides what the widget asks for and where the results go.
• The Client declares its legal name, registered address and data-protection contact when it accepts this agreement in the Webappski Client Portal. Those three declarations, the version of this text that was on screen, a fingerprint of that text and the moment of acceptance are recorded together as one record, and are reproduced at the top of the Client's own copy of this document. They form part of this agreement.

DATA PROCESSOR ("Processor", "we"):

• Victoria Isayeuskaya, sole proprietorship (jednoosobowa działalność gospodarcza)
• Address: ul. Staniszewskiego 19b, 81-603 Gdynia, Poland
• VAT ID (EU): PL5862405795
• Email: info@webappski.com
• Website: https://webappski.com

1. PURPOSE AND SCOPE

1.1 Subject Matter

This Data Processing Agreement ("DPA") governs the processing of personal data by the Processor on behalf of the Controller in connection with Typelessity ("the Service").

Typelessity is a conversational assistant embedded on the Controller's website. A visitor holds a conversation with it — by typing or by speaking — and the assistant collects the information the Controller has configured it to collect. At the end of the conversation the collected information takes one of two paths, both configured by the Controller:

• Booking path: the information is submitted to an integration endpoint operated by the Controller (for example, the Controller's own booking system), and whatever that system answers is recorded as the outcome.
• Request path: where no integration endpoint is configured, the information is forwarded by email to an address the Controller nominates. Nothing is confirmed by any booking system; the result is a request for the Controller to act on.

The Service therefore processes personal data of the Controller's website visitors, for the Controller's purposes, on the Controller's instructions.

1.2 Duration

This DPA becomes effective when the Controller accepts it, and in any event no later than the first publication of a widget configuration, which is the point at which the Service begins to process personal data for the Controller. It remains in effect for as long as the Processor processes personal data for the Controller.

1.3 Hierarchy

This DPA is the parties' complete agreement on data protection for the Service and stands on its own. Where the parties also enter into service terms or an order form, this DPA prevails over them on data-protection matters.

1.4 Version of this document, and how acceptance is recorded

This text carries a document version at the top of the page. The acceptance record described in PARTIES stores that same version string together with a fingerprint of the text that was on screen. There is one version identifier for this agreement, and the Service stores that one — not a second, separate numbering of its own.

2. DEFINITIONS

Personal Data: any information relating to an identified or identifiable natural person ("Data Subject"), GDPR Art. 4(1).

Processing: any operation performed on personal data, GDPR Art. 4(2).

Sub-processor: a third party engaged by the Processor to process personal data on behalf of the Controller, GDPR Art. 28(4).

Data Breach: a breach of security leading to accidental or unlawful destruction, loss, alteration, unauthorised disclosure of, or access to personal data, GDPR Art. 4(12).

GDPR: Regulation (EU) 2016/679.

Conversation: the exchange of messages between a website visitor and the Typelessity assistant in a single session.

Preview session: a conversation started from the Controller's own Portal, by the Controller's own staff, to see how a configuration behaves before it is published. It is not a conversation with a website visitor.

3. CONTROLLER AND PROCESSOR ROLES

3.1 Controller Responsibilities

The Controller:

• decides what the assistant asks for — the field set, its labels and any enrichment lookups are the Controller's configuration;
• decides where the result goes — its own integration endpoint, or an email address it nominates;
• establishes a lawful basis (GDPR Art. 6) for that processing and, where applicable, an Art. 9 condition;
• provides its own privacy information to visitors (GDPR Art. 13);
• handles data-subject requests it receives and instructs the Processor where the Processor's side of the data is affected.

3.2 Processor Responsibilities

The Processor:

• processes personal data only on the Controller's documented instructions (GDPR Art. 28(3)(a)), the configuration itself being the principal instruction;
• operates the conversational assistant, the session store, the email forwarding of requests and the submission of bookings to the Controller's endpoint;
• implements the technical and organisational measures in Section 5.3 and Appendix A;
• engages sub-processors only as set out in Section 5.4 and Appendix B.

3.3 Prohibited Actions

The Processor does not:

• sell personal data, or share it with any party other than the sub-processors listed in Appendix B and the recipients the Controller itself configures;
• use conversation content or collected data to train its own or any third party's AI models;
• process the data for its own purposes beyond operating, securing and supporting the Service.

3.4 Independent Controller for Service Security and Operational Records

For a narrow set of records the Processor acts as an independent controller on its own legitimate-interest basis (GDPR Art. 6(1)(f)): request rate-limit counters, API-usage counters per organisation, and application error logs (written through the sanitiser described in Section 5.3). These exist to keep the Service available, to detect abuse and to control cost. They are not processed on the Controller's behalf and are not part of the Controller's instructions.

3.5 Independent Controller for Portal Account Data

The Controller's own account in the Webappski Client Portal — the person who signs in, their email address, their organisation record and the acceptance record of this agreement — is processed by the Processor as an independent controller, under the website privacy notice, not under this DPA.

4. DESCRIPTION OF PROCESSING

4.1 Nature and Purpose of Processing

Processing consists of:

1. Serving the assistant. The widget script is loaded onto the Controller's page and resolves the Controller's configuration.
2. Consent at the boundary. Before a conversation starts on a Controller's live embed, the visitor's consent record is checked on the server; a conversation cannot be created without one. The check is repeated on every message, so that a withdrawal takes effect in the middle of a conversation and not only at its end. Two supporting calls made inside a conversation that has already passed the gate — speech-to-text and, where enabled, address lookup — authorise on the session rather than re-reading the consent record; a visitor who withdraws stops the conversation itself, which is what stops those calls.
3. Preview sessions. A preview started by the Controller's own staff from the Portal does not pass through the consent gate, and is stored in the same way as any other session. It is stated here rather than omitted, because the earlier wording of this document described previews as carrying no data at all, which was not accurate. A preview contains whatever the Controller's staff typed into it, and the Controller should not use live customer data to test a configuration.
4. Holding the conversation. Messages are sent to a large-language-model provider (Appendix B) with the Controller's configuration as context, so the assistant can ask for what is missing and understand the answers. Where the visitor speaks instead of typing, the audio is transcribed by the same provider.
5. Extracting the collected values. The assistant records the values it has understood, and — where the Controller has configured enrichments (for example, address lookup) — the corresponding lookup results.
6. Delivering the outcome. The completed data is either submitted to the Controller's integration endpoint, or forwarded by email to the address the Controller nominated. The result of that delivery (accepted, emailed, failed) is recorded.
7. Making the results available to the Controller in the Client Portal, and erasing them there on the Controller's instruction (Section 5.5).

No automated decision producing legal or similarly significant effects on the visitor is made by the Service (GDPR Art. 22): the assistant collects and transmits, it does not decide.

4.2 Categories of Data Subjects

• Visitors to the Controller's website who interact with the assistant.
• Any third person whose details a visitor enters (for example, a booking made on someone else's behalf).
• The Controller's own staff, where they run preview sessions.

4.3 Types of Personal Data Processed

a) Whatever the Controller configured the assistant to collect. The field set belongs to the Controller; typical configurations include name, email address, telephone number, dates and times, addresses or pick-up and drop-off points, party size, and free-text notes. The Processor stores these as the conversation's extracted values and, where delivery is by email, in the record of the forwarded request.

b) The conversation itself. Every message in the session — what the visitor wrote, or what their speech was transcribed into, together with the assistant's replies — is stored as part of the session. Free-text conversation can contain more than the configured fields; see Section 4.4.

c) Enrichment results. Where the Controller enables a lookup (for example address autocomplete), the query text and the result are processed and stored with the session.

d) Delivery records. For each completed conversation: the outcome status (submitted to the Controller's system, emailed as a request, failed, cancelled), the data submitted, the response the Controller's system returned, timing, and any error message. For emailed requests, the recipient address the Controller nominated at that time and the delivery status of the message.

e) Technical data, and where it actually sits.

• With the consent record: IP address, user-agent string, the domain the widget was loaded on, the interface language, the consent method, the policy version and the widget version.
• With the session itself: none of the above. The session carries no IP address, no user-agent and no referring page.
• In the hosting provider's request logs: IP addresses appear transiently at request level, as they do for any web request (Appendix B, hosting).
• In the visitor's own browser: the widget keeps the consent record — including a randomly generated visitor identifier and the consent history — in localStorage, and the session identifier, session token and interface state in sessionStorage. These are set for the functioning of the assistant the visitor asked for; the widget sets no advertising or cross-site tracking storage.

f) Voice audio. Where the visitor speaks, the audio is sent to the transcription provider and is not retained by the Processor once the transcript is produced. What the provider does with it is in Appendix B.

4.4 Special Categories of Personal Data (GDPR Art. 9)

The Service is not designed for special-category data. The Controller must not configure fields that ask for health, biometric, racial or ethnic, political, religious, trade-union, sex-life or sexual-orientation data, and must not use the Service where the answers it invites would routinely reveal such data.

This is a prohibition on what the Controller may configure, not merely a preference, and the reason is concrete: conversation text is sent to a language-model provider outside the EEA (Appendix B), where it is retained for up to 30 days in that provider's abuse-monitoring logs. The Processor holds no arrangement that shortens or removes that retention. A configuration that routinely invites Art. 9 data would therefore export it, and the safeguards this document describes are not built for that.

What the Service enforces, and what it does not. A configuration that declares itself to be of the medical business type is refused by the Service outright, on every path by which a configuration can be submitted. That enforcement reads the declared type, not the content of the fields: a configuration declared as, for example, beauty or fitness can still contain a free-text field that asks about medication or allergies, and the Service will not stop it. The prohibition in the paragraph above is therefore a contractual obligation of the Controller and is only partly backed by a technical control. The Processor states this rather than implying a guarantee it does not provide.

Because the conversation is free text, a visitor may nevertheless volunteer such information unprompted. The Processor treats that content with the same measures as all other conversation content and does not single it out. The Controller remains responsible for establishing a condition under Art. 9(2) if such data is knowingly processed, and for assessing whether a data protection impact assessment is required (Art. 35).

5. PROCESSOR OBLIGATIONS

5.1 Processing Instructions (Art. 28(3)(a))

The Processor processes personal data only on the Controller's documented instructions, including with regard to transfers of personal data to a third country or an international organisation. Those instructions consist of: this DPA, the widget configuration the Controller publishes, and any further written instruction the Controller gives. Where the Processor is required by EU or Member State law to process beyond those instructions, it informs the Controller before doing so unless the law prohibits it.

The Processor informs the Controller if, in its opinion, an instruction infringes the GDPR.

5.2 Confidentiality (Art. 28(3)(b))

Every person authorised to process personal data under this DPA is bound by a duty of confidentiality. Access is limited to what the person's role requires. The Processor is a sole proprietorship: the set of authorised persons is the proprietor and, where engaged, named contractors under written confidentiality obligations. The Processor keeps that set as small as the work allows and states its size honestly rather than describing an organisation it does not have.

5.3 Security Measures (Art. 28(3)(c); Art. 32)

The measures in force are set out in full in Appendix A, which is written against Art. 32(1)(a)–(d) and states, for each measure, what is in place today rather than what is planned. In summary:

• transport encryption on every connection the Service makes and receives, including delivery to the Controller's own integration endpoint, which must be an https:// URL;
• encryption at rest for the database, and separate application-level encryption (AES-256-GCM) for integration secrets;
• per-organisation isolation and authentication, hashed API keys, rate limiting;
• error logging through a sanitiser that strips secrets and personal data;
• a consent check enforced on the server at session creation and on every message;
• availability, backup, restoration and testing arrangements stated as they actually are, with their present limits named rather than implied (Appendix A, sections (b) and (c)) — including the fact that the Service does not today run on plans that provide automatic database backups.

5.4 Sub-processors (Art. 28(2), 28(4))

The Controller gives general written authorisation for the sub-processors listed in Appendix B. The Processor imposes data-protection obligations on each sub-processor equivalent to those in this DPA and remains fully liable to the Controller for their performance.

The Processor will give the Controller at least 30 days' notice before adding or replacing a sub-processor. The Controller may object on reasonable data-protection grounds within that period; if the objection cannot be resolved, the Controller may terminate the Service for the affected processing without penalty.

5.5 Data Subject Rights Assistance (Art. 28(3)(e))

Taking into account the nature of the processing, the Processor assists the Controller in responding to requests under Arts. 15–22.

Erasure on instruction. The Portal does not today give the Controller a self-service button for erasure or export, so the Controller's written instruction is the mechanism. On that instruction the Processor erases the session and its messages and removes the personal content from the associated delivery records — the submitted data, the Controller's system's response, and any error message that quoted them — leaving an accounting skeleton with no personal content: the identifiers of the record, its status, its timing, and, for an emailed request, the Controller's own recipient address. The skeleton is retained so that the Controller keeps a provable trail of what was delivered and when; it identifies no visitor. Where a request was delivered by email, erasure does not reach the copy already sitting in the Controller's own mailbox or in its own systems. That copy is the Controller's to delete. A self-service erasure function in the Portal is planned; until it ships, this instruction route is what exists.

Access and export the Processor performs on instruction. For retrieval, correction, export, or erasure across more than one conversation, the Processor acts on the same written instruction, returns retrieved data in a structured, commonly used machine-readable format (JSON), and actions the request within 10 working days.

The Processor refers any request it receives directly from a data subject to the Controller without responding to it substantively.

5.6 Breach Notification (Art. 33)

The Processor notifies the Controller of a personal data breach without undue delay and in any event within 48 hours of becoming aware of it. The Processor learns of an incident from a security notice by one of its providers, from the Controller, or from its own observation of the Service — not from application logs, whose retention is short (Appendix A(d)).

The notification carries the information available at the time. Where the full picture under Art. 33(3) is not yet established, the information is provided in phases as it is established, without undue further delay — the course Art. 33(4) expressly provides for. Where the logs that would have described the scope of an incident are no longer retained, the Processor says so in the notification rather than implying a completeness it does not have. The Processor assists the Controller with its own notification obligations under Arts. 33 and 34, including the Controller's own 72-hour deadline to the supervisory authority.

5.7 Audits and Inspections (Art. 28(3)(h))

The Processor makes available the information necessary to demonstrate compliance with Art. 28 and contributes to audits by the Controller or an auditor it mandates, on 30 days' written notice, no more than once per year absent a breach or a supervisory authority's requirement, during business hours and subject to confidentiality.

5.8 Retention, Deletion and Return (Art. 28(3)(g); Art. 5(1)(e))

• Abandoned conversations — sessions that carry no delivery record and have had no activity for 24 hours — become eligible for deletion at that point and are removed, together with their messages, by a scheduled job that runs once a night. The worst case is therefore 48 hours from the visitor's last activity, and the usual case is shorter. A session that produced a delivery record, including an emailed request, is not covered by that job.
• Completed conversations, delivery records and forwarded-request records are retained so the Controller can see its own results in the Portal. There is no automatic expiry on them: the Controller decides when they go, and erases them by instruction (Section 5.5). The Processor states this plainly because the alternative — an undisclosed automatic deletion — would remove the Controller's own records without warning.
• Consent records are retained as evidence of consent for 3 years after the visitor last answered the consent question, and are then deleted by the same nightly job, not by a manual step. This is the one deliberate exception to the deletion periods above: a consent record contains an IP address and a user-agent, and it is kept for those 3 years precisely because it is the evidence that the processing was lawful (GDPR Art. 7(1)).
• Voice audio is not retained by the Processor once the transcript is produced. The transcription provider's own retention is stated in Appendix B.
• On termination, the Processor deletes, or returns and then deletes, all personal data processed on the Controller's behalf. Where the Controller instructs return or deletion, that is done within 30 days of the instruction. Where the Controller gives no instruction, the Processor deletes the data within 90 days of termination in any event, subject only to the consent-record period above and to any retention required by EU or Member State law. Silence does not mean indefinite storage.

6. CONTROLLER OBLIGATIONS

6.1 Lawful Basis

The Controller warrants that it has a lawful basis under Art. 6 for the processing it configures, and an Art. 9 condition where applicable.

6.2 Consent and Transparency

The widget asks the visitor for consent before a conversation starts and records that consent with the details listed in Section 4.3(e). The consent it asks for covers the assistant as a whole — typed conversation as much as spoken — because both are processed the same way.

Responsibility for what the visitor is told is split, because the two halves sit in different hands:

• The Processor is responsible for the accuracy of the consent dialog the widget itself displays, in so far as it describes the Processor's own processing — what is collected, where it goes, how long it is kept. The Controller cannot edit that text, so it cannot be made answerable for it. The dialog also offers the visitor a way to withdraw, reachable at any time while the assistant is open.
• The Controller is responsible for its own privacy information under Art. 13 — its identity, its purposes, its lawful basis, its retention and its contact details — and for ensuring that consent is freely given, specific, informed and unambiguous (Art. 7; Recital 32), and for the age threshold applicable in its market (Art. 8). The widget's dialog is not a substitute for that notice.

6.3 Data Minimisation

The Controller configures only the fields it genuinely needs (Art. 5(1)(c)) and does not use free-text fields to collect data it could not collect directly.

6.4 Testing with Real Data

The Controller does not use real customer data to test a configuration in preview (Section 4.1(3)).

6.5 Cooperation with Supervisory Authorities

Each party cooperates with supervisory authorities in relation to the processing under this DPA.

7. INTERNATIONAL DATA TRANSFERS (Arts. 44–49)

7.1 Where Data Is Processed

The Service runs in the European Union (Frankfurt region) and its database is hosted in the European Union (Ireland). Beyond that, two things are true and are stated separately because they are different risks:

• Processing that takes place outside the EEA. The language-model provider used for the conversation and for transcription processes in the United States. The email provider used to forward requests processes in the United States.
• Providers established outside the EEA whose processing for us is inside it. The hosting provider is established in the United States and the database provider in Singapore, even though the data they hold for the Service stays in the European Union. Their establishment matters for provider-side access — support, administration and operational metadata — so they are treated as transfers as well.

Appendix B names each one, where it processes, and the mechanism that covers it.

7.2 Transfer Mechanism

Where the Controller is established in the EEA, there is no third-country transfer between the Controller and the Processor: both are in the European Union. The transfers described above are made by the Processor to its sub-processors, and each is covered by the Processor's own agreement with that sub-processor.

Those agreements incorporate the 2021 Standard Contractual Clauses (Art. 46(2)(c)) — Module Three (processor to processor), or Module Two where that provider's terms are framed that way. Where a provider is additionally certified under the EU–US Data Privacy Framework, that certification applies alongside (Art. 45). The Processor maintains SCC coverage irrespective of the Framework's status, which is subject to a pending appeal before the Court of Justice (Case C-703/25 P).

Where the Controller is established outside the EEA, its own import of the data is governed by its own law, and Chapter V does not apply to it through this agreement.

7.3 Supplementary Measures

Transport encryption; minimisation of what is sent to each provider; contractual commitments that the content is not used to train the provider's models; and the retention limits stated in Appendix B. The Processor has considered the circumstances of each transfer as required by Clause 14 of the SCCs and will make its assessment available to the Controller on request.

8. LIABILITY

Liability follows GDPR Art. 82.

The cap. Each party's total aggregate liability arising out of or in connection with this DPA is limited to the greater of (a) the total fees paid or payable by the Controller for the Service in the twelve months preceding the event giving rise to the claim, or (b) EUR 2,000. The floor exists so that the cap is a real figure during a free pilot or a first partial month, rather than zero.

What the cap covers. It applies between the parties, including a claim for recourse between controller and processor under Art. 82(5) — that is the claim this section is actually about.

What is excluded from liability altogether. Neither party is liable for indirect or consequential loss, loss of profit, loss of revenue, loss of anticipated savings, or loss of goodwill, however arising.

What cannot be capped, and is not. Nothing in this DPA limits liability for intentional misconduct, for death or personal injury, for fraud, or for anything else that the applicable law does not permit to be limited. The cap does not affect a data subject's own rights or remedies under Arts. 79 and 82, an administrative fine imposed on either party by a supervisory authority, or either party's obligations to that authority.

9. COMPLIANCE AND COOPERATION

The Processor assists the Controller, on request and taking into account the nature of processing and the information available, with data protection impact assessments (Art. 35) and prior consultation (Art. 36), and responds to regulatory inquiries concerning the Service.

10. TERM AND TERMINATION

This DPA runs for as long as the Processor processes personal data for the Controller. On termination Section 5.8 applies.

11. GOVERNING LAW AND JURISDICTION

This DPA is governed by the laws of Poland; the courts of Gdynia, Poland have jurisdiction, without prejudice to the data subject's rights under Arts. 77–79 and to the competence of the supervisory authority — in Poland, the President of the Personal Data Protection Office (Urząd Ochrony Danych Osobowych).

12. AMENDMENTS

The Processor may amend this DPA where required by law or by a change in the Service, giving the Controller 30 days' notice. Where an amendment materially reduces the protection afforded to personal data, the Controller may object and terminate the affected processing without penalty.

13. NOTICES AND CONTACT FOR DATA PROTECTION MATTERS

Notices to the Processor: info@webappski.com. Notices to the Controller: the data-protection contact recorded with this agreement.

APPENDIX A — Technical and Organisational Measures (Art. 32)

The measures are stated against the four limbs of Art. 32(1). Each says what is in place, and where a measure is limited by the plan the Service currently runs on, the limit is named rather than left implied.

(a) Pseudonymisation and encryption (Art. 32(1)(a))

• In transit. TLS on every connection the Service receives and makes: browser to Service, Service to database, Service to each sub-processor. Delivery to the Controller's own integration endpoint requires an https:// URL; a plain http:// endpoint is refused rather than silently downgraded.
• At rest. Database encryption at rest as provided by the database platform. Integration secrets the Controller stores — for example an API key for its own booking system — carry a second, application-level encryption (AES-256-GCM) on top of that. Language-model provider credentials held for an organisation are additionally key-versioned and rotatable.
• Credentials. API keys are stored only as hashes; the plaintext key is shown once, at creation, and cannot be shown again.
• Minimisation as a security measure. The session record carries no IP address, no user-agent and no referring page; those live only with the consent record, where they are the evidence of consent.

(b) Confidentiality, integrity, availability and resilience (Art. 32(1)(b))

• Confidentiality. Per-organisation isolation of configurations, sessions and results, and per-organisation authentication of every request. Where the Controller registers domains, requests are additionally restricted to them; registering none leaves that restriction off, and the Controller chooses. Administrative consoles of the Processor's providers are reachable only by the proprietor, each behind an individual account.
• Integrity. Database schema changes are applied as versioned migrations, not ad-hoc edits. Application error logging is routed through a sanitiser that strips secrets and personal data before writing. A small number of low-level call sites still log through the runtime's own error channel; the Processor is migrating them and does not claim the coverage is complete.
• Availability and resilience. The Service runs on a managed hosting platform with automatic restart and redundant regional infrastructure, and on a managed database platform. The present limits, stated plainly rather than implied, because a Controller is entitled to know them before it relies on the Service:
  • The Service runs on the free tiers of its hosting and database providers. On those tiers the database platform provides no automatic backups and no point-in-time recovery — the Processor's own exports, described in section (c), are what exists.
  • Those tiers also carry short provider-side log retention and, on the database platform, the possibility that a project with very little traffic is paused for inactivity until it is next used.
  • The Processor gives no availability SLA in this agreement and will not give one until the underlying plans support it.
  • Commitment: before the widget is first installed live on a Controller's own site, or before the first invoice is issued for the Service — whichever comes first — the Processor moves both platforms to plans that provide automatic daily backups and remove the inactivity pause, and tells the Controller when it has done so. The trigger is deliberately the first live installation and not the first payment, because a Controller who pays nothing still has its visitors' data in the Service. A Controller for whom recovery to a point in time is material should raise it before relying on the Service for that purpose.
• Rate limiting on conversation and cost-bearing endpoints, to keep one organisation's traffic from degrading another's.

(c) Restoring availability and access after an incident (Art. 32(1)(c))

• There are no automatic platform backups on the plan the Service runs on today. What exists instead is the Processor's own export: a dump of the database taken by hand, at the proprietor's discretion, held off-site — a manual step, not a schedule, and described that way because no automated rhythm enforces it. Restoration is performed from the most recent export that exists at the time, so the maximum window of data loss is not guaranteed on this plan — a Controller is entitled to know that rather than to assume continuous recovery, and the commitment in section (b) — plans with automatic daily backups before the first live installation or the first invoice — is how the limit is closed.
• Application code and configuration are held in version control and redeployed from it; recovery of the application does not depend on any single machine.
• Secrets are held in the hosting platform's secret store and are re-issuable by the proprietor.
• There is no warm standby and no documented recovery-time commitment. The Processor states this rather than implying a tested disaster-recovery capability it does not have.

(d) Testing and evaluating effectiveness (Art. 32(1)(d))

• Automated test suites run on every change: unit tests across the shared, API and widget packages, integration tests against a real PostgreSQL instance, and an end-to-end browser suite across multiple engines. Changes that touch a security boundary — the consent gate, the public-configuration boundary, outbound request filtering — carry tests that are verified to fail when the protection is removed, so that the test proves the control and not merely the code path.
• Restoration is not yet tested on a schedule. The Processor has not performed a documented restore drill. This is named as a gap rather than glossed; it is the measure a Controller should ask about first.
• Log retention. Application logs written by the Service are retained by the hosting platform only for the short window its current plan provides — a matter of hours — and are not exported to any further system. They are reviewed on incident, not continuously. The Processor states this because it bears on Section 5.6: an incident discovered after that window has passed cannot be reconstructed from logs, and the notification the Processor gives will say so rather than imply a completeness it does not have.
• The measures in this Appendix are reviewed when the Service changes materially, and at least annually.

APPENDIX B — Sub-processors

Each entry names the entity that contracts, where it is established, where the data is actually processed, and what covers the transfer. Provider terms were read on 20 September 2026; the links are the sources.

Retention at the language-model provider. This is stated separately because it is the one retention the Processor does not control:

• OpenAI's published data-retention documentation states, for /v1/chat/completions, abuse-monitoring retention of up to 30 days and application-state retention of "None". Conversation text therefore sits in that provider's abuse-monitoring logs for up to 30 days before deletion (OpenAI data controls, checked 20 September 2026).
• The same documentation states abuse-monitoring retention of "None" for /v1/audio/transcriptions, the endpoint the spoken audio is sent to. The 30-day period above is about the conversation text, not the audio.
• The Processor relies on those published defaults and cannot vary them: it holds no Zero Data Retention or Modified Abuse Monitoring approval from OpenAI.
• API inputs are not used to train the provider's models by default, per the same documentation.

Other recipients, which are not sub-processors. Named here for completeness, because data reaches them:

• Google Ireland Limited (Google Maps Platform, Places API) — address lookup, and only where the Controller enables an address enrichment. Under Google's controller-controller terms Google acts as an independent controller for this service, not as the Processor's sub-processor; Google names the EU–US Data Privacy Framework with SCCs as fallback. The lookup carries the query text, not the rest of the conversation.
• Google Ireland Limited (Firebase Authentication, Firestore, Cloud Functions) — sign-in for the Controller's own Portal account and the record of this agreement's acceptance. That is the Processor's own processing as an independent controller under Section 3.5, outside this DPA; processing is in the European Union (europe-central2).

APPENDIX C — Standard Contractual Clauses

Where the Standard Contractual Clauses apply under Section 7.2, the 2021 EU Commission SCCs (Implementing Decision (EU) 2021/914) apply as incorporated in the Processor's agreement with each sub-processor named in Appendix B — Module Three (processor to processor), or Module Two where that provider's own terms are framed that way. They are concluded between the Processor and the sub-processor, not between the Controller and the Processor, because that is where the third-country transfer occurs.

The descriptions in Sections 4.1–4.3, Appendix A and Appendix B populate Annexes I–III. Poland is the Member State whose law governs and the Polish supervisory authority (Urząd Ochrony Danych Osobowych) is the competent authority.

Each sub-processor's data processing agreement, in the form the provider publishes and the Processor has accepted, is linked in Appendix B and is public. Where a provider issues a countersigned copy on request, the Processor obtains it and makes it available to the Controller; where a provider's clauses are accepted by acceptance of its terms rather than by signature, there is no countersigned copy to produce, and the published terms together with the Processor's account record are what exists. The Processor will not describe as "executed and on file" a document that is in fact an accepted public form.

This document describes the Service as operated on the date at the top of this page. Questions: info@webappski.com.