Ri.NET
Architecture Cortex API About
Sign in Request demo

Sections

  • Introduction
  • 1. The seven principles
  • 2. Lawful processing
  • 3. Fairness & transparency
  • 4. Data minimization
  • 5. Accuracy
  • 6. Storage limitation
  • 7. Integrity & confidentiality
  • 8. Accountability
  • 9. Data subject rights (Art 12-23)
  • 10. Consent mechanics
  • 11. Data protection by design (Art 25)
  • 12. Privacy by default
  • 13. Records of processing (Art 30)
  • 14. DPIA triggers (Art 35)
  • 15. DPO role (Art 37)
  • 16. International transfers (Ch V)
  • 17. Breach notification (Art 33-34)
  • 18. Processor obligations (Art 28)
  • 19. Audit, supervision, sanctions
  • 20. How Ri.NET aligns

GDPR Compliance Framework

Document ref: RINET-GDPR-2026-001 · Version 2.0 · Last reviewed: 19 April 2026

Introduction

Regulation (EU) 2016/679 of the European Parliament and of the Council of 27 April 2016 on the protection of natural persons with regard to the processing of personal data and on the free movement of such data, and repealing Directive 95/46/EC — the General Data Protection Regulation, or "GDPR" — is the constitutional text of European data protection. It establishes the rights of data subjects, the obligations of controllers and processors, the role of supervisory authorities, and the consequences of non-compliance.

Ri.NET is not GDPR-compliant because we were forced to be. Ri.NET was designed to be GDPR-compliant because civic intelligence is a serious responsibility, and the Regulation articulates serious standards. This document describes how each principal requirement of GDPR is reflected in our operations.

1. The seven principles (Article 5)

Article 5(1) establishes seven principles that govern all personal-data processing. These are not aspirational targets. They are legal requirements.

  • (a) Lawfulness, fairness, and transparency. Every processing activity has a documented lawful basis. Data subjects are informed through accessible documentation. No processing occurs that a reasonable data subject would not expect.
  • (b) Purpose limitation. Personal data is collected for specified, explicit, and legitimate purposes and not further processed in a manner incompatible with those purposes.
  • (c) Data minimization. We collect what is adequate, relevant, and limited to what is necessary for the stated purpose.
  • (d) Accuracy. Data is kept accurate and, where necessary, kept up to date; inaccurate data is erased or rectified without delay.
  • (e) Storage limitation. Data is kept in a form permitting identification for no longer than necessary.
  • (f) Integrity and confidentiality. Data is processed with appropriate technical and organizational security.
  • (2) Accountability. The controller is responsible for, and able to demonstrate, compliance with the foregoing.

2. Lawful basis for processing (Article 6)

Each processing activity we perform rests on one of the six lawful bases identified in Article 6(1). The specific basis applicable to each category of processing is documented in our Privacy Policy (section 6). We do not rely on consent where another basis is more appropriate; we do not invoke legitimate interest where consent is available and meaningful; we do not conflate bases to avoid accountability.

3. Fairness and transparency

Transparency under GDPR is not a disclosure obligation to be checked off. It is a commitment to processing that a reasonable data subject would, after honest disclosure, accept as reasonable. Our Privacy Policy and DPIA exist to make our processing legible. If a data subject cannot understand what we do and why, we have not met the transparency standard, regardless of the length of our documentation.

4. Data minimization (Article 5(1)(c))

Operationally, minimization means: do not collect fields "in case they are useful." Do not log what is not required. Do not retain longer than required. Do not indexes more entities than the legitimate purpose requires. Each form on rinet.dev is reviewed for minimization; each log field is justified; each retained index is audited.

5. Accuracy (Article 5(1)(d))

Ri.NET’s entity resolution engine is architecturally committed to accuracy. Resolution is reversible: if new evidence contradicts a prior merge of two records into a single identity, the engine unmerges, recomputes dependents, and rebuilds affected slices. The system does not accumulate identity errors silently. Individuals have the right (Article 16) to request rectification of inaccurate data; we honor such requests across all derivative layers, not merely the primary record.

6. Storage limitation (Article 5(1)(e))

Retention schedules are enforced by automated jobs. Nothing retained beyond its documented period survives. When a retention period expires, the record is erased, not merely hidden. Backups are purged in line with parent dataset retention plus a maximum 90-day rolling window.

7. Integrity and confidentiality (Article 5(1)(f))

Technical and organizational measures are described in detail in our DPIA (sections 10-11) and include AES-256 at rest, TLS 1.3 in transit, zero-trust internal fabric with mTLS, per-tenant key derivation with rotation, blockchain-anchored audit logs, and a tested incident-response procedure.

8. Accountability (Article 5(2))

We can demonstrate compliance through (a) the documentation set comprising this page, the Privacy Policy, the Cookie Policy, the Terms of Service, and the DPIA; (b) technical audit trails anchored externally; (c) records of processing maintained per Article 30; (d) regular review cycle; (e) internal policies and procedures available on request to supervisory authorities.

9. Data subject rights (Articles 12-23)

GDPR enumerates rights that data subjects may exercise. We implement all of them as first-class operations:

  • Information (Art 13-14). Through Privacy Policy + Cookie Policy + DPIA.
  • Access (Art 15). Structured export including all personal data held, purposes, categories of recipients, retention period, and source.
  • Rectification (Art 16). Correction propagated across all derivative layers (indices, graph, cortex).
  • Erasure — "right to be forgotten" (Art 17). Complete erasure subject to legal retention obligations, with provenance of the erasure itself logged to audit trail.
  • Restriction of processing (Art 18). Records flagged with restriction are excluded from query output.
  • Notification obligation (Art 19). Rectifications and erasures are communicated to recipients where applicable.
  • Portability (Art 20). Machine-readable export in standard format.
  • Objection (Art 21). Processing based on legitimate interest may be objected to; we stop unless we demonstrate compelling legitimate grounds.
  • Automated decision-making (Art 22). We do not subject data subjects to qualifying decisions.
  • Information & right to effective remedy (Art 13, 14, 79). Data subjects may lodge complaints with supervisory authorities.

Response SLA: 30 calendar days (extendable to 90 for complex cases with explanation to the data subject).

10. Consent mechanics

Where processing relies on consent, we follow Article 4(11) and Article 7 strictly: consent is freely given, specific, informed, and unambiguous; granted through a clear affirmative action; demonstrable; withdrawable with the same ease with which it was given. The rinet.dev cookie-consent banner embodies these principles: three equally-weighted options, plain-language explanation, localStorage persistence so the decision is not re-demanded, free withdrawal at any time.

11. Data protection by design (Article 25)

Ri.NET was architected data-protection-first. The seven-layer forensic architecture is not a privacy afterthought bolted on top of a generic data platform. Tenant isolation is enforced at the storage layer. Purpose-specific tokens restrict scope at every internal call. Audit logs are generated before the data operation that produced them becomes visible to the query layer. The system defaults to the most privacy-protective configuration; less restrictive settings require explicit opt-in.

12. Privacy by default

Fresh accounts receive the minimum feature set consistent with the tier. Analytics are off by default. Optional data sharing is off by default. Broader access is granted only through explicit, informed opt-in.

13. Records of processing (Article 30)

We maintain an internal Record of Processing Activities (ROPA) covering:

  • Name and contact details of controller;
  • Purposes of processing;
  • Categories of data subjects;
  • Categories of personal data;
  • Categories of recipients;
  • International transfers and safeguards;
  • Retention schedules;
  • Technical and organizational security measures.

The ROPA is available to supervisory authorities on request.

14. DPIA obligation (Article 35)

We conduct a DPIA for any processing likely to result in high risk to data subject rights. The current DPIA (RINET-DPIA-2026-001) is published at /legal/dpia.html.

15. Data Protection Officer (Article 37)

At our current scale and given the nature of our processing, the appointment of a formal DPO under Article 37 is not mandatory. We have nonetheless designated a primary data-protection contact (Damir Radulic, damir@rinet.one) to ensure that data-protection obligations are consistently discharged. If our processing scales to the point where DPO appointment becomes mandatory, we will designate a qualified DPO and update this section.

16. International transfers (Chapter V)

Data is processed within the European Economic Area under default configuration. Transfers to third countries take place only under an Article 46 safeguard (principally Standard Contractual Clauses plus any required supplemental measures). A list of current sub-processors with their locations is in the Privacy Policy (section 9).

17. Breach notification (Articles 33-34)

In the event of a personal-data breach likely to result in risk to data subject rights, we notify the competent supervisory authority within 72 hours (Article 33) and affected data subjects without undue delay where risk is high (Article 34). Our technical telemetry allows reconstruction of any suspected breach window to the individual operation.

18. Processor obligations (Article 28)

We bind processors by written data-processing agreements meeting Article 28(3) requirements, including: (a) processing only on documented instructions; (b) confidentiality commitments; (c) appropriate security measures; (d) sub-processor authorization controls; (e) assistance with data-subject rights fulfillment; (f) assistance with breach notification; (g) deletion or return on termination; (h) audit rights.

19. Audit, supervision, sanctions

We cooperate fully with supervisory authorities. We maintain records sufficient to demonstrate compliance. We acknowledge that the sanction regime under GDPR (up to €20 million or 4% of annual global turnover, whichever is higher) is meaningful and that compliance is not a cost of doing business — it is the definition of doing business correctly in the European Union.

20. How Ri.NET aligns — summary

Ri.NET’s approach to GDPR can be summarized in three sentences: every processing activity has a documented lawful basis; every data subject right is implemented as a first-class operation; every security measure is both technical and organizational. These are not aspirations. They are architectural commitments reflected in the first line of Python and in every commit thereafter.

For a complete mapping of GDPR requirements to Ri.NET implementations, enterprise and sovereign customers receive a compliance matrix as part of their onboarding package.

Contact: damir@rinet.one · Supervisory authority: Autoriteit Persoonsgegevens, Netherlands

© 2026 Ri.NET · KvK Amsterdam · All content protected.
Home · Privacy · Terms · Cookies