Data access model
Who controls the data on CHORUS, and how researchers get access to it.
Each dataset has a data controller who decides who can use it and under what conditions. Access is granted per project, and it is always traceable and revocable.
Nobody owns access; someone is accountable for it
Every dataset on CHORUS has a data controller - the institution, or the principal investigator acting for it, responsible for having collected the data and for what happens to it afterwards.
The controller is not simply an owner with a veto. They carry the legal accountability, which is why the decisions below are theirs to make and not the platform's.
What the controller decides
- Which projects may use the data - and for what stated purpose.
- Under what conditions - what may be done with it, and by whom.
- For how long - access is bounded, not indefinite.
Controllers keep this authority throughout, including the right to restrict use or withdraw the data. Nothing in the platform overrides that.
How access is granted
Access is granted to a project, for a person, for a purpose - never to a person in general.
A researcher asks for access to specific data in the context of an approved project. The controller decides on the basis of that project's purpose, the person's role in it, and their affiliation. If granted, the person receives a role in the project's workspace, scoped to that workspace alone.
This is why membership follows the project's governance rather than being arranged between colleagues, and why holding a wide role in one project gives you nothing in another.
What access actually permits
Access means you may work with the data. It does not mean you may take it.
Inside the workspace you can analyse it with the platform's tools. You cannot copy it out, download it to your own machine, or pass it to someone outside the project. Results leave only through the reviewed export route - see Exporting results.
The distinction is the whole point of the model: use is generous, movement is controlled.
The rules access follows
Whatever the deployment, the same principles govern how access is granted:
- Named individuals only - no shared or generic accounts.
- Per project, never platform-wide.
- Least privilege - the smallest role that lets someone do their part.
- Time-limited, not open-ended.
- Multi-factor authentication where the platform or the institution requires it.
- External collaborators are approved explicitly, not admitted by association with a project.
- Access is revoked when the project closes.
- Every role change is logged.
When access ends
Access is bounded by the project. When the project ends, or the conditions it was approved under change, access is withdrawn and the workspace is closed - see Close a workspace.
What is recorded
Enough to reconstruct who did what, without watching how you work. The audit record covers:
- Signing in and out
- Access to a workspace
- Administrative actions
- Changes to user roles
- Data ingestion events
- Workspaces being created and closed
- Changes to network policies
- Export requests, and the decisions made on them
- Major technical incidents
Your analyses are not the subject of this record. What is captured is the governance around them - who was let in, what moved, and who decided.
Why access is tied to projects rather than to people
It would be simpler to accredit a researcher once and let them work on whatever they are cleared for. Most secure environments deliberately do not, and the reason is that consent and approval are specific.
Participants agreed to their data being used for a stated purpose. An ethics committee approved that purpose. A data transfer agreement covers that purpose. None of those things follow a researcher to their next study - so neither does the access.
It also means access ends naturally. A person-based permission has to be remembered and revoked; a project-based one expires with the project that justified it.