No. CERN does not apply the General Data Protection Regulation 2016/679 (GDPR), nor the Swiss Data Protection Act (FADP), nor any other national data protection law. CERN as an Intergovernmental Organisation applies solely its own internal data protection framework, the Operational Circular no. 11 “The Processing of Personal Data at CERN” (OC 11).

The application of OC 11 is not dependent on the time when the data was collected.

It applies to all processing operations carried out since the introduction of the OC 11 on 1.1.2019, including data subject rights which are enforceable also for “old” data.

What does this mean in practice?

It means that everything that you do today with the data (even if it was collected years ago) must be compliant. This “everything” includes all kind of processing, also storage.

Examples:

• Personal data was collected in 2010 when a new staff member was hired.
  The collection was not subject to OC 11, however, if the data is still present today and it turns out that there is no legal basis and purpose for keeping it, you have to delete it (OC 11 obliges!).

• A transfer of this data to an external entity carried out in March 2018 was not subject to OC 11.
  However, when the data subject concerned submits today a data subject request to correct the data, CERN has to comply with OC 11 and inform this external entity and ask them to update the data, too.

Data anonymisation is an irreversible process by which all data that might allow the data subject to be identified is removed from the dataset in order to render the individual unidentifiable.

There are several anonymisation techniques, and your choice will depend on the context. As the result of the anonymisation process must be as permanent as the destruction, we advise you to check the reliability of the technique you have chosen on the basis of three criteria:

1. Is it still possible to single out an individual?
2. Is it still possible to link information to an individual?
3. Is it possible to deduce information about an individual?

If you can answer "no" to the three questions above, the chosen technique is reliable and will lead to complete anonymisation of the data. If in doubt, or if the chosen process does not meet all the criteria, you should carry out an in-depth analysis of the potential risks and consult the ODP.

Data storage

First of all, it is important to have an overview of where personal data is stored. This may include:

• own servers;
• third party servers;
• email accounts;
• desktops;
• employee-owned device (BYOD);
• backup storage; and/or
• paper files.

General retention periods

Generally personal data should only be retained for as long as necessary. The retention periods can differ based on the type of data processed, the purpose of processing or other factors. Issues to consider include:

• Whether any legal requirements apply for the retention of any particular data. For example:
  • Trade law;
  • Tax law;
  • Employment law;
  • Administrative law;
  • Regulations regarding certain professions, e.g. medical.
• In the absence of any legal requirements, personal data may only be retained as long as necessary for the purpose of processing. This means data is to be deleted e.g. when:
  • the data subject has withdrawn consent to processing;
  • a contract has been performed or cannot be performed anymore; or
  • the data is no longer up to date.
• Has the data subject requested the erasure of data or the restriction of processing?
• Is the retention still necessary for the original purpose of processing?
• Exceptions may apply to the processing for historical, statistical or scientific purposes.

During the retention period

• Establish periodical reviews of data retained.
• Establish and verify retention periods for data considering the following categories:
  • the requirements of your service;
  • type of personal data;
  • purpose of processing;
  • lawful grounds for processing; and
  • categories of data subjects
• If precise retention periods cannot be established, identify criteria by which the period can be determined.
• Establish periodical reviews of data retained.

Expiration of the retention period

After the expiration of the applicable retention period personal data does not necessarily have to be completely erased. It is sufficient to anonymise the data. This may, for example, be achieved by means of:

• erasure of the unique identifiers which allow the allocation of a data set to a unique person;
• erasure of single pieces of information that identify the data subject (whether alone or in combination with other pieces of information);
• separation of personal data from non-identifying information (e.g. an order number from the customer’s name and address); or
• aggregation of personal data in a way that no allocation to any individual is possible.

In some cases, no action will be required if data cannot be allocated to an identifiable person at the end of the retention period, for example, because:

• the pool of data has grown so much that personal identification is not possible based on the information retained; or
• the identifying data has already been deleted.

Information obligations

In addition to other information obligations, in the context of data retention data subjects must be informed of:

• the retention period;
• if no fixed retention period can be provided – the criteria used to determine that period; and
• the new retention period if the purpose of processing has changed after personal data has been obtained.

In general, the monitoring of an employee’s computer usage, especially the use of keylogging software that records all keyboard entries made at a desktop computer does not comply with the best data protection practices.

All activities that involve substantial monitoring with the intention of identifying actions of individuals should be subject to a prior data privacy impact assessment.

All measures should minimise the intrusion of privacy for the individual as a primary consideration, not simply be based on the easiest technical solutions to implement. For example, the employee’s business computer could be checked in the presence of the employee as a first measure in line with the Organizations procedures for doing so.

Yes, according to the definition in OC 11, personal data includes also “online and device identifiers“.

Examples of such identifiers are:

• Internet protocol (IP) addresses;
• cookie identifiers; and
• other identifiers such as radio frequency identification (RFID) tags.

These identifiers refer to information that is related to an individual’s tools, applications, or devices, like their computer or smartphone. The above is by no means an exhaustive list. Any information that could identify a specific device, like its digital fingerprint, are identifiers.

And these identifiers can leave traces which may be used to create a profile of the device user and his identification, especially if combined with unique identifiers and other information received by servers.

Therefore, both dynamic and static IP addresses are considered personal data, as they allow the direct or indirect identification of the individual using the corresponding device.

Someone posts personal information on a social networking site, so its public and I can use it right?

Well, not exactly. Irrespective of the fact that these data are now known in the public domain, they can only be processed for the same purposes that they were originally made public.

The data subject always remains the owner of his/her personal data, whether publicy available or not.

Consequently, what is posted on a social networking site cannot be used for an employment evaluation for example.

In general, from a data protection standpoint, it is better to prevent something undesirable rather than monitoring to make sure that it does not happen. The simple logic is of course that in order to detect something you must monitor it and in doing so will process other, potentially personal, infomation. Such processing need not take place if prevention is implemented.

The ODP has an advisory role at CERN. It provides expert guidance to help services implement data privacy obligations correctly and in line with CERN’s internal rules. However, the ODP does not have the authority to issue binding instructions or make decisions on behalf of a service.

Ultimately, each controlling service remains fully responsible and accountable for its own processing activities and for the decisions it takes in that context. While ODP recommendations are not mandatory, they reflect best practices and are intended to support compliant, efficient, and risk‑aware processing. Implementing them is therefore strongly encouraged to ensure alignment with CERN’s data privacy framework.

The revised OC 11:

• Aligns CERN’s rules more closely with recognised international data protection best practices, including the EU General Data Protection Regulation (GDPR),
• improves legal certainty and reduces legal and reputational risks,
• simplifies implementation for Services while maintaining a high level of personal data protection, and
• ensures technological neutrality and supports the long-term viability of CERN’s various activities.

Key areas of modernisation

Among the various updates introduced, the revision highlights ten key areas where clarification or simplification was most needed

Looking ahead

With this revision, CERN confirms its commitment to protecting personal data through a modern framework designed to keep pace with evolving technologies and collaborative research environments, while maintaining a high level of protection and ensuring continuity, clarity and proportionality in practice.

The European Organization for Nuclear Research (CERN) is an intergovernmental organisation based in Geneva, Switzerland. Due to its specific legal status, CERN benefits from privileges and immunities under international law. As a result, CERN is not subject to national or supranational data protection laws, including the EU General Data Protection Regulation (GDPR).

The European Data Protection Board (EDPB), in its Guidelines 3/2018 on the territorial scope of the GDPR (Article 3), also clarifies that the GDPR does not affect the application of international law, including provisions governing the privileges and immunities of international organisations.

Furthermore, with regard to data transfers from the European Union to CERN, the Organization — by virtue of its intergovernmental status and associated privileges and immunities — is not subject to the Standard Contractual Clauses (SCCs). This interpretation is confirmed by the European Commission in its Q&A on the SCCs (Question 25).

Instead, CERN processes personal data exclusively in accordance with its own internal legislation. Its data protection framework is based on principles established in its Member States and, more broadly, within the European Union, and is implemented through appropriate technical and organisational measures. CERN will handle any requests in accordance with its internal procedures.

CERN has appointed a Data Privacy Adviser (DPA), who acts as the central point of expertise for all data protection matters within the Organisation. Because CERN is not subject to national jurisdictions, any disputes related to the processing of personal data are handled under its internal rules or, where necessary, through arbitration.

Further information on CERN’s approach to data protection is available in its Data Privacy Protection Policy.

The Data Subject is the individual whose personal data you are processing. Your relationship with the individual can effect the risks involved in ensuring that data are processed in a correct manner. Broadly, we can define 4 categories:

1. A direct, transactional relationship with the individual, for example secretariats dealing with the processing of staff, users, visitors etc.
2. A direct, long-term relationship with the individual, for example the pension fund.
3. An indirect, visible relationship with the individual, for example a service processing on behalf of another service.
4. An indirect, invisible relationship with the individual, for example the processing of computer logs.

When completing the RoPO for your Service, you should consider how you are processing and informing the data subjects whose personal data you are processing.

When creating a new Service, the following steps should be considered:

• Register the Service
  The Service must first be registered in the CERN Service Catalogue.

• Identify processing activities and roles
  Service designers must identify the planned processing operations and any potential privacy issues. They must also determine whether the Service acts as a Controlling Service and/or Processing Service of personal data.

• Apply data minimisation and privacy by default
  Services must be configured by default to ensure the minimum necessary collection, processing, and sharing of personal data. This includes limiting data transfers into and out of the Service. Where applicable, such processing activities and data transfers must be documented in the Record of Processing Operations (RoPO).

• Document processing activities (Controlling Service role)
  If the Service acts as a Controlling Service, a RoPO must be completed and reviewed with the relevant stakeholders, including the Office of Data Privacy (ODP).

• Assess and mitigate risks
  If the processing is likely to result in a high risk in the absence of mitigation measures, prior consultation with the ODP is required to determine whether a Data Privacy Impact Assessment (DPIA) must be carried out.

• Ensure security throughout the lifecycle
  Appropriate security measures must be put in place to protect personal data throughout the entire lifecycle of the Service. When the Service is discontinued, all related personal data must either be securely transferred to a competent Service or permanently deleted so that it is no longer accessible.