Umsetzung des revidierten DSG – daten:recht – das Datenrechts-Team von Walder Wyss

Laws

Privacy

Implementation of the revised DPA

Privacy FAQ

latest articles

LfDI Baden-Württemberg: Questions about ChatGPT

BayLDA: Brief information “Spring cleaning in the processing directory”.

ECJ, C‑307/22: Advocate General – Right to information also for preparation of proceedings, but copies of documents only in exceptional cases

EDSA: Guidelines on deceptive measures in social media.

EDSA: Clarifications in the final version of the guidelines on the right to information

Federal Council: DSA à la Suisse – large communication platforms to be regulated

EDSA: Version 2 of the Breach Notification Guidelines: no concentration at the EU representative.

FDPIC: Guidance on the use of “AI-supported applications

ECJ, Case C‑34/21: Opening clause of Art. 88 GDPR

Federal Act on the Use of Electronic Means for the Performance of Official Duties (EMBAG): adopted in final vote

Instructions
Processing directory
Information
Contracts
Foreign transmission
High-risk machining
More points

Implementation of the nDSG

In the meantime, empirical values have formed as to how data protection law is to be implemented. Especially for large companies and companies in a complex or regulated environment, numerous other questions will arise. But as we all know, even the longest journey begins with the first step.

Checklists for SMEs

Not only large companies have to implement the new data protection law, but also SMEs. There are only marginal exceptions for SMEs in the nDSG – most of the requirements also apply to them. However, the expectations for the standard of implementation are different. We have therefore drawn up a checklist for SMEs. It is designed for simpler circumstances and private companies (not for public bodies). It does not claim to be complete and does not constitute legal advice.

Implementation for larger companies

In the case of larger or internationally active companies, it can often be assumed that the GDPR will be implemented, insofar as this is possible. Accordingly, such companies ask themselves less which requirements of the new DPA and more where differences exist between the GDPR and the nDSG. For this purpose, we provide a guide:

Instructions

The revised law no longer trusts companies to ensure data protection without creating a certain structure and organization. It is still much more principle-oriented than the GDPR, but certain processes and framework conditions must be documented.

Data protection instruction

First, a company should set out the principles of its handling of personal data in a internal guideline (policy) regulations. This is not mandatory, but makes sense for several reasons:

A policy defines the organization of the company in the area of data privacy, and in particular also the internal persons in charge and responsibilities. Thus, a policy is also an element of correct delegation and thus relief for the management bodies.
A policy helps to communicate the company’s commitment to appropriate data protection internally.
It is foreseeable that companies will be asked more often for a policy by customers and possibly in the event of an acquisition.
If a data breach happens, a policy helps defend it, or at least argue that you didn’t completely disregard data privacy.

As part of the policy, the company should therefore consider, among other things, who should be responsible for what. This also raises the question of what know-how and resources are available internally and what should be purchased. A question of organization is also the appointment of a Privacy Advisor (this is more or less equivalent to the “DPO” of the GDPR). You don’t have to appoint a data protection advisor, but it can be useful, especially for companies with sensitive data and those with special customer expectations.

Other policies and instructions

Whether further policies, directives or guidance are required depends on the complexity of the organization and its business model.

In any case, it makes sense to have a policy for Data deletion. Notes on this can be found below.

Also the handling of Data security breaches is essential. On the one hand, the revDSG introduces an obligation to notify security breaches to the FDPIC or the data subjects under certain conditions. Only a limited period of time is available for this. Second, mishandling security breaches leads to reputational risks. Companies must therefore consider how they can ensure that security breaches are discovered quickly and taken up or escalated internally.

Also useful can be a general Instruction The aim should be to provide the simplest and most concrete information possible on how to deal with unusual situations, such as a security breach, a request for information or the use of new software.

Todos

Preparation of a draft policy with the essential principles of data protection in the company
Coordination with internal affected persons – whoever is given a task must accept it and be appropriately prepared for it (and have the necessary resources)
Consideration of whether additional policies or instructions are appropriate, e.g., for data deletion or handling of security breaches.
If necessary, elaboration of further policies or instructions

Processing directory

The revised law deliberately refrains from imposing a separate, general duty to document processing operations or the associated decisions. However, the legislator still provides for so-called accountability obligations in certain areas. These include, for example, the obligation to retain data for the data protection impact assessment or logging, but above all the obligation to keep a processing directory.

Content of the processing directory

The processing directory is a directory of the processing activities of a company. It is not a catalog of individual data (e.g. the names of all customers), but a list of the way in which data is processed. The law does not define “processing activity”, but it is about data processing with a similar purpose and comparable framework. The directory should not be too granular, because it should be self-explanatory and provide an understandable picture of the processing activities – this is not achieved with hundreds of entries. For an SME, it should rather be 10 – 15 activities.

Responsible parties and order processors must both maintain a directory, but it differs greatly in content. Responsible have per machining activity the following points to record – these are the points that describe a processing operation in terms of data protection law and characterize its risks:

Company name and address of the person responsible (i.e. the company, not, for example, the persons responsible for filling out the directory)
in each case, the purpose of the machining (what is it for, why does it exist at all)
Categories of data subjects (e.g. employees, applicants, contact persons of customers, end customers, etc.)
Categories of personal data processed (e.g. master data, transaction data, contract data, etc.)
Categories of recipients (e.g. IT service providers, group companies, authorities, partners, etc.)
The retention period or the criteria for determining the duration (preferably by reference to a deletion concept; otherwise e.g. “six months from X”, “11 years from X”, “indefinite”, etc.)
Description of the data security measures (e.g. by referring to a document with the relevant information);
if data is or will be disclosed abroad: a list of these countries (this also includes countries in Europe and all disclosures, including those to service providers). If a disclosure is based on the standard contractual clauses (or another data transfer contract), this should also be mentioned.

Order processor may make things a little easier for themselves, they only have to keep a list of the persons responsible for whom they process data on behalf of and describe the types of processing on behalf of. In addition, they must also record the information on data security and on disclosure abroad.

Type and form of the directory

The law says little about the form of the directory. However, it does not have to be signed, nor does it have to be audit-proof. The requirements of the GebüV for the storage of accounting documents do not apply either. The following are therefore possible

an Excel or Word document, locally or in Sharepoint or other platform
Tools that are often already in use anyway, e.g. Confluence or Notion
specialized tools from appropriate providers

More important than the form is the question of how the directory can be kept up to date. This requires an internal process, which can vary depending on the size and complexity of the organization. In many cases, it is sufficient to issue an instruction – in a formal directive or even in a short handout for employees – that a specific person is to be informed in the event of new or changed processing. In larger companies, it is more appropriate to make appropriate additions or adjustments to existing processes – for example, it can make sense to link the processing directory to processes that have already been defined and to have employees consult the directory in the event of adjustments or new processes so that gaps can be identified and closed. Random checks by data protection authorities are also a possibility – however, these are not explicit requirements, but rather questions of a functioning compliance organization depending on the company.

Exception for SMEs

SMEs are exempt from the obligation to keep a processing directory. However, this only applies to SMEs with less than 250 employees (as of January 1 in each case). Such SMEs may voluntarily keep a register, but in principle do not have to do so. It may well make sense to keep a directory voluntarily, provided that the edits are not so trivial that they are also so clear.

However, such SMEs must also keep a register if they carry out particularly risky processing, i.e. if they extensively process particularly sensitive data (e.g. health data) or if they carry out “high-risk profiling”. In this case, they do not have to record all but these sensitive processing operations in a directory.

Todos

Checking whether the exemption for SMEs applies – if so, whether a directory should still be kept
Determining the format – simpler is usually better
Elaboration of a template and, if necessary, a short instruction for it
Determination of the procedure for the initial filling and subsequent updating of the directory.
Recording of the directory, i.e. the processing activities – this usually requires the involvement of the business, HR and IT, e.g. in a workshop

Information

The current FADP only requires explicit information about the processing of personal data in exceptional cases (when particularly sensitive personal data such as health data or personality profiles are obtained). In most cases, it is sufficient if processing is self-evident.

This changes with the revised law. Analogous to the GDPR, the law requires information for all processing unless an exception applies. This even applies to self-evident and trivial processing. This does not help anyone, but a violation of this obligation can even be punishable.

Companies should therefore provide information about their processing, usually in the form of data privacy statements. These are notices or documents that comment on data processing – they are not part of the contract and should not generally be part of GTCs.

Privacy statements

Which and how many privacy statements are required depends on the business model. In most cases, however, it will be something like the following:

a general privacy policy provided on the website that covers most processing, e.g. handling end customer data, customer and supplier contact data, marketing, working with partners, etc;
a separate cookie notice that explains how personal data is handled via the website(s) and, if applicable, apps. It can be part of the general privacy statement, but a separate statement is often more in line with expectations;
a privacy policy for employees. It can also comment on job applicants, provided that a separate privacy policy is not used here.

Another question is how data subjects (i.e., individuals whose data is being processed) are made aware of the appropriate privacy policy. There is no one-size-fits-all solution for this – the interfaces with the data subjects are decisive. However, it makes sense to provide information

in contracts, at least in contracts with end customers (GTC) and in employment contracts or regulations,
in the footer of the website and in apps,
in correspondence with data subjects, e.g. in an e‑mail signature, invoices, order forms, etc. Here, existing customers whose data was obtained before the new law came into force can and should also be made aware of the data protection declaration.

Does it need consents?

Consents are not frequently required under Swiss data protection law.

However, consent must be considered when particularly sensitive data (e.g., health data) is passed on and in the case of e‑mail marketing.

Todos

Elaboration of the privacy statements – for this purpose, samples are available, which are suitable as source material with the necessary adaptations. A detailed sample can be found here, and more patterns are available
Considerations regarding references to data protection statements, e.g. in contracts and sample correspondence
If necessary, consideration of adjustments to data processing, e.g., replacing or discontinuing certain analysis tools on websites.

Contracts

The revised DPA requires the conclusion of contracts in certain cases. This results from the fact that the DPA distinguishes between different roles of companies.

Responsible persons and order processors

The “Responsible” is the company that processes data or has data processed in its own interest and that determines this processing. For example, a company is a controller of the processing of the data of its employees and its (end) customers.

One “Order processor” also processes data, but only as a service provider for a controller. A contract processor is, for example, a hosting service provider or the provider of a cloud-based software solution: Here, the controller determines the type and manner of data processing. However, some service providers are also controllers – when they largely decide on the type of data processing themselves. One example is a law firm.

Order processing

Because these roles differ so much in processing, so do the duties under data protection law. The controller must comply with the full range of obligations of the DPA (which is why he is also called the “controller”). An order processor does not have to and cannot do this to the same extent, because he is controlled to a certain extent by the controller – he is, so to speak, his extended arm.

However, this also requires that the data controller and the data processor regulate their relationship contractually. For this purpose, they must conclude a so-called order processing agreement – rules, for example, on the right of the controller to issue instructions, his right to check the data processing, and the obligation of the order processor to ensure data security and to delete data at the end of his order.

If such a contract is missing when processing an order, this may be punishable under the revised DPA. The controller must therefore ensure that he has concluded or will conclude such contracts. This is usually the case with providers of standard solutions – they include such contracts in their standard contracts. With other providers, however, they may be missing.

And it is not uncommon for such contracts to be missing, especially within a group, if a company operates central services such as a CRM system within the group. Other points may also need to be regulated within the group, e.g. the deployment of employees from one company to another.

joint responsibility

In addition to order processing, there is also joint responsibility when several companies make joint decisions about processing. The concept is abundantly unclear, but within a group, joint responsibility is common when multiple group companies use the same solution for employee management or a CRM, for example. Shared responsibility is also not uncommon in partnerships where data is processed for a common product.

Unlike the GDPR, the revised law does not explicitly require a separate agreement between the jointly responsible parties. However, it makes sense, because it is often difficult to delineate competences and responsibilities here. It should therefore generally be agreed who will inform the data subjects, who will deal with requests for information, who will ensure data security, etc.

Transmission abroad

An important topic at present is the transfer of personal data abroad. It may also require the conclusion or review of contracts. Separate information on this subject is provided below.

Todos

Review of contractual relationships: Where and for what are service providers involved? Where are there forms of cooperation that represent shared responsibility?
This is to be checked in each case within the group from also for external partners.
Review of existing contracts: Do they exist? Are they reasonably up-to-date? Do they already contain the necessary data protection provisions?
Adjustment or new conclusion of contracts, insofar as the required data protection provisions are missing or insufficient
If necessary, elaboration of own templates for the above step
For service providers: Checking whether the required guarantees are met, especially whether data security is known and sufficient – if necessary, a new check is required here.

Abroad

Data protection law aims to ensure protection. It cannot therefore permit transfers to countries without restriction if the necessary protection is lacking there. Like the GDPR and the current DPA, the revised DPA therefore initially only permits such transfers if the recipient state guarantees adequate data protection. If data is exported illegally, this may be punishable under the revised FADP.

Safe third countries

Adequate protection exists for all EEA States and a few other states (the FDPIC maintains a list of such states, which are Country listwhich is newly listed in the ordinance as an annex).

According to the FDPIC, further measures are currently required for data on legal entities in such countries as well. In practice, this is largely and rightly ignored.

States without adequate protection

At other states such as the USA or India lack an adequate level of protection. Here, a transfer is only permissible if the lack of legal protection is compensated for by the conclusion of an adequate contract with the recipient.

These are almost always the so-called Standard Contractual Clauses or “SCC”, which were drawn up by the EU Commission.

The FDPIC Has accepted this SCC as sufficient. However, it requires that they be adapted to Swiss law in some respects.

There are also exceptions – under certain circumstances, the conclusion of a contract can also be waived for such states. However, these are rather rare exceptions that hardly play a role in the context of the implementation of the revised DPA.

Companies should therefore check whether they disclose data abroad. This will very often be the case – not only when cooperating with companies abroad, but especially with IT service providers. If these service providers are located in a country that does not guarantee adequate data protection, the contracts with them must be checked to see whether they contain the necessary provisions.

Schrems II and “TIAs

The SCCs mentioned, which are to be concluded with data recipients in the USA, for example, are just that – contracts. Unlike local law, they do not bind the authorities. If they have too far-reaching access rights to transmitted data, this is problematic from the perspective of the DPA, because these rights can hardly be limited by the SCC.

The European Court of Justice has therefore ruled (in the infamous “Schrems II” judgment) that an exporter must not blindly rely on the SCC. Rather, he must check the local law, and if this conveys excessive access rights, he must take further measures.

Hardly any other topic is currently so disputed like this. On the one hand, it is unclear whether the exporter can rely on the fact that the local authorities will have no interest in the data he transmits (which will be true in the vast majority of cases). On the other hand, it is unclear how the risk of access can be countered at all, because even technical measures can hardly exclude such access in most cases.

In practice, companies estimate the risks of access by the authorities to be with a form a, and if the probability of access is very low, they have no reason to believe that access will occur. In this case, they rely on the SCC. This approach is not legally secure, but a reasonable alternative is missing.

Todos

Inventory where data is transferred to states that do not have adequate protection
Examination of whether the corresponding disclosure could be waived or whether a service provider could be replaced by a CH/EU provider.
Verification that an agreement exists with the recipient in the relevant unsafe country that includes SCCs
If so, check whether the SCC are up to date and whether they contain the necessary adaptations to Switzerland (e.g. in the form of a standardized addendum, a “Swiss Addendum”).
Conclusion of further contracts (SCC), if applicable

High-risk machining

The law generally follows a risk-based approach. This means that the responsible parties have to adjust their compliance measures in accordance with their assessment of the risks for those affected. In some cases, however, the law specifies higher requirements for particular risks.

personal data requiring special protection

Particularly sensitive personal data is data that The Law refers to as particularly sensitive in a blanket manner. These are

Data on religious, ideological, political or trade union views or activities
Health data
Privacy data
Data on racial or ethnic affiliation
genetic data
biometric data used to identify a person
Data on administrative and criminal prosecutions or sanctions
Data on social assistance measures

In the case of such data, the controller must ensure that disclosure to third parties is justified, e.g. because it is necessary for a contract or with consent.

If consent is required – which is rather an exception – it must also be explicit.

handling of personal data

In some cases, certain additional requirements depend on whether personal data is processed “extensively”. What this means is open; the legislator has not drawn a numerical limit. However, the processing must involve an exceptionally large amount of data, which is also deliberately designed in this way, i.e. the extensive processing must be part of a plan – usually a business model.

Profiling with high risk

A “high risk profiling” is first a Profilingi.e., automated data processing that is used for analysis or forecasting purposes. Examples include information on customer behavior based on transactions.

One “high risk” brings profiling with it when it leads to a personality profile, i.e. allows an assessment of essential aspects of the personality. It has not been clarified when this is the case. To be on the safe side, it should be assumed that a particularly broad data base or a particularly meaningful profiling result may pose a high risk.

Logging

If a controller processes particularly sensitive data extensively and if it carries out high-risk profiling, the corresponding data processing must be logged. If logging is intentionally omitted here, criminal liability is not completely ruled out (cf. here).

It may be necessary to log the storage, modification, reading, disclosure, deletion and destruction of data – reading in particular poses a practical problem.

Logs must also be kept separate from the production system so that they are protected in the event of an attack on that system. They must be kept for at least one year.

Editing regulations

Extensive processing of particularly sensitive personal data or high-risk profiling not only trigger a logging obligation. In addition, in these cases the data controller must Editing regulations lead. Here, too, there may be a certain risk of criminal liability if such regulations do not exist.

A processing regulation is something different from the processing directory. It involves a kind of Manualwhich comments on the internal organization and the architecture and functioning of the systems, as well as on the processing of data along the lifecycle, the guarantee of data subjects’ rights and the technical and organizational security measures.

It is sufficient to refer to existing, other documents, as far as they exist.

Todos

Checking whether personal data requiring special protection are processed (not randomly at the margins, but planned) and how they are processed and shared
Checking whether there is extensive such processing, if applicable
Checking whether high-risk profiling is carried out (by the controller or by a processor).
If yes: Review of further measures; if necessary, also conduct a data protection impact assessment.

More points

In addition to the points mentioned, there are of course other points to consider. Without claiming to be exhaustive: two of the most important points are certainly data deletion and data security.

Data deletion

In general, and already under current data protection law, data may not be retained for longer than there is a legitimate purpose for doing so.

This concerns e.g.

Business purposes that require the processing of data, e.g. in the employment relationship or vis-à-vis customers and suppliers
Business purposes that are not mandatory but legitimate, e.g. storing data for marketing purposes, documentation, compiling statistics, etc.
statutory retention obligations, which may also require retention of personal data, e.g. for accounting purposes, in the tax area and in the employment relationship.

However, if there are no longer legitimate reasons for storing data and there is also no longer a legal obligation to retain it, personal data must be deleted or anonymized. Deletion also has advantages – the risks of a security breach can decrease, the duty to inform is breached less quickly, and requests for information are easier to answer correctly.

In simpler circumstances, this deletion can sometimes be carried out manually, e.g. in the case of applicant dossiers, records of employees who left the company a long time ago, or in the case of former customers if there is no longer a statute of limitations.

However, manual deletion is error-prone and incomplete. Implementing automated deletion routines, however, can be a decidedly challenging, lengthy and costly task, especially for companies whose complex IT has grown organically.

A reasonable middle ground – at least to start with – is usually a combination of a retention and deletion directive with appropriate configuration of the applications. If a system cannot be configured to delete data at a specific time, archiving can provide some substitute.

Data security

The revised law does not tighten the requirements for data security in principle, except for the obligation to report certain security breaches. Criminal liability cannot be ruled out in the event of certain breaches, but this is unlikely at present. What is getting worse, however, is the threat environment. Attacks such as ransomware, CFO Frauds, and others are on the rise, and they are often successful.

It is therefore imperative that companies address the security of their systems. This will often require the use of external specialists. Often, however, even simpler measures can bring about a considerable increase in security, e.g., a check to see whether access rights still correspond to the current roles and functions and whether access rights of former employees have been revoked.

However, this is not the end of the story. Experience shows that it is often employees who are the gateway to a security breach. They must therefore be informed and trained, e.g., to be able to recognize phishing attacks.

Todos

Where outdated data is located with certainty: Start a cleanup (e.g., split folders containing old applicant files).
Clarification of the essential retention periods (a mixture of retention obligations and limitation periods), ideally in a deletion policy
Definition of rules for manual deletion (also in the deletion policy)
Configuration of applications for automatic deletion, as far as possible and reasonable

Todos

If the security measures are not up to date: corresponding check of own systems and interfaces
Training of the employees to an appropriate extent and cycle

Laws

FDPA

GDPR

DPO

DSV in English

draft FDPO

nDSG EN

nDSG with message

FDPO

Privacy

Implementation of the revised DPA

Privacy FAQ

Links

latest articles

LfDI Baden-Württemberg: Questions about ChatGPT

BayLDA: Brief information “Spring cleaning in the processing directory”.

ECJ, C‑307/22: Advocate General – Right to information also for preparation of proceedings, but copies of documents only in exceptional cases

EDSA: Clarifications in the final version of the guidelines on the right to information

Federal Council: DSA à la Suisse – large communication platforms to be regulated

EDSA: Version 2 of the Breach Notification Guidelines: no concentration at the EU representative.

FDPIC: Guidance on the use of “AI-supported applications

ECJ, Case C‑34/21: Opening clause of Art. 88 GDPR

Laws

Pri­va­cy

latest artic­les

Privacy

latest articles