Skip to main content
Security & governance

The Five Safes

Concept

CHORUS protects sensitive data through five layers of control - the widely used Five Safes framework.

In short

Five layers cover who accesses data, why, where the work happens, how the data is protected, and what is allowed to leave.

Why a framework at all​

"Is this secure?" is not a question anyone can answer directly. The Five Safes breaks it into five that can be answered, each about a different thing that has to hold before sensitive data is used for research.

It came out of the UK Office for National Statistics and has become the common vocabulary for secure research environments across Europe. CHORUS organises its own security documentation around it, chapter by chapter - so the model is the structure, not a label applied afterwards.

Safe people​

Are the people using the data trained, authorised, and accountable?

Access is granted to a named individual, not to a team or a shared login, so every action traces back to a person. Accounts are issued by the institution running the instance, after whatever verification and approval it requires, and terms of use are accepted before first access.

Safe projects​

Is the research purpose appropriate, legal, and ethical?

Data is used for an approved purpose, not for whatever seems interesting later. A project arrives with its ethics approval, its legal basis, and an agreement covering the data it may use - and access is scoped to that project rather than to the person.

This is why membership of a workspace follows the project's governance rather than being arranged informally between colleagues.

Safe settings​

Is the environment the analysis happens in secure?

Each project works in an isolated workspace - separated at the network, at storage, and at the level of running processes - with no unmediated route in or out. Data does not reach your computer; you see the tools streamed to your browser.

Every consequential action is recorded: administrative changes, data movement, sessions opening and closing.

See What a workspace is for how isolation works in practice.

Safe data​

Is the data itself appropriate for this project?

Only what the approved purpose requires enters the environment, and it is de-identified at the source institution before transfer - not afterwards, and not by the platform.

How far that goes depends on the analysis: pseudonymisation is usually enough for work inside a project, while anything released publicly must be anonymised.

Safe outputs​

Do the results leaving preserve the confidentiality of the data behind them?

Nothing leaves by default. Results are released only through a review that considers whether an output could identify someone - a table with small cells, a figure with an outlier - and every approval decision is recorded.

See Exporting results for how that works.

How they work together​

The five are complementary, not alternatives. Even if one control were bypassed, the others still apply - anonymous data in an insecure setting is still a problem, and a perfect environment holding data nobody approved is still a problem.

Together they mean security comes from the design of the system rather than from individuals behaving carefully.

Where the Five Safes came from, and who else uses it

The framework was formalised by Desai, Ritchie and Welpton at the UK Office for National Statistics, and has been adopted as the reference model by national statistics offices, health data research bodies, and secure environment operators across Europe.

That shared vocabulary matters practically: when CHORUS, a partner hospital, and an ethics committee all describe controls in the same five terms, an assessment does not have to start by agreeing on definitions.

It also sits alongside other frameworks rather than competing with them - see Standards.