This article is a practical engineering checklist, not legal advice. Decisions on legal bases and contracts belong with your counsel and data protection officer.

Which law applies?

  • The nLPD applies to the processing of personal data of natural persons with an effect in Switzerland. It no longer covers data about legal entities.
  • The GDPR applies to companies established in the EU, and also to companies outside the EU — Swiss ones included — that offer goods or services to people in the EU or monitor their behaviour. In some of these cases an EU representative must be appointed.

A Ticino company with customers in Lombardy is a typical case where both apply. The pragmatic approach is to design to the stricter requirement wherever they differ.

The principles that shape architecture

Know what you process: the data map

You cannot protect what you have not mapped. For each system involved in a project, record which categories of personal data it holds, for what purpose, where it is stored, who can access it and how long it is kept. Under the nLPD a record of processing activities is required, with an exemption for companies with fewer than 250 employees unless the processing carries a high risk. Under the GDPR the record is the norm. Either way, the map is the foundation of every other decision.

Privacy by design and by default

Both laws require data protection to be built into systems, not added afterwards. In engineering terms:

  • collect only the fields the purpose needs;
  • restrict access by role, and log it;
  • pseudonymise or anonymise data used for analysis and testing;
  • define retention periods and actually delete data when they expire;
  • make the most protective setting the default.

Processors and the supplier chain

Cloud providers, SaaS tools and AI services usually act as processors on your behalf. Both laws require a written agreement that binds them to your instructions and to adequate security — the data processing agreement, or DPA. Check the whole chain: a SaaS tool may itself rely on sub-processors in other countries. The same obligations must flow down to every link.

Cross-border transfers

Transfers abroad are allowed to countries the Federal Council (for the nLPD) or the European Commission (for the GDPR) recognises as providing adequate protection. Elsewhere, additional safeguards are needed, typically standard contractual clauses and an assessment of the risks in the destination country. For the United States, transfers to companies certified under the Swiss-U.S. and EU-U.S. Data Privacy Frameworks are possible on that basis.

The question to ask a provider is concrete: in which countries is our data stored, processed and accessible, including for support and administration? This is also where a sovereign cloud setup with explicit data residency simplifies the analysis.

Security, breaches and impact assessments

  • Security measures must be appropriate to the risk: encryption, strong authentication, network segmentation, backups, patching.
  • Data breaches that are likely to pose a high risk must be reported to the Federal Data Protection and Information Commissioner (FDPIC) as soon as possible under the nLPD; the GDPR sets a 72-hour deadline for notifying the competent supervisory authority. A tested incident procedure is what makes these deadlines achievable.
  • Data protection impact assessments are required when a processing operation is likely to result in a high risk — large-scale processing of sensitive data, systematic monitoring, some uses of AI.

Specific questions for AI projects

AI adds a few questions of its own:

  • Where are prompts and documents processed? Public AI services may process them abroad and, depending on the terms, retain them. Check the contract, not the marketing page.
  • Is your data used to train the provider's models? It should not be, unless you have decided otherwise.
  • Can people get an explanation? The nLPD gives individuals rights regarding automated individual decisions with significant effects. Keeping a person in control of critical decisions is good practice and good compliance.
  • What about the EU AI Act? It entered into force in 2024 and applies in stages, with obligations depending on the risk category of the system. Swiss companies can be affected when they place AI systems on the EU market or when their outputs are used in the EU.

When the answers to the first two questions are unsatisfactory, running models on your own infrastructure removes the problem at the source.

A checklist for your next project

  1. Map the personal data the project touches.
  2. Decide and document where data resides and who holds the encryption keys.
  3. List every supplier and sub-processor; sign DPAs that carry the same obligations down the chain.
  4. Assess cross-border transfers and document the safeguards.
  5. Apply privacy by design: minimisation, role-based access, logging, retention.
  6. Run an impact assessment when the risk is high.
  7. Write and test an incident procedure with the notification deadlines in mind.
  8. Keep the documentation current — it is what an audit, or a customer's security questionnaire, will ask for.

Our sovereign cloud and cybersecurity service produces exactly this documentation alongside the technical work, so that compliance is a by-product of the architecture rather than a separate exercise.