Clarification Data Access on myDRE
1. Objective
The purpose of this document is to establish a clear, formal governance policy that defines and demarcates data access boundaries, processing mechanics, and regulatory roles within the myDRE platform. It outlines the specific technical and administrative measures implemented by anDREa B.V. (hereafter "anDREa") to protect data assets while giving client organizations the visibility and control required to fulfill their statutory compliance duties.
2. Scope
The scope of this document aligns directly with the overall scope of the ISMS as defined in Clause 4 (Context of the Organization). It specifically governs:
- The processing of two distinct data classes: User Data and Subject Data.
- The control perimeters of all platform participants: including anDREa Support, local Research Support (RS), Workspace Accountables, and Privileged Members.
- Regulatory mapping: under ISO/IEC 27001:2023 Controls A.05.15 (Access Control), A.05.16 (Identity Management), A.05.18 (Access Rights), GDPR data processing boundaries, and EU NIS 2 Directive data protection requirements.
3. Availability and Access
This document is:
- Required reading for all anDREa employees and contractors.
- Available to all authorized interested parties and platform users via our public ISMS repository.
4. Architectural Model and Platform Philosophy
The myDRE platform delivers an architecture that is entirely data and tool agnostic. Unlike traditional data management systems, myDRE provides a secured cloud workspace that functions as a digital trusted environment.
┌───────────────────────────────────────────────────────────┐ │ Client Azure Billing Account │ │ ┌─────────────────────────────────────────────────────┐ │ │ │ myDRE Workspace │ │ │ │ ┌───────────────────────┐ ┌─────────────────────┐ │ │ │ │ │ Subject Data │ │ Tenant Tooling │ │ │ │ │ │ (Isolated Storage) │ │ (User-Deployed VMs) │ │ │ │ │ └───────────────────────┘ └─────────────────────┘ │ │ │ └─────────────────────────────────────────────────────┘ │ └───────────────────────────────────────────────────────────┘
- Data Sovereignty: anDREa does not supply software applications or enforce specific data schemas. Instead, all data assets are stored and processed within dedicated Microsoft Azure environments hosted under the client organization's own Azure Billing Account in their chosen geographic region.
- Trusted Environments: Platform trust is maintained by performing upfront due diligence with institutions, allowing them to determine what data classes they entrust to a workspace.
- Contractual Foundation: Every client organization operates under a legally binding Data Processing Agreement (specimen) (DPA) with anDREa.
5. Data Typology and Processing Rationales
anDREa categorizes platform-accessible information into two distinct classes, maintaining strict handling rules for each.
5.1 User Data (Platform Participants)
User Data encompasses any information generated by or collected from an individual interacting with myDRE services. This data is processed to satisfy the client organization's implicit duty of care and platform security monitoring needs.
- Core Identity Attributes: Usernames and alternative verification email addresses are stored to authenticate access.
- Telemetry and Diagnostics: Geolocation data and IP addresses are parsed to enable real-time troubleshooting and security context verification.
- Continuous Improvement: Aggregated system telemetry is evaluated to identify platform bugs and performance opportunities.
- Auditing and Traceability: Telemetry logs provide an unalterable audit trail for institutional compliance teams, aligning directly with the Assessment Framework for Services.
5.2 Subject Data (Research Datasets)
Subject Data includes any dataset, image, file, or object uploaded to a myDRE workspace by its members for scientific processing and analysis.
- Processing Purpose: Grounded entirely on the explicit authorization and operational mandates of the client organization.
- Platform Neutrality: anDREa acts strictly as a Processor under the GDPR. The client organization serves as the Controller, determining the purpose and means of processing. anDREa will not access, inspect, or manipulate Subject Data unless compelled to do so by a legally enforceable court order or explicit, authorized instruction.
6. Privileged Personnel Access Governance and Mitigations
To ensure client organizations can execute time-sensitive investigations (such as containing a misprovisioned workspace or concluding a data leak audit within the statutory 72-hour GDPR window), authorized anDREa personnel retain a technical path to modify workspace memberships.
Because this administrative capability introduces a theoretical path to access the data within a workspace, anDREa mitigates this threat through five strict layers of operational controls:
- Explicit Client Authorization Only: anDREa personnel are strictly prohibited from accessing a workspace or modifying permissions unless they receive an explicit instruction from an authorized client representative via the official ticketing system. Urgent out-of-band exceptions must be documented immediately.
- Environment Separation: Development and testing environments are strictly isolated from production scopes. Production data is never utilized for development, testing, or acceptance workflows.
- Privileged Identity Management (PIM): Administrative changes require anDREa Support to manually activate an elevated role via Microsoft Azure PIM. PIM activations cannot be automated, require a documented business justification, and log who activated the role and when.
- Mandatory Personnel Acknowledgment: Every anDREa employee must formally sign and acknowledge their understanding of this data access policy before receiving system credentials.
- Continuous Audit Review: All PIM activations, support logs, and configuration changes are retained for a minimum of 90 days. The anDREa Privacy Officer reviews these records at least every 30 days to verify policy compliance.
7. Role Definitions & Boundary Operations
7.1 Operational Role Matrix
- anDREa Support: Internal anDREa personnel tasked with maintaining platform stability and executing authorized configuration adjustments for local Research Support teams.
- Research Support (RS): Designated institutional administrators who manage their organization's overall myDRE footprint, create workspaces, and oversee tenant-level compliance.
- Accountable: The sole individual with ultimate responsibility for a specific myDRE workspace. Acting as the functional Controller, they maintain full authority over workspace access, resource allocation, and data egress approvals.
- Privileged Member: Mandated workspace administrators who hold the same operational privileges as the Accountable (excluding the ability to transfer ownership).
7.2 Core Lifecycle Processes
Workspace Provisioning
[Client Ticket Received] ──► [RS Validation] ──► [anDREa Support PIM Activation] ──► [Workspace Created]
- Inception: If a workspace is not created directly by local Research Support, an authorized institutional representative must submit a formal ticket containing the Accountable's identity, optional Privileged Members, Study ID, Cost Center, and specific budget thresholds.
- Verification: anDREa Support will reject any request that lacks explicit approval from the client organization's designated contacts.
- Sovereignty: All completed workspaces remain fully visible to and managed by the client organization's internal Research Support team.
User Account Creation
- Request Flow: New user accounts are created when local Research Support submits a request through the Research Support Portal. Workspace Accountables and Privileged Members may also request account creation, provided their local RS team has approved the action.
- Execution: anDREa Support activates their required PIM role to execute the provisioning workflow inside the directory.
- Attack Surface Reduction: This human-in-the-loop approval process functions as a safeguard against automated provisioning attacks and limits the number of accounts with extended directory privileges.
Workspace Membership Mutations
- Member Modifications: Workspace Accountables and Privileged Members can autonomously add or remove any valid myDRE username within their workspace, assigning any role except Accountable.
- Accountable Role Transfers: The Accountable role can only be modified by local Research Support. Changing an Accountable requires a direct action by the RS team or an explicit ticket instructing anDREa Support to perform the transfer.
Data Ingress Architecture
To enforce unidirectional data movement and prevent unauthorized exfiltration during the ingestion phase, all uploads utilize a secure two-step pipeline:
- Instantiation: The platform provisions a temporary, isolated Azure blob container to receive the incoming file payload.
- Commitment: Once the upload is committed, the uploader's access token to the temporary container is automatically revoked. The platform then securely moves the payload into the workspace's primary storage account.
- Alternate Vectors: Users may also ingress data via authorized Data Landing Zone APIs, third-party utilities using keys managed by the Accountable, or outbound connections to approved subdomains.
Data Egress Architecture
Data extraction out of a workspace is strictly limited to four regulated pathways:
- Download Request Workflow: A workspace member triggers a formal extraction request, which must be manually reviewed and approved by the workspace Accountable or a Privileged Member.
- Workspace-to-Workspace Transfer: Cross-workspace data sharing requires the requesting user to maintain active, valid memberships in both the source and destination perimeters.
- Approved Network Paths: Direct network egress is restricted to specific ports or domains explicitly allowed by the workspace Accountable.
GDPR and SCC roles
The table is tailored under the assumption that myDRE is being used from anDREa BV and was created by Barbara Archbold (Legal Council UMC Utrecht). For more information regarding Standard Contractual Clauses (SCC). Disclaimer, always consult your own DPO and Legal.
SCC for anDREa BV applies when anDREa BV actively participates. If members of a workspace use the services provided by anDREa to perform the action, it is the person with the role Accountable for that particular Workspace that is subject to SCC rules and regulations; this is the responsibility of the institute to which the Workspace belongs.
| Party | GDPR | SCC | Licence myDRE | |
|---|---|---|---|---|
| A.1 | anDREa BV | Processor of licence holder (Institute) of myDRE | If transfer outside EEA by anDREa = anDREa is data exporter – anDREa needs to sign SCCs (module 3 or 4) (in agreed in DPA) ** | Protinus licences to Institute and purchase licences from anDREa |
| A.2 | anDREa BV | Controller for User/Tenant information (processing for anDREa’s own purpose) | If transfer outside EEA by anDREa = anDREa is data exporter – anDREa needs to sign SCCs (module 1 or 2) ** | n/a |
| B | anDREa BV’ processors (i.e. Google, Zoho, Microsoft) | Sub processor of Institute | If transfer outside EEA by anDREa to sub processor of anDREa: anDREa needs to sign SCCs (module 3) (agreed in DPA) | n/a |
| C | Institute | Controller | If Institute is the data exporter (including when Institute gives access to myDRE from outside the EEA) Institute needs to sign SCC’s with data importer (module 1 or 2) | Protinus licences to Institute and purchase licences from anDREa |
| D | Research / collaboration partners of Institute who get access to myDRE through Institute | Controller, or joint controller in case the GDPR defines them as joint controllers. | If these parties transfer data outside the EEA; they are data exporters. They need to sign SCC’s with the receiver/data importer. If they access from outside the EEA = they are a data importer and need to sign SCC’s with the data exporter. That is Institute, not anDREa BV as processor of Institute. | Falls under licence of Institute as long as Institute is controller for myDRE and accountable and responsible for their performance of the study/action/workpackage where the data management of myDRE is a part of Institute’s responsibility. |
| E | Subcontractor/third party/data provider of Institute who get access to myDRE through Institute for the purpose of performing their part of the action | Controller, or joint controller in case the GDPR define them as joint controllers (in some cases/countries the applicable privacy laws define them as processor for the part of performing services for Institute) | If these parties transfer data outside the EEA; they are data exporters. They need to sign SCC’s with the receiver/data importer. If they access from outside the EEA = they are a data importer and need to sign SCC’s with the data exporter. That is Institute, not anDREa BV as processor of Institute. | Falls under licence of Institute as long as Institute is controller for myDRE and accountable and responsible for their performance of the study/action/work package where the data management of myDRE is a part of Institute’s responsibility. |
| F.1 | Subcontractor/third party/data provider within the project but subcontracted by research of collaboration partner of Institute, however Institute give access to myDRE as part of Institute’s action | controller, or joint controller in case the GDPR defines them as joint controllers (in some cases/countries the applicable privacy laws define them as processor for the part of performing services for Institute. | If these parties transfer data outside the EEA; they are data exporters. They need to sign SCC’s with the receiver/data importer. If they access from outside the EEA = they are a data importer and need to sign SCC’s with the data exporter. That is Institute, not anDREa BV as processor of Institute. : | Falls under licence of Institute as long as Institute is controller for myDRE and accountable and responsible for their performance of the study/action/work package where the data management of myDRE is a part of Institute’s responsibility. |
| F.2 | Subcontractor/third party/data provider within the project but subcontracted by research of collaboration partner of Institute, however Institute give access to myDRE as processor | Institute= Processor Other parties, controllers or joint controller anDREa = processor | If these parties transfer data outside the EEA; they are data exporters. They need to sign SCC’s with the receiver/data importer. If they access from outside the EEA = they are a data importer and need to sign SCC’s with the data exporter. All depending on the actual processing. As Institute cannot be a party, this is superfluous this schedule | If Institute only processes on behalf of other parties and is a processor a meant under GDPR: this is out of scope of the licence of Institute = the research of collaboration partners (or even the subcontractors) need to purchase their own licence from Protinus or anDREa. |
- MODULE ONE: Transfer controller to controller
- MODULE TWO: Transfer controller to processor
- MODULE THREE: Transfer processor to processor
- MODULE FOUR: Transfer processor to controller