When an auditor asks for proof that a reranking pipeline respects GDPR, the ideal response is a complete, tamper‑evident trail that shows who accessed personal data, when the access occurred, what was returned, and that any sensitive fields were redacted according to policy. The evidence package also demonstrates that the organization grants access only for a legitimate purpose and approves any ad‑hoc requests in real time.
What GDPR expects from a reranking service
GDPR treats personal data as a regulated asset. Articles 5 and 6 require data minimisation, purpose limitation, and a lawful basis for processing. Articles 30 and 32 push organisations to maintain detailed records of processing activities and to implement technical and organisational measures that protect data integrity and confidentiality.
From an auditor’s perspective, the following artifacts are essential:
- Identity‑bound logs that record every query against the ranking database.
- Evidence of consent or another lawful basis attached to each request.
- Proof that any returned personally identifiable information (PII) was masked or pseudonymised when required.
- Approval records for any operation that exceeds a predefined risk threshold.
- Replay‑able session recordings that can be inspected if a data‑subject request arises.
Why many pipelines cannot provide that evidence
In practice, teams often let a reranking service connect directly to a database using a static credential they share across environments. The service runs with broad read‑write rights, and there is no central point that can inspect the SQL payloads or the HTTP responses.
Because the connection bypasses any audit layer, the organisation loses visibility into who queried which user profile, whether the response contained raw email addresses, and whether a privileged operation was performed without oversight.
Even when organisations adopt OIDC or SAML for authentication, the application validates the token, not the network edge. The result is a situation where the setup, identity federation and least‑privilege roles, decides who may start a session, but it fails to enforce or record what actually happens on the data path.
The missing control surface: a data‑path gateway
You can close the gap only by inserting a layer that sits between the reranking service and the underlying datastore. That layer must inspect, approve, mask, and log every request. It is the only place where the gateway enforces policy, and it becomes the source of the audit evidence required by GDPR.
How hoop.dev fills the gap
hoop.dev is an open‑source Layer 7 gateway that proxies connections to databases, Kubernetes, SSH, RDP, and internal HTTP services. By placing hoop.dev in front of the ranking database, the organisation gains a single, identity‑aware proxy that provides the exact artifacts GDPR auditors demand.
Setup: identity and least‑privilege grants
Engineers authenticate to hoop.dev via OIDC or SAML. The gateway validates the token, extracts group membership, and maps the identity to a scoped role that defines which tables or columns the reranking service may touch. This step decides who can initiate a connection, but it does not yet guarantee what the connection will do.
The data path: hoop.dev as the enforcement boundary
All traffic from the reranking service to the database flows through hoop.dev. Because the gateway operates at the protocol layer, it inspects each query before it reaches the database and inspects each response before it reaches the service. This is the only place where the gateway enforces policy.
Enforcement outcomes that generate GDPR evidence
- hoop.dev records every session, including timestamp, identity, and full query text. You can retrieve the log for audit.
- When a query returns a column marked as sensitive, hoop.dev masks or pseudonymises the field in real time, ensuring that raw PII never leaves the gateway.
- If a request attempts a high‑risk operation, such as bulk export of user profiles, hoop.dev routes the request to a just‑in‑time approval workflow. hoop.dev stores the approval record alongside the session log.
- hoop.dev replays each session, giving auditors a step‑by‑step view of what the reranking service saw and did.
Because hoop.dev is the sole source of these artifacts, removing it eliminates the audit trail, the masking, and the approval records. In other words, the GDPR‑required evidence appears only because hoop.dev sits in the data path.
Getting started
To adopt this approach, begin with the getting‑started guide to deploy the gateway and configure OIDC authentication. The learn section explains session recording, inline masking, and just‑in‑time approvals in depth. For the full source code and contribution guidelines, visit the GitHub repository.
FAQ
Do I need to change my existing reranking code?
No. hoop.dev works with standard database clients, so the reranking service can continue using its existing driver. The only change is to point the client at the gateway endpoint instead of the raw database host.
How does hoop.dev handle data‑subject access requests?
Because every session is recorded and can be replayed, you can extract exactly what data was accessed for a given user and provide that to the data‑subject.
Is the gateway itself a data controller?
hoop.dev acts as a data processor on behalf of the organisation. It does not store user data permanently; it only logs metadata and masked responses needed for compliance.
