Sign in Request demo

Data Protection Impact Assessment (DPIA)

Document ref: RINET-DPIA-2026-001 · Version 2.0 · Dated: 19 April 2026 · Next review: 19 October 2026

Preamble

This Data Protection Impact Assessment has been prepared pursuant to Article 35 of Regulation (EU) 2016/679 (the General Data Protection Regulation, hereafter "GDPR") in respect of the processing activities carried out by Ri.NET through the rinet.dev developer platform and the underlying Ri.NET Civic Intelligence Operating System. The assessment documents the nature, scope, context, and purposes of the processing; identifies and analyzes the risks to the rights and freedoms of natural persons; and records the measures adopted to address those risks.

A DPIA is not a legal formality. It is the operational record of how we think about our obligations. This document is maintained as a living instrument and will be updated whenever processing operations change materially or at each scheduled review, whichever is sooner.

1. Scope of the assessment

This DPIA covers:

  • Personal data processed through rinet.dev (registration, demo booking, API usage, analytics, fingerprinting);
  • Personal data about public-sector officials and other individuals whose publicly-available information is indexed by the Ri.NET platform as part of its civic intelligence mission;
  • Communications, billing, and support-related personal data.

This DPIA does not cover processing conducted by Ri.NET’s customers in their capacity as data controllers (governmental authorities deploying sovereign instances). Those deployments are the subject of separate customer-specific DPIAs maintained by the relevant customer.

2. Necessity and proportionality

Ri.NET’s processing of personal data through rinet.dev is necessary for (a) providing the Service to registered developers; (b) maintaining the security and integrity of the platform; (c) complying with legal obligations; (d) pursuing the legitimate interest of operating and improving a technical service. The volume and detail of personal data processed are proportionate to these purposes: we collect what is required, for no longer than is required, with the strongest protections we can reasonably implement.

The platform’s civic intelligence processing of publicly-available information about public officials is necessary for the legitimate interest of democratic oversight, regulatory transparency, and investigative journalism. The processing relies exclusively on information already lawfully in the public domain as a result of specific statutory publication requirements (company registry disclosures, public procurement announcements, legal gazette publications, court docket publications). Ri.NET does not aggregate this public information beyond what is necessary to make democratic oversight effective.

3. Purposes of processing

Processing is carried out for the following specific, explicit, and legitimate purposes:

  • Service delivery — authentication, API provisioning, rate limiting, billing, support.
  • Platform security — fraud prevention, abuse detection, incident response.
  • Analytics — aggregated usage patterns for product improvement.
  • Legal compliance — tax, regulatory retention, responses to lawful requests.
  • Civic intelligence — forensic analysis of public-sector data for authorized analysts.

4. Categories of personal data

Five broad categories of personal data are processed:

  • Identification & contact (name, email, organization) — collected at registration or demo booking.
  • Authentication (OAuth provider IDs, API keys) — derived from identity provider sign-in.
  • Technical telemetry (IP, user-agent, device fingerprint, session ID) — collected automatically.
  • Usage data (API requests, response codes, feature interactions) — derived from platform use.
  • Public-sector profile data (OIB, role history, procurement participation) — indexed from public registries.

5. Processing flows

The main personal-data flows are:

  • Visitor → rinet.dev → telemetry store. Page view, fingerprint, session recorded.
  • Registrant → rinet.dev → leads store + API key issuance. Contact + context data captured; API key generated; audit log anchored.
  • Demo requester → rinet.dev → leads + demo queue. Contact + preferred date captured.
  • Authenticated user → API → usage log. Every API request logged with key ID, endpoint, status, response time.
  • Public-sector ingestion agents → normalization → entity resolution → graph & vector stores. Public registry records normalized and linked to canonical entities.

6. Lawfulness of processing

Each processing activity has an identified legal basis under GDPR Article 6 (or, where applicable, Article 9). These are documented per category in the Privacy Policy (section 6). The most sensitive processing — civic intelligence indexing of publicly-available information about public officials — rests on the legitimate-interest basis (Art. 6(1)(f)) with a detailed balancing assessment recorded below.

7. Legitimate interest balancing test

Where processing is based on legitimate interest (primarily the civic intelligence function and security-motivated telemetry), we apply the following three-part balancing:

  • Purpose test. Is the interest legitimate? Yes — democratic oversight of public institutions, fraud prevention in public procurement, and journalistic investigation into corruption are interests recognized throughout European case law as compelling.
  • Necessity test. Is the processing necessary to achieve the interest? Yes — the public-sector datasets we process are fragmented across thirty-plus sovereign sources. Without the reconciliation we perform, the information is technically public but practically unreachable.
  • Balancing test. Do the rights and freedoms of data subjects override the interest? No — the individuals in scope are (a) acting in public-official capacity, (b) subject to specific statutory publication duties, (c) benefiting from democratic oversight as a whole. We do not process data outside the scope of public official activity; we do not cross-reference with private-life data; we do not publish derived findings except where the underlying facts are already publicly documented.

8. Risk assessment

We have identified the following risks to data subject rights and freedoms:

  • Unauthorized disclosure. Risk that personal data could be accessed by unauthorized parties. Severity: High (some categories). Likelihood: Low (multiple security controls).
  • Inaccurate or outdated data. Risk that data about an individual is no longer current or contains errors carried forward from a source. Severity: Medium. Likelihood: Medium (mitigated by reversible entity resolution).
  • Excessive profiling. Risk that aggregated data creates a more detailed profile than any individual source permits. Severity: Medium. Likelihood: Medium (controlled by purpose-limited retrieval).
  • Function creep. Risk that data collected for one purpose is used for another without renewed lawful basis. Severity: High. Likelihood: Low (strict purpose labeling, architectural tenant isolation).
  • Re-identification. Risk that technical telemetry (fingerprints) enables persistent cross-site identification. Severity: Medium. Likelihood: Medium (mitigated by retention limits, consent-based analytics layer).

9. High-risk processing

Two activities qualify as potentially high-risk processing triggering DPIA scrutiny:

  • Systematic monitoring of publicly accessible areas (Art. 35(3)(c)). The civic intelligence function indexes public information systematically. Mitigation: scope strictly limited to public-official activity; reversible entity resolution; transparent public documentation of data sources; no retention of data outside the stated sources.
  • Device fingerprinting at scale (Art. 35(3) analogously). Mitigation: retention limit of 13 months, full disclosure in Privacy Policy, consent-layer for non-essential analytics, architectural separation from civic intelligence datasets.

10. Mitigation measures

The following measures have been implemented to reduce identified risks:

  • Tenant isolation at the storage layer (not merely application-level);
  • AES-256 encryption at rest with per-tenant key derivation;
  • TLS 1.3 with HSTS preload;
  • Zero-trust internal fabric with mTLS and SPIFFE identities;
  • Scope-limited access tokens for all service-to-service calls;
  • Automated retention enforcement via scheduled deletion jobs;
  • Reversible entity resolution with full provenance trail;
  • Immutable audit log anchored to Polygon Proof-of-Stake for post-hoc verification;
  • Transparent disclosure of fingerprinting methodology;
  • Consent-based activation of optional analytics;
  • Right-request fulfillment procedures with 30-day SLA.

11. Security controls — summary matrix

Detailed security documentation is maintained separately as RINET-SEC-2026. Summary of control domains:

  • Access control: role-based with principle of least privilege;
  • Authentication: OAuth 2.0 with MFA on administrative roles;
  • Session management: httpOnly cookies with strict SameSite policy;
  • Cryptography: AES-256, TLS 1.3, post-quantum-ready key derivation hierarchy;
  • Audit: append-only log anchored externally;
  • Monitoring: real-time anomaly detection with Telegram escalation;
  • Backup: encrypted off-server copies with 90-day rolling retention;
  • Vulnerability management: automated dependency scanning, patch SLA;
  • Incident response: documented runbook, 72-hour breach-notification capability.

12. Retention and erasure

Retention periods are defined per category in the Privacy Policy (section 8). Erasure on data-subject request is implemented at the storage layer with guaranteed propagation to vector indices, graph edges, and search indices.

13. International transfers

Personal data processed by Ri.NET remains within the European Economic Area under default configuration. Where limited processing involves sub-processors outside the EEA, we rely on European Commission Standard Contractual Clauses plus any supplemental technical measures required by the Court of Justice’s Schrems II jurisprudence.

14. Data subject rights

Mechanisms for exercising rights (access, rectification, erasure, restriction, portability, objection, withdrawal of consent, complaint to supervisory authority) are documented in the Privacy Policy. All requests are logged to the immutable audit trail.

15. Automated processing

Ri.NET performs extensive automated processing of publicly-available data but does not subject individual data subjects to decisions based solely on automated processing within the meaning of Article 22. Human analysts remain the decision-makers. Automated output surfaces findings; it does not take legal action.

16. Children and vulnerable subjects

The Service is intended for professional use by individuals over 16. We do not knowingly process personal data of children. Vulnerable-subject protections (enhanced transparency, restricted legitimate-interest processing) are applied wherever a data subject may reasonably be identified as vulnerable.

17. Ongoing monitoring

Compliance is monitored continuously through:

  • Audit log review (monthly);
  • Retention enforcement checks (automated);
  • Access-request response time tracking;
  • Incident logging and post-mortem review;
  • Quarterly review of legitimate-interest balancing for material changes.

18. Review cycle

This DPIA is reviewed:

  • Every six months on scheduled cadence;
  • Upon any material change to processing operations;
  • Upon any material change to applicable law;
  • Upon any significant security incident.

Next scheduled review: 19 October 2026.

19. Residual risk statement

After application of the mitigation measures listed above, residual risk to data subject rights and freedoms is assessed as acceptable. No identified residual risk rises to the level that would require consultation with the supervisory authority under GDPR Article 36.

20. Sign-off

This DPIA has been reviewed and approved by the data controller. A full copy, including the supporting legitimate-interest assessment and risk register, is available on written request to enterprise customers and on request to supervisory authorities.

Controller: Ri.NET, Amsterdam, Netherlands
Contact: damir@rinet.one
Reference: RINET-DPIA-2026-001 v2.0