Data Processing Agreement (DPA)

Between Data Controller and Data Processor

Effective Date: Upon Service Activation Last Updated: October 5, 2026

PARTIES

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

• The business entity or individual that integrates TypelessForm widget on their website
• Legal name: [TO BE FILLED BY CLIENT]
• Address: [TO BE FILLED BY CLIENT]
• Contact: [TO BE FILLED BY CLIENT]

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

• Lizaveta Isayeuskaya, sole proprietorship (jednoosobowa działalność gospodarcza)
• Address: ul. Leona Staniszewskiego 19a, 81-603 Gdynia, Poland
• VAT ID (EU): PL5862379862
• REGON: 521887646
• 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 the TypelessForm voice-powered form filling service ("the Service").

1.2 Duration

This DPA becomes effective upon Service activation and remains in effect for the duration of the Terms of Service, unless terminated earlier in accordance with Section 10.

1.3 Hierarchy

This DPA forms an integral part of the Terms of Service. In case of conflict between this DPA and the Terms of Service, this DPA prevails regarding data protection matters.

2. DEFINITIONS

Personal Data: Any information relating to an identified or identifiable natural person ("Data Subject"), as defined in GDPR Article 4(1).

Processing: Any operation performed on Personal Data, including collection, recording, storage, transmission, deletion, as defined in GDPR Article 4(2).

Sub-processor: Any third party engaged by the Processor to process Personal Data on behalf of the Controller.

Data Breach: A breach of security leading to accidental or unlawful destruction, loss, alteration, unauthorized disclosure of, or access to Personal Data.

GDPR: Regulation (EU) 2016/679 (General Data Protection Regulation).

Supervisory Authority: An independent public authority responsible for monitoring GDPR application.

3. CONTROLLER AND PROCESSOR ROLES

3.1 Controller Responsibilities

The Controller:

• Determines the purposes and means of processing Personal Data
• Collects consent from Data Subjects (end users) for using voice input
• Provides Privacy Policy to Data Subjects
• Handles Data Subject requests (access, erasure, rectification)
• Ensures lawful basis for processing exists (GDPR Article 6)
• Is responsible for obtaining parental consent for users under 16 (GDPR Article 8)

3.2 Processor Responsibilities

The Processor:

• Processes Personal Data only on documented instructions from the Controller
• Does NOT determine purposes or means of processing
• Provides technical infrastructure for voice input processing
• Ensures Sub-processors comply with GDPR
• Assists Controller with Data Subject requests
• Notifies Controller of Data Breaches within 24 hours

3.3 Prohibited Actions

The Processor shall NOT:

• Process Personal Data for its own purposes
• Disclose Personal Data to third parties (except Sub-processors)
• Transfer Personal Data outside instructed scope
• Use Personal Data for marketing, profiling, or analytics
• Train AI models on Controller's Personal Data

3.4 Independent Controller for Infrastructure Security Logs

For infrastructure security logs strictly necessary to operate the Service (e.g., timestamps, HTTP status codes, request duration, User-Agent, and IP addresses as logged by Google Cloud), the Processor acts as an independent controller under GDPR Art. 6(1)(f) (legitimate interests) and Recital 49 (network and information security).

Scope:

• Data: Timestamps, HTTP status/error codes, request duration, User-Agent, infrastructure IP (logged by GCP)
• Purpose: Security monitoring, abuse detection, DDoS protection, debugging production errors
• Legal basis: Processor's legitimate interests (Art. 6(1)(f)) for network security (Recital 49)
• Retention: Maximum 30 days, then automatic deletion
• Location: Google Cloud Logging, global location, with no guarantee that these logs stay in the EU (the data the Processor stores itself, such as client configurations and consent receipts, is kept in the EU: europe-central2)

Data Minimization:

• Logs are not combined with Customer Content
• Not used for profiling, tracking, or marketing
• Access restricted to authorized administrators only
• IP addresses processed transiently by infrastructure; not enriched with additional personal data

Transparency:

• Disclosed in Processor's Privacy Policy (https://webappski.com/en/legal/website-privacy)
• Data Subjects may exercise rights by contacting info@webappski.com

For all other processing activities (voice transcriptions, form field metadata), Processor acts solely as a Processor on the Controller's documented instructions.

For details on infrastructure log processing, see the Website Privacy Policy Section 2.2 (Automatically Collected Information) and the End-User Privacy Policy Section 2.3 (Technical Data).

3.5 Independent Controller for Portal User Account Data

For portal/dashboard user account data, the Processor acts as an independent Data Controller under GDPR Art. 6(1)(b) (performance of contract). This processing is separate from the Client's end-user widget data, for which the Client remains the Controller.

Scope:

• Data types: Firebase UID, email address, display name, subscription tier, usage metrics (API call counts, fill counts), API key hashes (SHA-256; raw keys not stored after initial generation), registered domains
• Purpose: Account management, subscription billing, service delivery, usage enforcement
• Legal basis: Art. 6(1)(b) GDPR — processing necessary for performance of the contract between Processor and the portal user (Client)
• Retention: Until account deletion by the user; billing and invoice records retained for 5 years to comply with Polish accounting and tax obligations (Ustawa o rachunkowości)
• Location: Processed in EU regions (europe-central2 / eur3) via Firestore; payment data processed by Stripe, Inc. (see Sub-processor list)

Role Clarification:

• For portal account data (subscription, billing, usage): Processor is the Data Controller
• For end-user widget data (voice transcriptions, form metadata, consent receipts): the Client is the Data Controller, and Processor acts solely as Data Processor on the Client's documented instructions

Data Subject Rights:

Portal users (Clients) may exercise their GDPR rights regarding their account data by contacting info@webappski.com. This includes:

• Right of access (Art. 15): Obtain a copy of account data
• Right to erasure (Art. 17): Request account deletion (subject to billing record retention)
• Right to data portability (Art. 20): Export account data in JSON format
• Right to rectification (Art. 16): Update account information via the dashboard or by contacting support

Data Export:

Clients may request export of their usage logs (API call history, fill counts, error rates) in JSON format by contacting info@webappski.com. Export requests will be fulfilled within 14 business days.

For details on how portal account data is processed, see the Website Privacy Policy at https://webappski.com/en/legal/website-privacy, Sections 2.1 (Portal Account Registration), 2.3 (Subscription & Billing Data), and 2.4 (API Key Management).

4. DESCRIPTION OF PROCESSING

4.1 Nature and Purpose of Processing

Purpose: Voice-powered form completion assistance

Processing Activities:

1. Voice-to-text transcription (via the OpenAI speech-to-text API, model gpt-4o-mini-transcribe)
2. Natural language to structured data mapping (via OpenAI GPT models)
3. Language detection and translation (via OpenAI GPT models)
4. Form field analysis and badge generation
5. System logging for debugging and error investigation

4.2 Categories of Data Subjects

• End users of Controller's website who voluntarily use the voice input feature
• Typically: adults (18+) or minors with parental consent (as required by Controller)

4.3 Types of Personal Data Processed

Primary Data (User-Provided):

• Voice transcriptions (text of spoken words)
• Extracted form data (names, emails, phone numbers, addresses, etc.)
• Language preference (browser language)

Metadata (Form Structure - sent to our API when the widget first reads a form):

When the widget first reads a form, it sends our API a description of every visible, enabled field (hidden fields, disabled fields, submit, reset and button inputs, and fields with no name, label or placeholder are skipped). This description includes fields marked private (data-ai-private, data-private="true") and password fields: nothing is removed from it on the device before it is sent. It contains no field values.

• Field names, labels and placeholder text (e.g., "Full Name", "Email Address", "Enter your name", "Min 8 characters")
• Field types (e.g., text, email, tel, password)
• Form title from the webpage and section headings
• Option labels of dropdown, radio and checkbox fields (at most 10 per field are kept)
• Field structure metadata:
  • HTML tag names (e.g., "nz-select", "mat-select", "ion-datetime"), CSS classes (for UI library detection), the required flag, and the datalist flag and list id
  • ARIA attributes (role, aria-haspopup, aria-controls)
  • Data attributes (the private flag, data-ai-label)

Of this description, our API passes the following to OpenAI (GPT models, in separate calls for language detection, label translation, sensitive-field classification and form naming): field names, the best available label of each field (its label, ARIA label, name, placeholder or, when a field has none of these, its first option), placeholder text, data-ai-label text, field types, tag names, role and aria-haspopup, section headings, the form title, whether a list has options, and the private flag. CSS classes, aria-controls, the datalist flag and list id, and the required flag stay on our API and are not passed to OpenAI.

At fill time OpenAI receives the transcript; the name, label, type and placeholder of fields not marked data-ai-private; the option values of select, radio and checkbox-group fields; and min/max/step/pattern constraints.

Metadata (Processed by our infrastructure; NOT sent to OpenAI):

• Page URL where the form is located (used for diagnostics/compatibility; Controller should avoid PII in query parameters)
• User Agent (browser type and version, used for compatibility/security)

Technical Data:

• Temporary audio recordings (memory buffer only, never stored)
• Processing timestamps

Consent Audit Data (Consent Receipt):

• Pseudonymous user ID (UUID, randomly generated)
• Consent timestamp (date/time when user clicked "I Accept")
• Consent method (checkboxes + button click)
• Policy version (e.g., "v1.0")
• Modal text hash (SHA-256 of consent text shown)
• Widget version (e.g., "1.0.0")
• UI locale (language in which consent was displayed, e.g., "en", "ru")
• Checkbox states (boolean: checkboxMain, checkboxAge)
• User-Agent (browser type, for compatibility verification and consent record search)
• Domain (website domain where consent was given, for audit trail)
• IP hash (daily-rotating): SHA-256 of the IP address and the UTC date, computed without a secret key; pseudonymous, treated as personal data
• Linked user IDs: pseudonymous IDs of consent records with the same IP hash and domain

How Private and Sensitive Fields Are Handled:

A field is private when it carries data-ai-private or data-private="true", or is a password field. A field is sensitive when our server flags it: a classifier model (an OpenAI GPT model) reads the field descriptions, and fixed guardrail rules apply on top of its answer. The classifier decides which fields are sensitive; the guardrails guarantee only password fields, fields marked private, and one-time or second-factor codes recognisable from the field's own name, label or placeholder; file, colour and range inputs are not offered for voice filling. Whether a payment-card number, a government identity number or an Article 9 label is flagged depends on the classifier, and free-text health fields are not flagged: mark them data-ai-private. For these fields:

1. No local pre-filtering. The widget does not remove any label, placeholder or type from the description of the form before it is sent. Sensitive fields are identified on our server, from that description, with the help of OpenAI.
2. Not filled by voice. The widget writes no spoken value into a private or sensitive field.
3. Private fields are cut out of the filling request. After the Data Subject speaks, the widget leaves private fields out of the request that fills the form, and our server drops them again. Their names, labels and placeholders are therefore not part of that request. A field that the classifier or the guardrails flag as sensitive but that is not private stays in that request; it is only not filled.
4. Data said aloud. Digits or other data a Data Subject says aloud stay in the audio and in the transcription, which go to OpenAI as described in this DPA, whether or not the field is filled.

Data Minimization Principle (GDPR Article 5(1)(c)): The description of the form that is sent when it is first read contains no field values, and private fields are cut out of the request that fills the form. The Processor does not filter labels before sending them, so minimisation of the labels themselves rests on the Controller: marking fields with data-ai-private where needed, and the measures in Section 4.4 where labels may reveal Article 9 data.

Exhaustiveness Note: The classifier and the guardrails cannot catch all variants of sensitive field labels, and they act after the description of the form has been sent. Controller must use the data-ai-private attribute for company-specific sensitive fields so that they are not filled by voice and are cut out of the filling request.

Data Subject Impact:

• ✅ No field values are sent when the form is first read. Only the description of the fields listed above is sent.
• ✅ No value that was already in the form goes to OpenAI. When the Data Subject speaks, the widget includes the value currently in each non-private field in the request to our API; our server does not use these values, does not pass them to OpenAI and does not write them to its logs.
• ⚠️ The labels of private and sensitive fields ARE sent (to our API and to OpenAI) when the form is first read. Marking a field private keeps it out of voice filling and out of the filling request; it does not keep it out of that first read.
• ⚠️ Company-specific sensitive labels (e.g., "Internal Reference Code", "Confidential Project Name") require Controller to mark with data-ai-private attribute

Consent Audit Data Processing Details:

• Purpose: GDPR Art. 7(1) proof of consent, security audit, compliance verification
• Legal Basis: Data Subject's consent (Art. 6(1)(a)) for voice feature + Processor/Controller's legitimate interests (Art. 6(1)(f)) for auditability and compliance
• Retention: Maximum 24 months, then automatic deletion (Controller may specify shorter period)
• Storage Location: Firestore database (Google Cloud Platform, EU/Poland region)
• Transmission to Sub-processors: NOT transmitted to OpenAI; only stored in Firestore for audit purposes
• Data Minimization: UUID is pseudonymous (not linked to Data Subject's identity); only essential audit fields stored

4.4 Special Categories of Personal Data (GDPR Article 9)

The Service is NOT intended to process Special Categories of Personal Data under GDPR Article 9 (racial/ethnic origin, political opinions, religious beliefs, health data, sexual orientation, biometric data, genetic data, trade union membership, sex life).

⚠️ CRITICAL WARNING - Field Labels Risk:

Processor acknowledges that form field labels may inadvertently contain Special Categories of Personal Data, even when field VALUES are not sent to OpenAI. Examples:

• "HIV Test Result" (health data)
• "Political Party Affiliation" (political opinions)
• "Religious Beliefs" (religious data)
• "Sexual Orientation" (sensitive personal data)
• "Ethnic Origin" (racial/ethnic data)
• "Trade Union Membership" (union membership)

How Processor Detects Article 9 Labels: Processor's classifier model may flag common Article 9 labels (e.g., religion, political opinions, trade-union membership) so that those fields are not filled by voice; the guardrail rules guarantee only password fields, private fields and one-time or second-factor codes recognisable from the field's own name, label or placeholder. Free-text health fields are not flagged: mark them data-ai-private. This detection runs on our server after the description of the form, including these labels, has been sent to our API and to OpenAI. It is not a filter applied to the description before it is sent, and it is NOT exhaustive: it cannot catch all variations.

Since field labels, including those of private fields, are sent to our API and to OpenAI when the form is first read, and detection is not exhaustive, Controller MUST:

1. Conduct Pre-Integration Review:

• Audit all forms for Article 9 field labels BEFORE integrating widget
• Document which forms contain Article 9 data
• Conduct Data Protection Impact Assessment (DPIA) per Article 35 if Article 9 data present

2. Obtain Explicit Consent (Article 9(2)(a)):

• If forms contain Article 9 field labels, obtain explicit consent from Data Subjects
• Consent must be separate and specific for Article 9 processing
• Generic consent for voice input is NOT sufficient for Article 9 data

3. Use Technical Safeguards:

• Mark Article 9 fields with data-ai-private attribute so that they are not filled by voice and are cut out of the filling request (their labels are still sent when the form is first read)
• Disable widget on forms containing Article 9 data if explicit consent cannot be obtained
• Implement additional encryption or pseudonymization where feasible

4. Controller's Legal Basis:

• Ensure lawful basis under Article 9(2) exists (explicit consent, vital interests, legal claims, etc.)
• Document legal basis in Controller's privacy policy
• Implement additional safeguards per Article 9(2) requirements

If Data Subjects speak Article 9 information during voice input (despite warnings), Controller is additionally responsible for:

• Obtaining explicit consent for voice processing of Article 9 data
• Informing Data Subjects of 30-day retention in logs
• Ensuring OpenAI processing complies with Article 9 requirements

Processor's Limitations:

• Processor CANNOT automatically detect all Article 9 field labels (e.g., "Status" instead of "HIV Status")
• Processor CANNOT prevent Data Subjects from speaking Article 9 information
• Processor relies on Controller to use data-ai-private for Article 9 fields
• Controller bears primary responsibility for Article 9 compliance

Joint Liability (Article 82): If Article 9 data is processed without proper safeguards, both Controller and Processor may be held jointly liable for GDPR violations under Article 82(4).

5. PROCESSOR OBLIGATIONS

5.1 Processing Instructions

The Processor shall process Personal Data only based on documented instructions from the Controller, unless required by EU or Member State law (GDPR Article 28(3)(a)).

Documented Instructions:

• This DPA and Terms of Service
• Technical implementation as described in TECHNICAL.md
• Controller's integration configuration (domain whitelist, data-ai-private attributes)

Out-of-Scope Instructions: If Controller requests processing that Processor reasonably believes violates GDPR or other applicable law, Processor shall immediately inform Controller and may refuse to comply.

Technical Implementation and Infrastructure:

Processor's service is implemented as a serverless application using cloud infrastructure. Controller acknowledges the following technical architecture:

• Infrastructure Provider: Google Cloud Platform (Firebase)
  • Firebase Cloud Functions Gen2 (compute/processing)
  • Google Cloud Logging (system logs, 30-day retention)
  • Firestore (client configuration storage)
• Data Storage: All Personal Data is stored and processed within Google Cloud's secure infrastructure
• Physical Infrastructure: Processor does not operate physical servers, data centers, or storage facilities
• Security Responsibility: Physical security, infrastructure security, and data center operations are managed by Google Cloud Platform under their SOC 2, ISO 27001, and ISO 27018 certifications
• Processor's Role: Processor is responsible for application-level security (code, configuration, access controls, PII sanitization) but relies on Google Cloud for infrastructure-level security

Security Documentation:

• Google Cloud Security: https://cloud.google.com/security
• Google Cloud Compliance: https://cloud.google.com/security/compliance
• SOC 2 Reports: Available from Google Cloud upon request (Controller may request from Processor, who will facilitate access)

Implications for Liability:

• Infrastructure failures (e.g., Google Cloud data center breach, unauthorized access to Cloud Run) are Sub-processor breaches under GDPR Article 28(4)
• Application-level failures (e.g., bugs in Processor's code, misconfigured access controls) are Processor's direct responsibility
• Processor remains fully liable to Controller for Sub-processor performance under GDPR Article 28(4) (see Section 8.2)

5.2 Confidentiality (GDPR Article 28(3)(b))

Processor ensures that persons authorized to process Personal Data:

• Are bound by confidentiality obligations
• Have received appropriate GDPR training
• Access Personal Data only as necessary for their role

Authorized Personnel:

• System administrators (for debugging and infrastructure management)
• No other personnel have access to logs or Personal Data

5.3 Security Measures (GDPR Article 28(3)(c) & Article 32)

Technical Measures:

• Encryption in transit: TLS 1.2+ (HTTPS) for all data transmission
• Encryption at rest: Google Cloud Logging encryption (AES-256)
• Access control: Role-based access, multi-factor authentication for admins
• API security: Firebase Cloud Functions with secrets management
• No persistent storage: Audio exists only in memory, never saved to disk

Organizational Measures:

• Security policies and procedures documented
• Incident response plan (24-hour breach notification to Controller)
• Regular security reviews and updates
• Vendor security assessments (Google Cloud, OpenAI)

Pseudonymization/Anonymization:

• No cookies and no tracking; the identifiers we hold are, e.g., the pseudonymous ID and the daily-rotating IP hash of the consent record (see Consent Audit Data)
• PII sanitization applied to error logs of the completion endpoint (automatic redaction of emails, phone numbers, credit cards, API tokens)
• Correlation IDs used for error tracking without exposing Personal Data

Technical Logs for Security and Abuse Prevention:

Processor may retain minimal technical logs for legitimate interests under GDPR Article 6(1)(f):

• Purpose: Security monitoring, abuse detection, DDoS protection, and debugging production errors
• Data collected: IP addresses (infrastructure logs only), timestamps, User Agent, request duration, error codes
• Retention: Maximum 30 days, then automatic deletion
• Safeguards:
  • Data minimized (no Personal Data content from requests)
  • Access restricted to authorized administrators only
  • Not used for profiling, tracking, or marketing
  • Not shared with third parties
  • Separate from Customer Content logs

Note: These technical logs are distinct from Customer Content and are processed under Processor's legitimate interests for security purposes, not under Controller's instructions. See GDPR Recital 49 (network and information security) and CJEU Breyer (C-582/14) on IP addresses as Personal Data.

Limitations: ⚠️ Processor CANNOT prevent Data Subjects from speaking sensitive information. Controller must educate users about appropriate voice input usage.

5.4 Sub-processors (GDPR Article 28(2) & (4))

Current Sub-processors:

Sub-processor Agreements:

• All Sub-processors bound by contracts imposing same GDPR obligations as this DPA
• EU Standard Contractual Clauses (SCCs) in place for international transfers

Changes to Sub-processors:

• Processor may engage new Sub-processors with 30 days' prior notice to Controller
• Controller may object within 14 days if reasonable grounds exist
• If Controller objects, Controller may terminate Services without penalty
• List of Sub-processors maintained at: https://webappski.com/en/legal/dpa (or upon request)

Sub-processor Terms Changes:

"Material Change" includes:

• New processing purposes not covered by current DPA
• New categories of Personal Data processed
• Change of processing location or data transfer mechanism (e.g., SCCs → DPF)
• Increased retention periods
• Introduction of high-risk processing activities
• Changes affecting GDPR Article 28 compliance

If OpenAI or Google Cloud materially changes their data processing terms, Processor shall:

1. Notify Controller within 15 calendar days of becoming aware of such changes
2. Provide summary of changes and potential impact on Controller's data
3. Assess GDPR compliance of new terms and inform Controller of any risks
4. Allow Controller to object within 30 days if changes are incompatible with Controller's obligations
5. Use commercially reasonable efforts to propose mitigation or alternative Sub-processor
6. If no feasible alternative exists, Controller may suspend/terminate affected Services without penalty

Controller's Rights:

• Controller may terminate Services without penalty if Sub-processor terms become incompatible with GDPR
• Processor shall monitor Sub-processor terms quarterly and maintain change log

5.5 Data Subject Rights Assistance (GDPR Article 28(3)(e))

Controller is responsible for responding to Data Subject requests. Processor shall assist Controller by:

Right to Access (Article 15):

• Providing logs/data within 7 days if Controller requests
• Note: Logs auto-deleted after 30 days; earlier requests have better chance of retrieval

Right to Erasure (Article 17):

• Deleting specific Data Subject's data from logs upon Controller request
• Note: Logs auto-deleted after 30 days; no action needed if beyond 30 days

Right to Rectification (Article 16):

• Not applicable (Processor does not store long-term Personal Data)

Right to Data Portability (Article 20):

• Providing data in JSON format if Controller requests within 30-day log window

Right to Object/Restrict Processing (Articles 18, 21):

• Suspending processing for specific Data Subject upon Controller request

Response Time:

• Processor shall respond to Controller's assistance requests within 7 business days
• Processor may charge reasonable fees for complex requests exceeding 2 hours of work

5.6 Breach Notification (GDPR Article 33 & 34)

Processor's Obligations:

1. Notification without undue delay to Controller upon discovery of Data Breach

• Preliminary notice: Maximum 24 hours from becoming aware of breach (even if full details not yet available)
• Detailed notice: Maximum 48 hours from becoming aware, including all required information below

2. Notification includes:

• Nature of breach (what data, how many Data Subjects affected)
• Likely consequences
• Measures taken or proposed to mitigate harm
• Contact point for further information

Notification Method:

• Email to Controller's registered contact: [Controller email from account]
• Backup: info@webappski.com if Controller's email fails

Controller's Obligations:

• Controller is responsible for notifying Supervisory Authority within 72 hours (GDPR Article 33)
• Controller is responsible for notifying Data Subjects if high risk (GDPR Article 34)

Processor's Assistance:

• Processor shall cooperate with investigations
• Processor shall provide technical details of breach
• Processor shall implement remediation measures

5.7 Audits and Inspections (GDPR Article 28(3)(h))

Controller's Rights:

• Request information to demonstrate GDPR compliance (annually)
• Conduct audits or appoint independent auditor (with 30 days' notice)

Processor's Cooperation:

• Provide requested documentation within 14 days
• Allow on-site inspections (with 30 days' notice, during business hours)
• Respond to audit findings within 30 days

Audit Costs:

• Controller bears audit costs for routine audits
• Processor bears costs if non-compliance found

Frequency Limitation:

• Maximum 1 audit per year unless Data Breach or Supervisory Authority request

5.8 Data Deletion and Return (GDPR Article 28(3)(g))

Upon Termination of Services:

• Processor shall delete all Personal Data within 30 days of termination
• Processor shall provide written certification of deletion upon request
• Exception: Data required by law (e.g., accounting, tax records) may be retained

During Service - Retention Periods and Justification:

System Logs (30 days retention):

• Purpose: Debugging production errors, monitoring abuse, investigating Data Breaches
• Justification:
  • Most production bugs are discovered within 7-14 days of occurrence
  • Data Breach investigations under GDPR Article 33 require historical logs (72-hour notification window)
  • Abuse pattern detection requires multi-week data for statistical analysis
• Data Minimization:
  • Logs contain metadata, e.g. (transcript length, detected language, audio duration, timings, error types and codes, HTTP status, field identifiers) - NO transcript text or field values stored
  • IP addresses are not intentionally logged by Processor; infrastructure may temporarily process transient IPs for security and routing (see §3.4 for Independent Controller role)
  • NO audio recordings stored
  • Personal Data (voice transcriptions, form data) is NOT logged - only metadata and the consent identifiers named under Consent Audit Data
• Alternative Considered: 7-day retention insufficient for thorough breach investigation and debugging complex issues

OpenAI Data Retention (up to 30 days — text endpoints):

• OpenAI retains abuse-monitoring logs, which hold the text of the requests and responses of the chat calls (for TypelessForm: the transcript, the descriptions of the form fields and the filled values), for up to 30 days, "unless longer retention is required by law, or is reasonably necessary to protect our services or any third party from harm" (OpenAI data controls, checked 5 October 2026)
• Processor cannot override or reduce this retention period: as at the date of this document the Processor holds no Zero Data Retention or Modified Abuse Monitoring approval from OpenAI
• This period applies to the text endpoints used for field mapping and language detection. The speech-to-text endpoint is stated separately by OpenAI — see the audio section below
• OpenAI does NOT use API data for model training

Audio Recordings — Processor side (0 days retention):

• Audio exists ONLY in a memory buffer during transcription (typically 1-5 seconds)
• Audio is NEVER written to disk, to storage or to logs by the Processor
• The buffer is released as soon as the transcription response returns; the Processor keeps no copy of the audio

Audio Recordings — Sub-processor side (OpenAI):

• To be transcribed, the audio is transmitted to OpenAI's speech-to-text endpoint (/v1/audio/transcriptions, model gpt-4o-mini-transcribe). Once transmitted it is outside the Processor's control, and the Processor's own 0-day statement above does not extend to it
• OpenAI's published data-retention documentation states abuse-monitoring retention of "None" for /v1/audio/transcriptions (OpenAI data controls, checked 5 October 2026)
• The Processor relies on that published default and cannot vary it: it holds no Zero Data Retention or Modified Abuse Monitoring approval from OpenAI

Client Configuration Data (Retained for Service Duration):

• Firestore stores only: domain, API key, rate limits, feature flags
• NO end-user Personal Data stored in Firestore (except consent receipts, see below)
• Deleted within 30 days of Service termination

Consent Audit Data (24 months retention):

• Purpose: GDPR Art. 7(1) proof of consent - Controller must demonstrate that Data Subjects gave informed consent
• Justification:
  • Consent validity may be challenged months or years after collection
  • GDPR does not specify maximum retention period for consent records; 24 months is reasonable for audit and legal defense
  • Shorter retention (e.g., 12 months) would undermine ability to prove consent in delayed complaints or audits
• Data Minimization:
  • Only pseudonymous UUID and essential audit metadata stored (no names, e-mail addresses or form content)
  • Consent records stored in a separate Firestore collection (user-consents); the pseudonymous ID and a shortened hash prefix are also written to the application log (30 days)
  • NOT transmitted to OpenAI or other Sub-processors
• Alternative Considered: 12-month retention insufficient for compliance defense if Data Subject files complaint 18-24 months after consent
• Controller's Rights: Controller may request shorter retention period if justified; Processor shall assess feasibility within 14 days

Retention Period Review:

• Processor shall review retention periods annually to assess necessity
• If technical improvements allow shorter retention (e.g., better error monitoring), Processor shall reduce retention periods accordingly
• Controller may request shorter retention periods if justified; Processor shall assess feasibility within 14 days

Litigation Hold: Retention periods may be extended where required by EU or Member State law, or where necessary to establish, exercise, or defend legal claims.

Return of Data:

• Controller may request export of logs before termination (if within 30-day window)
• Format: JSON or CSV as agreed
• Processor may charge reasonable fee for large exports (>10,000 records)

6. CONTROLLER OBLIGATIONS

6.1 Lawful Basis for Processing

Controller warrants that:

• Lawful basis for processing exists under GDPR Article 6
• Consent obtained from Data Subjects for voice input (Article 6(1)(a))
• Privacy Policy provided to Data Subjects
• Data Subjects informed of risks (30-day log retention, OpenAI processing)

6.2 Data Subject Consent

Controller is responsible for:

• Obtaining informed consent for voice input feature
• Obtaining parental consent for minors under 16 (Article 8)
• Informing Data Subjects they can withdraw consent anytime

Minimum Notice Elements Required Prior to First Use:

Controller shall ensure that Data Subjects are presented with a clear notice before first use of the voice input feature, covering at least the following elements:

1. Sub-processor Processing:

• Voice and form metadata will be sent to OpenAI (the speech-to-text API, model gpt-4o-mini-transcribe, for transcription; OpenAI GPT models for field mapping)
• OpenAI acts as Sub-processor under EU Standard Contractual Clauses

2. Data Retention:

• Usage and form-structure metadata (text length, detected language, audio duration, timings, error types and field identifiers) are logged for 30 days, then deleted; the text of voice transcriptions and of field values is not logged
• OpenAI retains the requests and responses of its chat calls (the transcript, the form-field descriptions and the filled values) for up to 30 days for abuse monitoring (cannot be shortened)

3. International Transfers:

• Personal Data transferred to United States (OpenAI, Google Cloud Platform)
• Transfers protected by EU Standard Contractual Clauses (SCCs)

4. Security Logs (Independent Controller Role):

• Processor acts as independent Controller for infrastructure security logs (IP addresses, timestamps)
• Legal basis: Legitimate interests under GDPR Article 6(1)(f) for network security
• Retention: 30 days maximum

5. Special Categories of Data (Article 9):

• If forms contain Article 9 field labels (health, political opinions, religious beliefs, etc.), separate explicit consent required
• Generic consent for voice input is NOT sufficient for Article 9 data
• Controller must mark Article 9 fields with data-ai-private attribute

6. User Responsibilities:

• Do NOT speak highly sensitive information (passwords, payment data, government IDs)
• Processor's sensitivity detection is not exhaustive and cannot catch all variations

Notice Format:

• Notice may be presented as: consent banner, modal dialog, checkbox with link to Privacy Policy, or other conspicuous method
• Notice must be separate and specific for voice input (not bundled with general website consent)
• For Article 9 data, explicit consent must be obtained separately with clear explanation of risks

Recommended Implementation: Controller may use the consent template provided in Processor's Integration Guide (available at https://webappski.com/en/legal/dpa) as a starting point, but Controller is responsible for adapting the template to their specific legal requirements and jurisdiction.

Consent Receipts - Controller's Instruction: Controller authorizes Processor to store consent receipts (audit records) in pseudonymous form for the purpose of GDPR Art. 7(1) proof of consent. Controller confirms that:

• Default retention period of 24 months is acceptable (Controller may request shorter retention if justified)
• Consent receipt storage serves Controller's legitimate interests in compliance and auditability
• Controller will provide instructions for deletion if required by Data Subject requests or regulatory guidance

6.3 Data Minimization

Controller shall:

• Use data-ai-private attribute for company-specific sensitive fields, to keep a field out of voice filling and out of the filling request (its label is still sent when the form is first read)
• Educate Data Subjects NOT to speak highly sensitive information (passwords, SSN, etc.)
• Keep card numbers out of the filling request: a card number typed into a field that is not marked data-ai-private reaches our API with the filling request (not OpenAI); keep card fields in the payment provider's frame or mark them data-ai-private
• Not use Service for Special Categories of Personal Data (Article 9) without additional safeguards

6.4 Supervisory Authority Cooperation

Controller shall:

• Handle all Supervisory Authority inquiries related to Data Subjects
• Notify Processor if Supervisory Authority requests information
• Provide Processor's contact to Supervisory Authority if technical questions arise

7. INTERNATIONAL DATA TRANSFERS

7.1 Transfer Locations

Personal Data is transferred from European Union to United States for processing by Sub-processors (OpenAI, Google Cloud Platform).

7.2 Legal Mechanisms

Transfers are protected by:

• EU Standard Contractual Clauses (SCCs) approved by European Commission (Decision 2021/914)
  • OpenAI: Module 2 (Controller-to-Processor) and Module 3 (Processor-to-Processor) via OpenAI DPA
  • Google Cloud: Module 2 and Module 3 via Google Cloud Data Processing Terms
• Note (verified 2025-01-16): OpenAI is not currently listed in the EU-U.S. Data Privacy Framework; transfers rely solely on SCCs and supplementary measures

7.3 Supplementary Safeguards (Schrems II Compliance)

To comply with CJEU Schrems II decision (C-311/18), the following supplementary measures are implemented:

• Encryption in transit: TLS 1.2+ (HTTPS) for all data transmission
• Encryption at rest: AES-256 for stored data
• Access controls: Role-based access, multi-factor authentication for administrators
• Data minimization: 30-day retention period with automatic deletion
• Contractual protections: Sub-processors contractually bound to same GDPR obligations
• Technical segregation: Customer Content segregated from operational data

7.4 Suspension of Transfers

If EU or Member State law prohibits international transfers (e.g., Schrems III-type ruling):

• Controller may request suspension of transfers
• Processor shall cooperate to find alternative solutions (e.g., EU-based Sub-processors)
• If no solution found, Controller may terminate Services without penalty

8. LIABILITY AND INDEMNIFICATION

8.1 GDPR Liability (Article 82)

• Controller and Processor are jointly liable to Data Subjects for damages under GDPR Article 82
• Processor is liable only if it has not complied with GDPR obligations specifically directed to Processors (Article 28) OR if it has acted outside or contrary to lawful instructions from Controller

8.2 Liability Cap

Subject to Section 9.1 of the Terms of Service, Processor's total aggregate liability under this DPA for all claims arising in any rolling twelve (12)-month period shall not exceed the greater of:

(a) the total fees actually paid by Controller to Processor during the twelve (12) months immediately preceding the event giving rise to the claim; or

(b) EUR 50,000.

This cap applies regardless of the legal theory (contract, tort, negligence, strict liability, GDPR Article 82) and covers all claims by Controller under this DPA, including indemnification payments.

8.3 Excluded Damages

Neither party shall be liable for indirect, incidental, special, consequential, or punitive damages, or for loss of profits, revenue, goodwill, or data, even if advised of the possibility of such damages.

8.4 Exceptions

Nothing in this Section limits liability for:

• Fraud or willful misconduct
• Death or personal injury caused by negligence
• Processor's obligations under GDPR Articles 28-32 (to the extent such liability cannot be limited under applicable law)
• Controller's unpaid, undisputed fees

8.5 Sub-processor Liability

Where a Sub-processor (OpenAI, Google Cloud Platform, or any other Sub-processor) causes losses to Controller, Processor shall:

1. Pursue claims against the Sub-processor on Controller's behalf
2. Assign any recovered amounts to Controller (proportional to Controller's loss)
3. Cooperate with Controller in pursuing direct claims against Sub-processor where legally possible

Processor's liability for Sub-processor breaches is limited to the cap in Section 8.2.

9. COMPLIANCE AND COOPERATION

9.1 Regulatory Inquiries

If either party receives inquiry from Supervisory Authority:

• Notify other party within 24 hours
• Cooperate fully with investigations
• Provide requested documentation promptly

9.2 Data Protection Impact Assessment (DPIA)

If Controller conducts DPIA (Article 35):

• Processor shall provide Technical Documentation (TECHNICAL.md)
• Processor shall answer Controller's questions within 14 days
• Processor shall review Controller's DPIA for technical accuracy (optional service)

9.3 Prior Consultation with Supervisory Authority

If Controller must consult Supervisory Authority (Article 36):

• Processor shall provide information as requested
• Processor shall cooperate with Supervisory Authority's recommendations

10. TERM AND TERMINATION

10.1 Term

This DPA remains in effect as long as Services are active.

10.2 Termination by Controller

Controller may terminate:

• For convenience: 30 days' notice
• For breach: Immediate termination if Processor breaches GDPR or this DPA and fails to cure within 14 days
• For Sub-processor change: 14 days after notice of new Sub-processor if Controller objects

10.3 Termination by Processor

Processor may terminate:

• If Controller requests processing that violates GDPR or applicable law
• If Controller fails to pay fees for 30+ days (see Terms of Service)

10.4 Effect of Termination

Upon termination:

• Processor deletes all Personal Data within 30 days
• Processor provides written certification of deletion (if requested)
• Outstanding fees remain payable
• Sections 8 (Liability), 11 (Governing Law), survive termination

Post-Termination Consent Receipt Retention: After termination of this DPA, Processor retains consent receipts (pseudonymous UUID, timestamp, consent version, daily-rotating IP hash) as an independent controller under GDPR Art. 6(1)(f) (legitimate interests — proof of lawful processing, legal defense) for the remainder of the applicable retention period (maximum 24 months from collection). This retention is necessary to demonstrate that Data Subjects' consent was lawfully obtained during the contract period, and serves both parties' legitimate interests in legal compliance and dispute resolution.

11. GOVERNING LAW AND JURISDICTION

11.1 Governing Law

This DPA is governed by the laws of Poland.

11.2 Jurisdiction

Any disputes arising from this DPA shall be resolved exclusively in the Courts of Warsaw, Poland.

11.3 GDPR Supremacy

In case of conflict between Polish law and GDPR, GDPR prevails.

11.4 Supervisory Authority

The lead Supervisory Authority for Processor is: Urząd Ochrony Danych Osobowych (UODO) ul. Stawki 2, 00-193 Warsaw, Poland Website: https://uodo.gov.pl/

12. AMENDMENTS

12.1 Amendment Process

This DPA may be amended:

• By mutual written agreement
• By Processor to comply with GDPR or other legal requirements (30 days' notice)

12.2 Notice of Amendments

Amendments notified via:

• Email to Controller's registered contact
• Dashboard notification (if applicable)
• Updated document published at https://webappski.com/en/legal/dpa

12.3 Objection to Amendments

If Controller objects to amendments within 14 days:

• Parties shall negotiate in good faith
• If no agreement, Controller may terminate Services without penalty

13. ENTIRE AGREEMENT

This DPA, together with the Terms of Service, constitutes the entire agreement regarding data processing. It supersedes all prior agreements, proposals, or representations regarding data protection.

Order of Precedence:

1. This Data Processing Agreement (DPA)
2. Terms of Service
3. Technical Documentation (TECHNICAL.md)

14. SEVERABILITY

If any provision of this DPA is found invalid or unenforceable, the remaining provisions remain in full effect. The invalid provision shall be replaced with a valid provision that most closely reflects the parties' intent.

15. NOTICES

To Controller: As specified in Controller's account settings

To Processor: Lizaveta Isayeuskaya, sole proprietorship (jednoosobowa działalność gospodarcza) ul. Leona Staniszewskiego 19a 81-603 Gdynia, Poland Email: info@webappski.com

Notice Deemed Received:

• Email: 24 hours after sending
• Physical mail: 5 business days after mailing

16. CONTACT FOR DATA PROTECTION MATTERS

Processor's Data Protection Contact: Email: info@webappski.com Subject: "DPA Inquiry - [Your Company Name]"

Response Time: 7 business days for routine inquiries, 24 hours for Data Breaches

SIGNATURES

This DPA is accepted automatically upon Service activation by Controller. Controller represents that they have authority to bind their organization to this DPA.

Controller Acceptance:

• Date: [Auto-filled upon Service activation]
• Method: Electronic acceptance via account registration

Processor: Lizaveta Isayeuskaya, sole proprietorship (jednoosobowa działalność gospodarcza) Date: [DPA Effective Date - filled upon Service activation]

APPENDICES

Appendix A: Technical and Organizational Measures

See Section 5.3 and TECHNICAL.md for detailed technical security measures.

Appendix B: Sub-processors List

Current Sub-processors (as of 2026-10-05):

| OpenAI, L.L.C. | Speech-to-text transcription (gpt-4o-mini-transcribe)
Natural language processing (OpenAI GPT models) | Voice recordings (audio), voice transcriptions (text), form field metadata (names, labels, placeholders, types, section headings and form title; at fill time also the option values of select, radio and checkbox-group fields and min/max/step/pattern constraints; no values already typed into fields, see Section 4.3) | United States | California, USA | OpenAI DPA
SCCs: Module 2 & 3 | | Google Cloud Platform (Google LLC) | Cloud infrastructure:
- Firebase Cloud Functions (compute)
- Google Cloud Logging (system logs)
- Firestore (client configs, consent receipts) | Application logs (metadata only, no transcript text), infrastructure logs (IP, timestamps, error codes), client configuration data, consent receipts | European Union (stored data); logs: global location, no EU-only guarantee | europe-central2 (Poland) for stored data; Cloud Logging: global | Google Cloud DPA
Data Processing Terms (EU regions) | | Stripe, Inc. | Payment processing:
- Subscription billing
- Invoice management
- Payment method handling | Payment method tokens, billing email, invoice data, subscription status | EU / United States | California, USA | Stripe DPA
SCCs + PCI DSS Level 1 | | Formspree | Contact form processing:
- Website contact form submissions | Name, email address, message content | United States | United States | Standard Contractual Clauses | | Google Fonts (Google LLC) | Web font delivery | IP address (implicit with HTTP requests) | Global CDN | United States | Google Privacy Policy — EU-US Data Privacy Framework |

Change Notification Mechanism:

1. 30-Day Prior Notice: Processor shall notify Controller at least 30 days before engaging a new Sub-processor or materially changing Sub-processor terms
2. Notification Method: Email to Controller's registered contact address + dashboard notification (if applicable)
3. Controller's Objection Period: 14 days from notification to raise reasonable objections
4. Termination Right: If Controller objects and no alternative solution found, Controller may terminate Services without penalty
5. Quarterly Monitoring: Processor monitors Sub-processor terms quarterly and maintains change log
6. Material Changes: See DPA Section 5.4 for definition of "Material Change"

Current as of: 2026-10-05 Last updated: 2026-10-05 Online version: https://webappski.com/en/legal/dpa

Appendix C: Standard Contractual Clauses

EU Standard Contractual Clauses (Decision 2021/914) are incorporated by reference via:

• OpenAI Data Processing Addendum
• Google Cloud Data Processing Terms

Full SCC texts available at:

• OpenAI: https://openai.com/policies/data-processing-addendum
• Google Cloud: https://cloud.google.com/terms/data-processing-addendum

END OF DATA PROCESSING AGREEMENT