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"):

• [NAME], Individual Entrepreneur
• Address: Staniszewskiego 19b, 81-303 Gdynia, Poland
• NIP: --------
• 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 Joint Controllership for Infrastructure Security Logs (GDPR Article 26)

For infrastructure security logging strictly necessary for providing the Service, Controller and Processor act as Joint Controllers under GDPR Article 26.

Rationale for Joint Controllership:

• Security logging is inextricably linked to the provision of voice processing services (CJEU Fashion ID C-40/17)
• Both parties benefit from infrastructure security: Controller needs reliable service, Processor needs operational stability
• Both parties jointly determine the essential purpose (service provision with security) and essential means (security logging via Google Cloud Platform)

Scope of Joint Controller Processing:

• Infrastructure security logs: IP addresses, request timestamps, HTTP status codes, User Agent, request duration
• Purpose: DDoS protection, abuse detection, rate limiting, debugging production errors
• Legal basis: Legitimate interests (GDPR Article 6(1)(f)) for network and information security (Recital 49)
• Retention: Maximum 30 days, then automatic deletion
• Processing location: Google Cloud Platform (us-central1 region)

Allocation of GDPR Obligations (Article 26(1)):

See Appendix D: Joint Controller Agreement for detailed allocation of responsibilities.

Summary of Allocation:

Data Subject Contact Point (Article 26(2)):

• Data Subjects may contact either Processor or Controller regarding security logs
• Primary contact: Processor (info@webappski.com, Subject: "Security Logs - GDPR Request")
• If Data Subject contacts Controller, Controller shall forward request to Processor within 48 hours

Essence of Arrangement (Article 26(2)): The essence of this joint controller arrangement and the allocation of responsibilities is made available to Data Subjects via:

• Processor's Privacy Policy (https://webappski.com/legal/privacy-policy)
• This DPA Appendix D (provided to Controller, who may share with Data Subjects upon request)

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
• Page URL where the form is located
• User Agent (browser type and version)
• 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)

Technical Data:

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

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

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
• See Appendix D Section 4 for detailed fault allocation between Processor and Sub-processors

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 sanitized textual artifacts (voice transcriptions, extracted form data) with automatic PII redaction
  • Sanitization patterns: Emails, phone numbers, credit cards, IBAN, API keys, JWT tokens, names, addresses are automatically redacted before storage
  • 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
• 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
• Deleted within 30 days of Service termination

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.

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: 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 operates as [NAME], 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 operates as [NAME], 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 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: [NAME] Individual Entrepreneur Date: [DPA Effective Date]

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 [DATE]):

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: [DATE] Last updated: [DATE] 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

Appendix D: Joint Controller Agreement (GDPR Article 26)

Purpose: This Appendix defines the allocation of GDPR obligations between Controller and Processor for infrastructure security logging as required by GDPR Article 26(1).

Scope: This agreement applies ONLY to infrastructure security logs (IP addresses, request timestamps, HTTP status codes, User Agent, request duration). For all other processing (voice transcriptions, form metadata), Processor acts solely as a Processor under Controller's instructions (see DPA Section 3.2).

1. Rationale for Joint Controllership

Legal Basis:

• CJEU Fashion ID (C-40/17) establishes that joint controllership exists where processing is "inextricably linked" to service provision
• Security logging is technically necessary for operating Cloud Run infrastructure and cannot be disabled
• Both parties benefit: Controller needs reliable service; Processor needs operational stability
• Both parties jointly determine essential purpose (service provision with security) and means (Google Cloud Platform logging)

Technical Architecture:

• Firebase Cloud Functions Gen2 runs on Google Cloud Run
• Cloud Run automatically logs httpRequest.remoteIp, timestamps, status codes, User Agent
• These logs enable DDoS protection, rate limiting, abuse detection, error debugging
• Logs are not used for tracking, profiling, or marketing

2. Joint Processing Details

Categories of Data:

• IP addresses (infrastructure logs only, transient processing)
• Request timestamps (date/time of API call)
• HTTP status codes (200 OK, 429 Rate Limit, 500 Error, etc.)
• User Agent strings (browser type and version)
• Request duration (milliseconds)
• API endpoint accessed (e.g., /complete, /transcribe)

Purpose:

• DDoS protection and abuse detection
• Rate limiting enforcement
• Infrastructure performance monitoring
• Production error debugging
• Security incident investigation

Legal Basis:

• GDPR Article 6(1)(f) - Legitimate interests for network and information security
• GDPR Recital 49 - Processing necessary for ensuring network security

Retention:

• Maximum 30 days, then automatic deletion by Google Cloud Platform
• No extension beyond 30 days except for litigation hold (EU/Member State law requirement)

Processing Location:

• Google Cloud Platform us-central1 region (United States)
• Protected by EU Standard Contractual Clauses (Google Cloud DPA)

Data Subjects:

• End users of Controller's website who interact with AI Form Copilot widget

3. Detailed Allocation of GDPR Obligations

4. Internal Arrangements Between Parties

Communication Channels:

• Routine matters: Email (info@webappski.com for Processor)
• Urgent matters (breaches): Email + phone if available
• Response times:
  • Breach notification: 24h preliminary, 48h detailed
  • Data Subject requests: 7 business days
  • Routine inquiries: 14 days

Cost Allocation:

• Processor bears costs: Infrastructure (Google Cloud), technical implementation, routine Data Subject requests (first 2 hours)
• Controller bears costs: Legal advice, regulatory filings, complex Data Subject requests (>2 hours of Processor time)
• Shared costs: DPIA reviews (if joint DPIA conducted), legal defense (proportional to fault under Art. 82)

Liability Allocation (GDPR Article 82):

• Joint and several liability: Data Subjects may pursue either or both parties for full damages under Art. 82(4)
• Internal recourse: Party that pays damages beyond their responsibility may seek recourse from the other party based on fault allocation
• Fault presumption:
  • Processor presumed responsible for: application-level security breaches (e.g., bugs in Processor's code, misconfigured access controls, failed PII sanitization, weak API key management)
  • Sub-processor (Google Cloud) presumed responsible for: infrastructure failures (e.g., unauthorized access to Cloud Run, Google Cloud data center breach, Cloud Logging security violations)
  • Sub-processor (OpenAI) presumed responsible for: API processing failures (e.g., unauthorized access to Whisper/GPT data, retention policy violations, OpenAI data breach)
  • Controller presumed responsible for: inadequate transparency or consent (Art. 13-14 violations), failure to mark Article 9 fields with data-ai-private
  • Both parties share responsibility for: delayed breach notification (Art. 33-34)

Burden of Proof (Shifting Presumption):

Where a breach originates from Sub-processor infrastructure or services, Processor may rebut the presumption of fault by demonstrating:

1. Processor's code/configuration was compliant with security best practices and GDPR requirements at the time of breach
2. Breach occurred at Sub-processor level (e.g., Google Cloud infrastructure breach, OpenAI API breach) based on:

• Sub-processor breach notification to Processor
• Technical evidence (logs, audit trails) showing breach origin
• Independent security audit confirming Processor's systems were not compromised

3. Processor acted promptly upon discovering the breach (notified Controller within 24h, implemented mitigation)

Recourse Mechanism:

If Processor successfully demonstrates Sub-processor fault:

• Controller's primary recourse shifts to Processor pursuing Sub-processor's insurance/liability
• Processor shall immediately file claim with Sub-processor under back-to-back DPA terms
• Processor shall assign recovery rights to Controller (net of reasonable legal costs)
• Controller may join Processor's claim against Sub-processor to maximize recovery

Important: Under GDPR Art. 28(4), Processor remains initially liable to Controller regardless of fault origin. This fault allocation mechanism only determines internal recourse and cost-bearing between parties after Controller is compensated.

Dispute Resolution:

• If parties disagree on responsibility allocation, escalate to senior management within 5 business days
• If no resolution, parties may seek mediation before Polish arbitration institution (agreed mediator)
• Disputes do NOT delay Data Subject response deadlines; party receiving request responds provisionally while disputes resolve

5. Data Subject Contact Points (Article 26(2))

Primary Contact: Processor

• Email: info@webappski.com
• Subject line: "Security Logs - GDPR Request - [Request Type]"
• Response time: 30 days (Art. 15), 7 days for deletion (Art. 17)

Secondary Contact: Controller

• If Data Subject contacts Controller first, Controller forwards to Processor within 48 hours
• Controller provides Processor's contact details to Data Subject

Transparent Availability:

• This arrangement published in Processor's Privacy Policy (§2.3 and §13)
• This DPA Appendix D provided to Controller (who may share with Data Subjects upon request)
• Data Subjects informed of joint controllership before first use of widget

6. Essence of Arrangement (Article 26(2) Public Disclosure)

What Data Subjects Need to Know:

"For infrastructure security logging necessary to operate the AI Form Copilot service, [NAME] (Processor) and your website operator (Controller) act as Joint Controllers under GDPR Article 26.

What is logged: IP addresses, timestamps, request types, error codes - used for DDoS protection, rate limiting, and debugging.

Retention: 30 days maximum, then automatic deletion.

Your rights: You may contact either the Processor (info@webappski.com) or your website operator to exercise GDPR rights (access, erasure, objection).

Primary contact for security logs: info@webappski.com (Subject: 'Security Logs - GDPR Request')

Legal basis: Legitimate interests (GDPR Article 6(1)(f)) for network security (Recital 49).

Note: For voice transcriptions and form data processing, the Processor acts solely as a Processor on your website operator's instructions."

7. Review and Amendment

Annual Review:

• Parties shall review this arrangement annually to assess:
  • Whether joint controllership rationale still applies
  • Whether technical changes enable independent processing
  • Whether allocation remains appropriate

Amendment Process:

• Either party may propose amendments by email with 30 days' notice
• Amendments require mutual written agreement
• If GDPR or Supervisory Authority guidance changes, Processor may amend with 14 days' notice (Controller may terminate if objects)

Termination of Joint Controllership:

• If technical architecture changes allow independent processing, Processor shall notify Controller
• If either party determines joint controllership no longer accurate, parties negotiate revised arrangement within 30 days
• If no agreement, Controller may terminate Services without penalty

8. Supervisory Authority Contact

Lead Supervisory Authority (Processor): Urząd Ochrony Danych Osobowych (UODO) ul. Stawki 2, 00-193 Warsaw, Poland Website: https://uodo.gov.pl/ Email: kancelaria@uodo.gov.pl

Controller's Supervisory Authority: As determined by Controller's establishment location (GDPR Art. 55-56)

If UODO or Controller's Supervisory Authority requests information:

• Receiving party notifies other party within 24 hours
• Both parties cooperate fully with investigation
• Each party provides information within their responsibility scope (per allocation table above)

Last updated: [DATE] Effective: Upon Service activation Version: 1.0 (aligned with DPA §3.4)

END OF DATA PROCESSING AGREEMENT