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 NIS2 Directive cybersecurity risk-management and incident-reporting 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: myDRE does not prescribe research applications or enforce specific data schemas. Subject Data is stored and processed within dedicated Microsoft Azure environments hosted under the client organization's own Azure Billing Account in their chosen geographic region. The handling of User Data is described in section 5.1 and the linked policies.
- 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 information generated by or collected from individuals interacting with myDRE services. For the myDRE user information covered by the Data Protection Policy, anDREa acts as Processor on the instructions of its Tenants, including when collecting and storing user actions. Processing purposes, responsibilities, and the handling of data subject rights are defined in the Data Protection Policy and Data Handling Policy.
- 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 support traceability and provide audit evidence for institutional compliance teams, aligning with the Assessment Framework for Services. Log access, protection, retention, and review are governed by the applicable ISMS controls.
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: For Subject Data, anDREa acts as Processor under the applicable DPA, and the client organization's Controller responsibilities are defined in the linked Data Protection Policy and GDPR/SCC guidance. anDREa personnel will not access, inspect, or manipulate Subject Data except on explicit, authorized client instruction or where processing is required by applicable Union or Member State law. In the latter case, anDREa will inform the client organization before processing unless that law prohibits such notification.
6. Privileged Personnel Access Governance and Mitigations
To support time-sensitive incident containment and investigation, authorized anDREa personnel retain a technical path to modify workspace memberships on explicit client instruction. This capability enables client organizations to investigate incidents and meet applicable notification obligations, including those under NIS2 and the GDPR. Incident escalation, client communication, and notification timelines are governed by the linked incident-management procedures and organization-specific escalation routes.
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. Instructions must be received through the official ticketing system. In urgent situations, an instruction may be received through an approved out-of-band channel in accordance with the organization's documented escalation routes. The instruction and resulting actions must be documented immediately in the official ticketing system and communicated to the designated client contacts through those escalation routes.
- Environment Separation: anDREa's 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 the required elevated role via Microsoft Azure PIM. Under anDREa's privileged-access procedures, these activations must not be automated. Each activation requires a documented business justification and is logged, including 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 accountable for a specific myDRE workspace within the client organization's governance arrangements. In the workspace context, the Accountable acts as a functional controller by governing workspace access, resource allocation, and data egress approvals on behalf of the client organization. This operational designation does not replace or transfer the legal responsibilities of the Controller under the GDPR. The Accountable's permissions and responsibilities are defined in the myDRE Role Matrix.
- 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 Privileged member, or outbound connections to approved subdomains.
Data Egress Architecture
Data egress from a workspace is governed through the following 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 hold valid memberships in both workspaces and requires approval by an Accountable or Privileged Member through the applicable workspace-to-workspace transfer workflow.
- Approved Network Paths: Direct network egress is restricted to specific ports or domains explicitly allowed by the workspace Accountable or Privileged member.
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