# DPIA — Two-Sided Data Sharing Model (v2.0)

_Last updated: 2026-05-15. Owner: info@profoyo.com._

## 1. Scope of the assessment

This Data Protection Impact Assessment covers the cross-side data-sharing model on the Profoyo platform: how a freelancer's data becomes visible to a linked company, and how a company's data becomes visible to a linked freelancer.

It is required because the processing involves:

- Special-category data (insurance / health) — Art. 9 GDPR.
- Automated scoring (Zelfstandigenwet readiness, dossier health, AI match) — Art. 22.
- Systematic monitoring of working relationships at scale.

## 2. Description of processing

- **Data subjects:** independent professionals and company representatives in the Netherlands and EU.
- **Categories of data:** identity, contact, KvK, insurance, contract, financial (invoices, time, expenses), assessment scores, AI-generated insights.
- **Purpose:** enable lawful, defensible engagements between freelancers and companies under the Dutch Zelfstandigenwet.
- **Recipients:** the freelancer themselves, the linked company themselves, sub-processors (see `subprocessors.md`).

## 3. Necessity and proportionality

Cross-side data sharing is **necessary** to operate a two-sided marketplace, but it is **not** necessary to share data blanket. The system therefore enforces:

- **Default-deny:** every cross-side scope starts at "denied" (Art. 25).
- **Granular consent:** each data scope (insurances, compliance score, etc.) is a separate consent record with its own purpose, retention and TTL (Art. 5(1)(c) data minimization).
- **Two lanes only:** (a) self-assessment pre-sharing, or (b) explicit approval of a specific request from the other side. No third lane exists.
- **Withdrawal parity:** withdrawing consent is one click, takes effect immediately (Art. 7(3)).

## 4. Risks identified and mitigations

| Risk | Likelihood | Impact | Mitigation |
|---|---|---|---|
| Company sees data the freelancer did not intend to share | High without controls | High (special-category) | Default-deny RLS + `has_consent()` gate; row-level visibility flags; preview before approving |
| Score-based decisions disadvantage freelancers | Medium | Medium | Explainability per score; human-review button; scores never sole basis |
| Marketplace exposure leaks identity | Medium | High | Discoverability is identity-card-only by default; per-verification toggles |
| Token-based share links opened by unintended parties | Medium | Medium | 30-day TTL cap; opened-count + country logged; one-click revoke; notify-on-open |
| Stale data persists after consent withdrawal | Low | Medium | Daily cron purges per scope retention; legally retained tables documented to user |
| Breach exposes scope-wide data | Low | High | RLS + private buckets + signed URLs; hash-chained audit; 72h breach workflow |

## 5. Data subject rights (Art. 15–22)

Implemented as `dsr_requests` workflow exposed in the Privacy Center. Response within 30 days. See `privacy-v2.md`.

## 6. Consultation

This DPIA will be revised whenever a new consent scope is added or an existing scope's retention/legal basis changes. Material changes trigger a re-acknowledgement of the Privacy Notice.

## 7. Conclusion

The two-sided sharing model, as designed, reduces the residual privacy risk to **low**, conditional on the consent-v2 enforcement flag being enabled in production. This DPIA must be re-reviewed after the flag flips and annually thereafter.