Data Processing Agreement (DPA)

Between Data Controller and Data Processor

Effective Date: Upon Service Activation

PARTIES

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

• The business entity or individual that integrates AI Form Copilot 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", "AI Form Copilot"):

• Fundacja Rozwoju Przedsiębiorczości „Twój StartUp" (operating the organized business part: Artur Kuzmenka)
• Address: ul. Żurawia 6/12, office 766, 00-503 Warsaw, Poland
• VAT ID (EU): PL5213641211
• BDO: 000460502
• 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 AI Form Copilot 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: Processed in EU regions (europe-central2 / eur3)

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/legal/privacy-policy)
• 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.

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 OpenAI Whisper API)
2. Natural language to structured data mapping (via OpenAI GPT-4o-mini API)
3. Language detection and translation (via OpenAI GPT-4o-mini API)
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 OpenAI for analysis after pre-filtering):

• Field labels (e.g., "Full Name", "Email Address") - sensitive labels filtered locally before transmission
• Placeholder text (e.g., "Enter your name", "Min 8 characters")
• Field types (e.g., text, email, tel) - password/payment types excluded
• Form title from the webpage
• First 3 options from dropdown/checkbox fields (for context)
• Field structure metadata:
  • HTML tag names (e.g., "nz-select", "mat-select", "ion-datetime")
  • CSS classes (for UI library detection)
  • ARIA attributes (role, ariaHaspopup, ariaControls)
  • Data attributes (isPrivate, explicitLabel)

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)

How Field Filtering Works:

1. Local pre-filtering - Sensitive field labels are filtered locally BEFORE any transmission to OpenAI:

• Fields with types: password, credit-card-number, cvv, ssn
• Fields with labels matching denylist: "Password", "Credit Card", "CVV", "SSN", "Social Security", "IBAN", "Passport", "Driver License", "Tax ID", "Medical Record", "Health Insurance", "Religious Belief", "Political Party", "Trade Union"
• Fields marked with data-ai-private attribute

2. Only non-sensitive field metadata sent to OpenAI GPT-4o-mini for form structure analysis and badge generation
3. GPT assists with nuanced sensitivity detection for context-dependent fields (e.g., "Salary Range" may be sensitive in some forms but not others)
4. Backend applies additional hard guardrails to ensure critical fields remain excluded
5. Only verified non-sensitive fields shown to Data Subjects in the voice input interface

Data Minimization Principle (GDPR Article 5(1)(c)): By filtering sensitive labels locally, Processor sends only the minimum necessary metadata to Sub-processors. This reduces privacy risks and complies with data minimization requirements.

Exhaustiveness Note: Local denylist filtering materially reduces risk but cannot catch all variants of sensitive field labels. Controller must use data-ai-private attribute for company-specific sensitive fields not covered by the denylist.

Data Subject Impact:

• ✅ Field VALUES are NEVER sent - only non-sensitive labels and metadata
• ✅ Sensitive labels (passwords, payment, health, etc.) NEVER sent to OpenAI
• ✅ Pre-filtering happens locally in browser/backend before any external transmission
• ⚠️ 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 collected. 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)

Processor's Pre-Filtering: Processor applies local denylist filtering to exclude common Article 9 labels before transmission to OpenAI (e.g., "Medical Record", "Health Insurance", "Religious Belief", "Political Party", "Trade Union"). However, this filtering is NOT exhaustive and cannot catch all variations.

Since field labels may contain Article 9 data that bypass filtering, 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 to exclude from analysis
• 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 user identifiers collected (no cookies, no tracking)
• PII sanitization applied to error logs before storage (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/subprocessors (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 only metadata (transcript length, detected language, audio duration, error codes, HTTP status) - NO transcript text or user data 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 anonymized metrics
• Alternative Considered: 7-day retention insufficient for thorough breach investigation and debugging complex issues

OpenAI Data Retention (30 days):

• OpenAI retains data for 30 days for abuse monitoring per OpenAI API Terms
• Processor cannot override or reduce this retention period
• After 30 days, OpenAI automatically and permanently deletes data
• OpenAI does NOT use API data for model training

Audio Recordings (0 days retention):

• Audio exists ONLY in memory buffer during transcription (typically 1-5 seconds)
• Audio NEVER written to disk or logs
• Audio immediately discarded after Whisper API responds

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 PII content)
  • Consent records stored in separate Firestore collection (user-consents), not commingled with operational logs
  • 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 (Whisper API for transcription, GPT-4o-mini for field mapping)
• OpenAI acts as Sub-processor under EU Standard Contractual Clauses

2. Data Retention:

• Voice transcriptions and form metadata logged for 30 days, then automatically deleted
• OpenAI retains data for 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 filtering 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/docs/integration) 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 to exclude company-specific sensitive fields
• Educate Data Subjects NOT to speak highly sensitive information (passwords, SSN, etc.)
• 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 Limitation of Liability (Two-Tier Structure)

General Cap: Processor's aggregate liability under this DPA for all claims (except as specified below) shall not exceed €50,000 per year.

Enhanced Cap for Data Protection/Security: For breaches of GDPR Articles 28–32 obligations, Security Incidents, or Data Breaches, Processor's aggregate liability shall not exceed €100,000 per year.

Insurance: Processor shall maintain commercially reasonable professional/cyber liability insurance covering data protection claims and provide certificate upon reasonable request.

Sub-processor Liability (GDPR Article 28(4)):

Processor remains fully liable to Controller for the performance of Sub-processors' obligations under GDPR Article 28(4), as if performed by Processor itself.

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

1. Seek and pursue full recourse against such Sub-processor under back-to-back terms
2. Promptly assign to Controller any recoveries obtained from the Sub-processor, net of reasonable legal costs
3. Cooperate with Controller in pursuing claims directly against Sub-processor if Processor's recourse efforts fail

Pass-Through Remedies:

To maximize Controller's recovery in event of Sub-processor breach, Processor commits to:

• Immediate claim filing: File claim with Sub-processor within 7 days of becoming aware of breach
• Assignment of rights: Assign to Controller all rights to pursue Sub-processor directly (if Processor's efforts unsuccessful within 90 days)
• Transparent reporting: Provide Controller monthly updates on status of Sub-processor claim
• No settlement without consent: Not settle Sub-processor claims without Controller's written approval if settlement affects Controller's recovery rights
• Shared legal costs: If Controller joins Processor's claim, parties split legal costs proportionally to their respective damages

Limitation - No Third-Party Beneficiary:

Processor is NOT a third-party beneficiary of Sub-processor insurance policies and CANNOT guarantee:

• That Sub-processor maintains insurance
• Specific insurance coverage amounts
• That Controller's claim will be covered by Sub-processor insurance
• Timeline for Sub-processor insurance recovery

Controller acknowledges that recovery from Sub-processor insurance depends on Sub-processor's policy terms, which may change without notice to Processor.

Important: Processor's liability to Controller is NOT contingent on successful recourse from the Sub-processor. Under Article 28(4) GDPR, Controller may pursue claims directly against Processor for Sub-processor failures. Processor then has the right to seek recourse from the Sub-processor, but this does not reduce Processor's initial liability to Controller.

Carve-outs (NO limitation applies): The above liability caps do NOT apply to the following, to the extent permitted by applicable law:

• (i) Willful misconduct or gross negligence by Processor or its personnel
• (ii) Breach of confidentiality obligations under Section 5.2
• (iii) Infringement of third-party intellectual property rights caused by Processor
• (iv) Data Subject claims under GDPR Article 82 (to the extent such liability cannot be limited under applicable law)
• (v) Regulatory fines/penalties imposed directly on Controller due to Processor's breach of GDPR obligations
• (vi) Claims arising from unauthorized Sub-processor engagement without proper notification
• (vii) Any liability which cannot be excluded or limited under applicable EU or Member State law

These carve-outs apply only to the extent such limitations are enforceable under the governing law and GDPR.

Excluded Damages:

• Processor NOT liable for indirect, consequential, special, or punitive damages (except where arising from willful misconduct/gross negligence)
• Processor NOT liable for Data Subject's voluntary disclosure of sensitive information despite warnings
• Processor NOT liable for losses caused by Controller's failure to:
  • Obtain proper consent from Data Subjects
  • Mark Article 9 fields with data-ai-private attribute
  • Educate Data Subjects about appropriate voice input usage
  • Respond timely to Data Subject requests

8.3 Indemnification by Controller

Controller shall indemnify, defend, and hold harmless Processor from and against all claims, damages, losses, liabilities, costs, and expenses (including reasonable legal fees) arising from:

1. GDPR Violations by Controller:

• Inadequate or absent consent from Data Subjects for voice input processing
• Failure to provide Privacy Policy or required transparency notices to Data Subjects
• Inadequate parental consent for minors under 16 (GDPR Article 8)
• Unlawful processing instructions issued to Processor

2. Article 9 Special Categories Violations:

• Processing Article 9 data without explicit consent: If Controller's forms contain Article 9 field labels (health, political opinions, religious beliefs, ethnic origin, sexual orientation, trade union membership, genetic data, biometric data) and Controller fails to:
  • Mark Article 9 fields with data-ai-private attribute
  • Obtain separate explicit consent for Article 9 processing
  • Conduct required Data Protection Impact Assessment (DPIA) per Article 35
  • Implement additional safeguards per Article 9(2)
• Reliance on Processor's filtering: Controller acknowledges that Processor's local denylist filtering is NOT exhaustive and cannot catch all Article 9 field label variations. Controller bears responsibility for identifying and marking company-specific Article 9 fields.
• Shared liability: If GDPR Article 82 claim arises from Article 9 violation where Controller failed to use data-ai-private, Controller shall reimburse Processor for any damages, fines, or legal costs paid by Processor (net of Processor's contributory fault, if any)

3. Data Subject Misuse:

• Claims arising from Data Subject voluntarily speaking sensitive information (passwords, payment data, government IDs, health data) despite:
  • Processor's warnings in widget UI
  • Controller's obligation to educate users
  • Processor's reasonable technical safeguards (sensitivity detection)

4. Failure to Respond to Data Subject Requests:

• Controller's failure to respond timely to Data Subject requests (access, erasure, rectification, objection)
• Controller's refusal to forward Data Subject requests to Processor within required timeframes

5. Controller's Own GDPR Violations:

• Use of Service in violation of GDPR Article 6 (no lawful basis)
• Failure to notify Supervisory Authority of breach within 72 hours (Article 33)
• Failure to notify Data Subjects of high-risk breach (Article 34)
• Processing Special Categories data without Article 9(2) lawful exception

Indemnification Process:

1. Processor shall notify Controller within 7 days of becoming aware of claim
2. Controller may assume defense of claim (at Controller's expense) with competent counsel
3. Processor shall reasonably cooperate with Controller's defense
4. Controller shall not settle claim without Processor's written consent if settlement imposes obligations on Processor or admits Processor's fault

Limitation: Controller's indemnification obligation does NOT apply to extent Processor's own negligence, willful misconduct, or breach of this DPA contributed to the claim. In such cases, parties bear liability proportionally to their respective fault.

8.4 Indemnification by Processor

Processor shall indemnify Controller for:

• Claims arising from Processor's breach of this DPA
• Claims arising from Processor's negligent security practices
• Claims arising from unauthorized Sub-processor engagement

8.5 Insurance and Financial Capacity

Entity Structure and Risk Allocation:

Processor (Fundacja Rozwoju Przedsiębiorczości „Twój StartUp") operates through Artur Kuzmenka as an Individual Entrepreneur (Polish: Indywidualny Przedsiębiorca), which differs from a limited liability company in the following ways:

• Personal assets may be at risk for judgments exceeding available insurance
• Financial capacity is limited compared to venture-backed corporations
• Liability caps and insurance requirements reflect realistic capacity of individual entrepreneur

Controllers acknowledge this structure and the following considerations:

1. Limited Personal Assets:

• Personal assets at risk for judgments exceeding liability caps and insurance
• No corporate veil protection (sole proprietor structure)
• Annual aggregate cap €200,000 (all Controllers combined) prevents bankruptcy but limits recovery

2. Insurance May Be Unavailable During Startup (Years 1-2):

• Processor may not maintain insurance if annual revenue <€50,000
• If no insurance: Controllers rely on (a) liability caps, (b) Sub-processor insurance, (c) Processor's personal assets
• Cyber insurance for startups: €1,500-3,000/year for €50K-100K coverage (only affordable at scale)

3. Risk Assessment for Controllers:

LOW RISK (probably acceptable without Processor insurance):

• Small websites: <10,000 users/month
• Non-sensitive forms: contact forms, newsletter signups, surveys
• Limited Personal Data: names, emails only
• No Article 9 data (health, political, religious, etc.)
• Recommendation: Proceed with integration, monitor Processor insurance status annually

MEDIUM RISK (consider Controller insurance):

• Medium websites: 10,000-100,000 users/month
• Some sensitive data: phone numbers, addresses, demographics
• Business-critical forms: lead generation, customer onboarding
• Limited Article 9 data (with proper safeguards)
• Recommendation: Obtain cyber insurance covering service provider risks (adds €500-2,000/year to premium), OR wait until Processor obtains €50K insurance

HIGH RISK (Processor insurance STRONGLY RECOMMENDED or use alternative vendor):

• Large websites: >100,000 users/month
• Highly sensitive data: financial, medical, government IDs
• Regulated industries: healthcare (HIPAA), finance (PCI-DSS), government
• Significant Article 9 data processing
• Recommendation:
  • (a) Wait until Processor obtains €100K+ insurance (revenue €100K+), OR
  • (b) Add Processor as "additional insured" on Controller's cyber policy, OR
  • (c) Use larger vendor with guaranteed insurance (at higher cost), OR
  • (d) Self-host open-source version (if available)

4. Controllers' Risk Mitigation Options:

Option A: Obtain Controller Cyber Insurance

• Add "service provider risk" rider to existing cyber policy
• Typical cost: €500-2,000/year (depends on Controller's revenue)
• Coverage: €100K-500K for service provider breaches
• Add Processor as "additional insured" (primary coverage)

Option B: Escrow/Reserve Fund Requirement

• Negotiate with Processor to maintain €20K-50K reserve fund
• Fund verified annually via bank attestation
• Gives Controller priority claim in event of breach

Option C: Mutual Insurance Requirement

• Both parties obtain cyber insurance (if economically feasible)
• Each party as "additional insured" on other's policy
• Reduces overall risk for both parties

Option D: Delayed Integration

• Wait until Processor reaches revenue milestone (€50K-100K)
• Processor commits to notifying Controllers when insurance obtained
• No penalty for delayed integration due to insurance concerns

5. Sub-processor Insurance (Partial Mitigation):

Processor relies on Sub-processors (Google Cloud Platform, OpenAI) maintaining enterprise-grade cyber liability insurance. While specific coverage amounts are not publicly disclosed, these major providers maintain substantial cyber insurance policies appropriate for their scale of operations.

What this means:

• If breach caused by Google Cloud or OpenAI → Processor can pursue claims against Sub-processor's insurance
• Recovery rights assigned to Controller (net of legal costs)
• Provides additional protection layer beyond Processor's direct coverage
• For current information: Refer to Google Cloud's Trust Center and OpenAI's Security Portal

Limitation: Sub-processor insurance does NOT cover Processor's own negligence (e.g., weak API key management, failure to sanitize logs)

6. Transparency and Monitoring:

Processor commits to:

• Disclose current insurance status within 14 days of Controller request (any time, no penalty)
• Notify all Controllers within 30 days of obtaining or materially changing insurance
• Provide certificate of insurance upon reasonable request
• Allow Controllers to terminate without penalty if insurance requirements not met

7. Acknowledgment:

By accepting this DPA, Controller acknowledges:

• Controller understands Processor is sole proprietor with limited insurance during startup phase
• Controller has assessed the risk profile of their use case (low/medium/high risk)
• Controller accepts the risks or has obtained appropriate mitigation (e.g., Controller insurance)
• Controller may terminate Services without penalty if Processor fails to obtain insurance within agreed timeline (if negotiated)

8.5.1 Insurance Coverage (Aspirational)

Processor shall use commercially reasonable efforts to obtain and maintain professional liability insurance (E&O) and cyber liability insurance as the business scales. Insurance details:

Target Coverage:

• Professional Liability (E&O): €100,000 per claim / €200,000 aggregate (aspirational)
• Cyber Liability: €100,000 per claim / €200,000 aggregate (aspirational)

Current Coverage:

• Available upon reasonable request by Controller (email info@webappski.com, Subject: "Insurance Certificate Request")
• Processor shall disclose current coverage amounts (if any) within 14 days of request

No Guarantee:

• Insurance is aspirational based on Processor's business size, revenue, and available capital
• Processor (sole proprietor/individual entrepreneur) is not obligated to maintain specific coverage amounts
• Insurance capacity is limited by business revenue and underwriting availability

Sub-processor Insurance (Additional Protection Layer):

Processor relies on Sub-processors (Google Cloud Platform, OpenAI) maintaining enterprise-grade cyber liability insurance. While specific coverage amounts are not publicly disclosed, these major providers maintain substantial cyber insurance policies appropriate for their scale of operations.

⚠️ CRITICAL DISCLAIMER - No Third-Party Beneficiary Rights:

Processor is NOT a third-party beneficiary of Sub-processor insurance policies. This means:

• No direct claims: Controller CANNOT directly claim against Google Cloud or OpenAI insurance policies
• No guarantee of coverage: Processor CANNOT guarantee that Sub-processor maintains insurance or that specific claims will be covered
• No control over terms: Sub-processor insurance terms may change without notice to Processor
• No verification rights: Processor has no right to inspect, verify, or audit Sub-processor insurance policies
• Reliance on public information: Controller relies on publicly available information from Sub-processors' Trust Centers/Security Portals

What this means practically:

• Controller's recovery path: Controller → Processor → Sub-processor (via Processor's DPA with Sub-processor)
• Controller CANNOT bypass Processor to claim directly from Sub-processor's insurer
• Processor's obligation under GDPR Art. 28(4) remains: Processor is initially liable to Controller, then seeks recourse from Sub-processor
• See Section 8.2 "Pass-Through Remedies" for detailed recovery mechanism

For current public information:

• Google Cloud: Trust Center
• OpenAI: Security Portal

Controller acknowledges:

• Recovery from Sub-processor insurance depends on Sub-processor's policy terms
• Processor will pursue Sub-processor claims diligently but cannot guarantee successful recovery
• See Section 8.2 for Processor's commitments on pass-through remedies and assignment of recovery rights

Limitations:

• Insurance coverage (if any) does NOT increase or waive the liability caps in Section 8.2
• Insurance is maintained for risk management purposes only
• Controller cannot directly claim against Processor's insurance policy (no third-party beneficiary rights)
• Sub-processor insurance does NOT cover Processor's own negligence (e.g., weak API key management, failure to sanitize logs)

8.5.2 Annual Aggregate Cap (All Controllers Combined)

Sole Proprietor Protection:

Given Processor's status as sole proprietor (individual entrepreneur) with limited personal assets, Processor's total aggregate liability to ALL Controllers combined shall not exceed €200,000 per calendar year, regardless of:

• Number of incidents or breaches
• Number of Controllers affected
• Number of Data Subjects affected
• Legal theory (contract, tort, GDPR Article 82, etc.)

IMPORTANT: This annual aggregate cap applies to claims between Controllers and Processor only. It does NOT limit Data Subjects' rights to compensation under GDPR Article 82 (see Section 8.2 Carve-outs).

Rationale:

• Processor (Fundacja Rozwoju Przedsiębiorczości „Twój StartUp") operates through Artur Kuzmenka, Individual Entrepreneur (not a limited liability company)
• Personal assets are at risk in event of judgment exceeding available insurance
• €200,000 annual aggregate cap reflects realistic financial capacity of sole proprietor with startup business
• Cap necessary to prevent bankruptcy from single catastrophic incident (e.g., Google Cloud breach affecting all clients)

Allocation Among Controllers:

If aggregate claims in a calendar year exceed €200,000:

1. Priority: Claims paid in order received (first-in, first-paid) until cap exhausted
2. Proportional reduction: If multiple claims arise simultaneously (e.g., same breach affecting multiple Controllers), compensation allocated proportionally:

• Formula: (Controller's claim amount / Total claims amount) × €200,000
• Example: Controller A claims €100K, Controller B claims €150K, Total €250K → Controller A receives €80K (100/250 × 200), Controller B receives €120K (150/250 × 200)

Notice to Controllers:

• Processor shall notify all affected Controllers within 7 days if annual aggregate cap is reached or expected to be reached
• Notification includes: total claims amount, allocation method, expected payment timeline
• Controllers may then pursue additional recovery from Sub-processors (Google Cloud, OpenAI) if breach caused by Sub-processor

Cap Resets:

• Annual aggregate cap resets on January 1 each calendar year
• Prior year's claims do not carry over or reduce subsequent year's cap

Carve-outs (NO annual aggregate cap applies):

The €200,000 annual aggregate cap does NOT apply to:

1. Willful misconduct or fraud by Processor (unlimited liability)
2. Gross negligence by Processor (unlimited liability)
3. Criminal activity by Processor (unlimited liability)
4. Infringement of third-party intellectual property rights caused by Processor (unlimited liability)
5. Breach of confidentiality obligations (Section 5.2) where Processor intentionally disclosed Personal Data (unlimited liability)

For these carve-outs, Processor's liability is subject only to Section 8.2 caps (€50K general / €100K enhanced), NOT the €200K annual aggregate cap.

8.5.3 Alternatives to Insurance (Risk Mitigation)

If Processor does not maintain insurance at target levels, Processor may use the following alternative risk mitigation measures:

Option 1: Reserve Fund (Escrow)

• Processor may establish and maintain a reserve fund of minimum €20,000 (increasing to €50,000 as revenue grows)
• Fund held in separate business bank account, not commingled with operating funds
• Fund used exclusively for breach response, legal defense, and Data Subject compensation
• Controller may request annual attestation of reserve fund balance

Option 2: Pass-through Sub-processor Insurance

• Processor maintains contractual right to claim against Sub-processor insurance (Google Cloud, OpenAI)
• In event of Sub-processor breach, Processor shall:
  1. Immediately file claim with Sub-processor insurance
  2. Assign recovery rights to Controller (net of legal costs)
  3. Cooperate with Controller in pursuing Sub-processor liability

Option 3: Mutual Indemnification Cap

• If insurance unavailable, Processor and Controller may negotiate mutual indemnification cap
• Example: Controller agrees to indemnify Processor for Controller's failures (Article 9, consent) up to €50K; Processor indemnifies Controller for Processor's failures up to €50K
• Mutual cap must be documented in writing as amendment to this DPA

Option 4: Third-Party Liability Limitation

• Controller may obtain cyber liability insurance covering Processor as "additional insured"
• Controller's insurance becomes primary coverage; Processor's insurance (if any) becomes secondary
• Controller receives premium discount from insurer (typical 10-20% reduction) due to service provider coverage

8.5.4 Insurance Updates and Scaling

As Business Grows:

Processor commits to increasing insurance coverage as revenue grows:

Notification:

• Processor shall notify all Controllers within 30 days of obtaining or materially changing insurance coverage
• Notification includes: coverage amounts, carrier name, policy period
• Certificate of insurance provided upon request (within 14 days)

Annual Review:

• Processor shall review insurance needs annually (each January)
• Processor shall solicit quotes from at least 2 insurance carriers if revenue exceeds €50K
• If insurance premiums exceed 5% of annual revenue, Processor may defer coverage increase (notify Controllers)

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

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 Gdynia, 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/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: [NAME] Staniszewskiego 19b 81-303 Gdynia, Poland Fundacja Rozwoju Przedsiębiorczości „Twój StartUp" (Artur Kuzmenka) ul. Żurawia 6/12, office 766 00-503 Warsaw, 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: Fundacja Rozwoju Przedsiębiorczości „Twój StartUp" (Artur Kuzmenka, Individual Entrepreneur) 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 2025-11-12):

| OpenAI, L.L.C. | Speech-to-text transcription (Whisper API)
Natural language processing (GPT-4o-mini API) | Voice recordings (audio), voice transcriptions (text), form field metadata (non-sensitive labels, placeholders, types only) | 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 | europe-central2 (Poland) / eur3 (multi-region) | Google Cloud DPA
Data Processing Terms (EU regions) |

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: 2025-11-12 Last updated: 2025-11-12 Online version: https://webappski.com/subprocessors

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