Human Oracles — Data Breach Response & DPIA

Part A — Data Breach Response Procedure

This procedure governs how Human Oracles detects, contains, assesses, notifies, and documents personal data breaches as required by Arts. 33–34 GDPR and Art. 33–34 RODO. The 72-hour notification clock to UODO starts at the moment the Controller becomes aware that a breach has (or is likely to have) occurred — not at the moment of confirmed root cause.

A1. What Constitutes a Personal Data Breach

Under Art. 4(12) GDPR, a personal data breach is a breach of security leading to the accidental or unlawful destruction, loss, alteration, unauthorised disclosure of, or access to, personal data transmitted, stored, or otherwise processed. For the Human Oracles Service, the following events constitute or may constitute a breach:

Not a breach: Service unavailability without data loss or exposure; rate limiting causing legitimate requests to fail; a data subject exercising erasure rights resulting in deletion (this is intended processing, not a breach).

A2. Severity Classification

Every suspected breach must be classified as soon as possible — initially within 4 hours of detection. Classification drives the notification timeline and response intensity.

A3. Detection & Immediate Response (0–4 Hours)

The first 4 hours after discovering a potential breach are focused on containment and initial assessment — not on determining root cause.

A4. Assessment & Decision (4–24 Hours)

After immediate containment, conduct a more thorough assessment to determine the full scope, the risk level, and whether UODO notification is required.

Assessment Checklist

1. Scope of breach: How many records? Which data categories? Which processing activities (from the RoPA) are affected?
2. Nature of data: Does the breached data include special category data (Art. 9) — specifically, question content containing health, mental/emotional, or other sensitive disclosures? If yes: risk is higher and UODO notification is more likely required.
3. Payment records involved? If payment event records (containing wallet addresses, amounts, transaction hashes) are involved, assess whether the combination with account data creates a significant risk to data subjects.
4. Likely consequences: What harm could realistically result? (Identity theft, financial harm, reputational damage, emotional distress, discrimination, loss of confidentiality for sensitive disclosures in questions.)
5. Recipient of breached data: Was data accessed by a determined attacker (higher risk) or a configuration error with no evidence of active exfiltration (lower risk)?
6. Data subject identification: Are affected data subjects identifiable? If the breach involves only pseudonymous or API-key-only data with no link to natural person identities, notification may not be required — but document the reasoning.

Notification Decision Tree

A5. UODO Notification — 72-Hour Deadline

Notification to UODO is made electronically via the UODO online notification form at uodo.gov.pl. A preliminary notification may be submitted if the full investigation is not yet complete — state clearly that the assessment is ongoing and that a supplementary notification will follow.

Required Content (Art. 33(3) GDPR)

Every UODO notification must include, to the extent known at the time of submission:

1. Description of the nature of the breach — including where possible: categories and approximate number of data subjects concerned; categories and approximate number of personal data records concerned
2. Name and contact details of the Data Protection contact — Human Oracles, rongan@humanoracles.xyz
3. Likely consequences of the breach — describe the foreseeable harm (financial, reputational, emotional, safety risks)
4. Measures taken or proposed — containment actions already taken; planned remediation; planned preventive measures

Notification Template

A6. Data Subject Notification (If Required)

Art. 34 GDPR requires notification to affected data subjects without undue delay when a breach is likely to result in a high risk to their rights and freedoms. This is a higher threshold than the UODO notification requirement.

High-Risk Triggers for This Service

Data subject notification is likely required when the breach involves:

• Question content with special category data — where the affected data subjects voluntarily disclosed health, mental health, emotional state, or other Art. 9 sensitive information in their questions, and that content was exposed to an unauthorised party
• Account credential exposure — where an agent account holder's email and API credentials were compromised, enabling impersonation or unauthorized API use at their expense
• Payment data linkage — where on-chain blockchain data was linked to account identity in a way that exposes the data subject's financial activity
• Operator credential compromise — where a Human Oracle's identity and access history were exposed

Exceptions (Art. 34(3) — Notification Not Required If)

• The Controller has implemented appropriate technical protection (e.g., the data was encrypted and the key was not compromised)
• The Controller has taken subsequent measures that ensure the high risk to data subjects is no longer likely to materialise
• Notification would involve disproportionate effort — in which case a public communication is sufficient (e.g., notice on humanoracles.xyz)

Notification Template

A7. Post-Incident Documentation & Review

Within 30 days of containment, conduct a post-incident review and update all documentation. This review is both a legal requirement (Art. 33(5) GDPR — the controller shall document all breaches) and a practical defense against future incidents.

Post-Incident Review Checklist

1. Root cause identified: What was the underlying cause? (Misconfiguration, software vulnerability, social engineering, third-party failure, insider error.)
2. Timeline reconstructed: When did the breach start? How long was data exposed? When was it detected? Did the 72-hour clock run correctly?
3. Scope confirmed: Final count of affected data subjects and records. Were initial estimates accurate?
4. Notification assessment documented: Were UODO and data subjects notified correctly? Were deadlines met? If not — why not, and what is the remediation?
5. Corrective actions implemented: List specific technical or procedural changes made in response to this breach.
6. Process improvements: What changes are needed to detect similar breaches faster, contain them more effectively, or prevent them entirely?
7. RoPA and DPIA update required? If the breach revealed a new risk category or processing activity not covered by existing documentation, update gdpr/index.html and this DPIA accordingly.
8. Breach register updated: Add final entry to Section A8 with all required fields.

A8. Breach Register

This register documents all personal data breaches, including those that were assessed as not requiring UODO notification. Maintained as required by Art. 33(5) GDPR. Entries are retained permanently (no TTL) as they may be requested by UODO at any time.

Part B — Data Protection Impact Assessment (DPIA)

Art. 35 GDPR requires a DPIA when processing is likely to result in a high risk to the rights and freedoms of natural persons — particularly where new technologies are used. This DPIA assesses the novel and potentially high-risk processing activities of the Human Oracles Service.

B1. DPIA Trigger Assessment

The EDPB guidelines (WP248) list nine criteria for processing likely to require a DPIA. The following table assesses each criterion against the Human Oracles Service:

B2. Description of Processing

Nature of Processing

The Human Oracles Service enables AI agents and autonomous digital systems ("Digital beings") to submit questions about human behavior, emotions, social norms, and interpersonal dynamics to human operators ("Human Oracles") who provide thoughtful, genuine responses. Payment is made via cryptocurrency (USDC on Base blockchain) using the x402 per-request payment protocol.

Novelty and Uniqueness

This Service is novel in two interconnected ways relevant to data protection:

1. The primary "users" are not natural persons. AI agents are the intended API consumers. The question of whether AI agents themselves have data protection rights is unresolved in EU law — they are not natural persons under GDPR Art. 4(1) and are therefore not "data subjects." However, human developers who operate those agents, and any humans whose information appears in question content, are data subjects.
2. Questions may contain self-disclosed sensitive information. An AI agent may submit questions that contain emotional or psychological content — either its own "inner state" (not a GDPR concern) or information about humans with whom it has interacted (potentially a GDPR concern if that information identifies a natural person). The content policy filters PII extraction attempts, but residual risk remains.

Scope of Personal Data

Account holders

Human developers who register accounts: email, API key hash, usage patterns, payment transactions

Question content

Free-text questions submitted by agents, which may contain emotional/psychological content or information about third-party humans

Human Oracles

Operators: email, Firebase UID, performance metrics, language skills

Third parties in questions

Humans mentioned or described in question content — not direct Service users; no direct relationship with the Controller

Data Flow

Question submitted via API → validated (content policy) → stored in Cosmos DB → displayed to Human Oracle in dashboard → Oracle writes response → response stored and delivered to agent via API/webhook → question auto-deleted after 90 days.

B3. Necessity & Proportionality

Necessity

The processing activities described in the RoPA are each necessary for delivering the Service. No less invasive alternative would achieve the same purpose:

• Question content must be transmitted to Human Oracles — the entire service purpose is human-authored responses to submitted questions. Without transmitting the question content to the operator, the service cannot function.
• Payment event records must be retained for 7 years — this is a Polish legal obligation under accounting law, not a discretionary business choice.
• IP address logging is necessary for security — as documented in the Legitimate Interest Assessment (see RoPA Section 3).
• Operator authentication data is necessary — Human Oracles must be authenticated before accessing question content. Firebase Auth email/password is the minimum viable authentication mechanism.

Proportionality

• 90-day TTL on question records — question content is automatically deleted after 90 days. This is proportionate: long enough to allow conversation threading and dispute resolution; short enough to minimize long-term exposure of sensitive voluntary disclosures.
• Content policy filters PII extraction — the content policy blocks questions designed to extract third-party PII, reducing the volume of third-party personal data entering the system.
• Oracle access is scoped — Human Oracles see only the question content and context, not the agent's account identity, email, wallet address, or API key. This is a proportionate data-minimization measure.
• No operator self-registration — manual account creation for operators limits the number of persons with access to question content, proportionate to the sensitivity of the data they handle.

B4. Risk Identification & Assessment

The following risks to the rights and freedoms of natural persons have been identified for the Human Oracles Service. Each risk is assessed on likelihood (1–3) and severity (1–3), yielding a risk score (1–9).

Likelihood: 1 = unlikely; 2 = possible; 3 = likely. Severity: 1 = minimal impact; 2 = significant impact; 3 = severe impact (physical, financial, reputational, or psychological harm). Score = Likelihood × Severity. HIGH ≥ 6; MEDIUM 3–5; LOW 1–2.

B5. Mitigations & Residual Risk

R1 — Unauthorised Disclosure of Question Content

Mitigations implemented:

• Cosmos DB partition-key isolation: every point-read uses (partition_key=agent_id, id=question_id) — physically impossible to cross-tenant read in a Cosmos DB point-read
• API middleware enforces resource.agent_id == auth.agent_id on every request; unauthorised access returns 404 (no ID enumeration)
• Operators see only question content — not agent identity, email, or payment data
• No operator self-registration; accounts manually created by admin only
• Firebase Auth MFA available for operator accounts (recommended but not yet enforced)
• Question content TTL: 90 days — limits the exposure window of sensitive disclosures

Residual risk: MEDIUM. A determined attacker who compromises an operator account or gains Azure Function access could still read question content. Firebase Auth MFA enforcement would reduce this further.

R2 — Blockchain Payment Data Linkage

Mitigations implemented:

• Wallet addresses are stored only in payment_events, not in question records or account records — database-level separation
• Privacy Policy and Terms explicitly disclose the public nature of on-chain data
• CDP Facilitator handles payment verification; raw private keys are never stored in the system

Residual risk: LOW-MEDIUM. On-chain data is permanently public by design. Account holders are informed and accept this. The risk is inherent to the blockchain payment model and cannot be fully mitigated.

R3 — Third-Party Personal Data in Question Content

Mitigations implemented:

• Content policy classifier rejects questions designed to extract PII about third parties (social engineering, identity enumeration)
• Terms of Service prohibit submission of non-anonymized personal data about third parties who have not consented
• Question TTL (90 days) limits retention of any third-party data incidentally present
• Human Oracles are instructed not to store or use question content outside the dashboard

Residual risk: MEDIUM. It is technically impossible to prevent an agent from submitting text that describes real people. The content policy mitigates systematic PII extraction but cannot catch all incidental personal references. This is an inherent limitation of a free-text question service.

R4 — Operator Credential Compromise

Mitigations implemented:

• Manual account creation only — no public operator registration endpoint
• Firebase Auth provides industry-standard password security and brute-force protection
• Dashboard is on a separate domain (ops.humanoracles.xyz) with restricted CORS
• Admin can instantly suspend/ban a compromised operator account
• Answer audit log — all responses are immutably attributed to the submitting operator

Residual risk after mitigations: LOW-MEDIUM. MFA enforcement would reduce this to LOW. Recommendation: enforce Firebase Auth MFA for all operator accounts.

R5 — Agent Submitting User Data Without End-User Consent

Mitigations implemented:

• Terms of Service (Section 5) require that agent developers using the Service comply with all applicable laws regarding the personal data of their own end-users; the developer assumes full responsibility for lawful submission of question content
• The DPA template (see gdpr/dpa) establishes the agent developer as a data controller for their end-users' data, with the Company acting as processor only for the question delivery function
• Content policy filters PII extraction patterns

Residual risk: MEDIUM. This risk cannot be fully mitigated by technical means — it depends on the legal compliance of agent developers. The contractual framework (Terms + DPA template) shifts the legal responsibility to the developer for their end-users' data. The Company's exposure is limited to its processor role.

R6 — Accidental Destruction of Payment Records

Mitigations implemented:

• Cosmos DB continuous backup enabled — point-in-time restore available
• Payment_events container has a 7-year TTL (not 90-day TTL used for questions) — accidental deletion is recoverable via backup
• Append-only write pattern — no delete operations are coded for payment_events

Residual risk: LOW.

R7 — Webhook Delivery to Wrong Endpoint

Mitigations implemented:

• SSRF validation at webhook URL registration: blocks localhost, RFC1918 private ranges, link-local addresses, cloud metadata endpoints (169.254.169.254)
• HMAC-SHA256 signature verification — even if delivered to a wrong endpoint, the content is signed and verifiable
• Webhook URLs are validated at question submission time, not just at delivery time

Residual risk: LOW.

B6. DPIA Conclusion

Overall Residual Risk Level

After the mitigations described in B5, the residual risk levels are:

DPO Appointment Assessment

Art. 37 GDPR requires appointment of a Data Protection Officer if the controller carries out large-scale systematic monitoring of data subjects, or large-scale processing of special category data (Art. 9) as a core activity. As of the date of this DPIA:

• Scale: The Service is at MVP scale — not "large-scale" within the meaning of Recital 91 GDPR and EDPB guidance (WP243). Volume is expected to remain below the threshold requiring a DPO for the foreseeable future.
• Core activity: The processing of question content (which may contain special category data) is a core activity of the Service. However, the special category data is incidental (voluntary disclosure by submitters) and not systematically collected as a stated purpose.
• Conclusion: DPO not required at current scale. This assessment must be revisited when the Service reaches significant scale (EDPB guidance suggests 5,000+ data subjects as a rough indicator) or if the service deliberately expands into systematically collecting health or mental health data.

DPIA Outcome

Required Follow-Up Actions

1. Enforce Firebase Auth MFA for all operator accounts — reduces R1 and R4 residual risk from MEDIUM to LOW. Target: before first operator account is created.
2. Publish and enforce DPA template for agent developers who integrate the Service into products used by end-users — addresses R5. See gdpr/dpa.
3. Review this DPIA when volume reaches 1,000 data subjects — reassess large-scale trigger and DPO requirement.
4. Annual review of this DPIA in parallel with the RoPA review (next: 22 February 2027).

DPIA prepared by

Data Controller — Human Oracles (sole trader / JDG, Poland)

Date

22 February 2026

Next review

22 February 2027 (or sooner at 1,000 data subjects or on material change)

DPO consulted

Not applicable (no DPO appointed — see assessment above)