Privacy Engineering: GDPR, Swiss nDSG & Privacy by Design

Privacy engineering turns data protection law into features, schemas, pipelines and defaults that behave the way the privacy notice promises. This lesson maps the field, translates the EU GDPR and the Swiss nDSG into engineering requirements, and walks through a complete review of one small app feature – data flow, legal basis, risks and measures.

• 12lessons in the course
• 7GDPR principles turned into engineering questions
• 1feature reviewed end to end in this lesson
• ~22 minreading time for this lesson

What privacy engineering is – and how it differs from security

Personal data is any information relating to an identified or identifiable natural person. "Identifiable" is the key word: a device ID, an IP address or a location trail can identify someone without a name. Processing is almost anything you do with it – collect, store, log, send to a vendor, train a model, delete.

Security asks: can an attacker get at the data? Privacy asks more: should this data exist, should we use it this way, and does the person know? A perfectly secured database is still a privacy failure if it holds data nobody needed or keeps it forever. Privacy protects people from the organisation as well as from attackers.

Who does what: controller, processor, data subject

The controller decides why and how personal data is processed – usually the company whose product you build. A processor processes data on the controller's behalf and instructions: the cloud host, the email service, the crash reporter. The data subject is the person the data is about. Roles follow facts, not contract titles; Lesson 3 goes deeper.

Two laws, one engineering job: GDPR and the Swiss nDSG at a glance

The GDPR applies to organisations established in the EU and to organisations elsewhere that offer goods or services to people in the EU or monitor their behaviour there. The revised Swiss Federal Act on Data Protection (nDSG, revDSG or FADP) has applied since 1 September 2023 and covers processing with an effect in Switzerland, even when it starts abroad. A Swiss app with users in Germany usually has to think about both.

The two laws share most principles, and for an engineer most of the day-to-day work is identical: know your data, have a purpose, minimise, secure, delete on time, respect people's rights. The differences sit mainly in the legal mechanics. The table is a simplified overview – precise conditions are a matter for counsel.

The mental model: principles as engineering requirements

Article 5 of the GDPR lists the principles everything else builds on; the nDSG has closely related ones in Article 6. Engineers should read them as requirements that can be designed, tested and reviewed.

Privacy by design means these questions are answered while the feature is designed, not after it ships. Privacy by default means the out-of-the-box setting processes only what is necessary: sharing starts off, profiles start private, retention starts short.

• Purposewhy the feature needs data at all
• Datathe minimum set, at the coarsest useful precision
• Basiswhich legal ground carries this flow
• Riskwhat could harm the person
• Controlsdesign, defaults, security, retention
• Proofrecords a reviewer can check

Worked example: a privacy review of a "Nearby running partners" feature

Here is a realistic design review, worked from start to finish. The company is fictional; the method is the one you will reuse throughout the course.

1. Pin down the purpose. One sentence a user would recognise: "Help runners who opted in find people with a similar pace who run nearby at similar times." Note what is not the purpose: advertising, movement profiles, selling insights.
2. Draw the data flow. Every hop: device, API, matching service, push provider, the other phone, logs, analytics – and which systems belong to vendors (Figure 2).
3. Inventory each data item. Needed for the purpose? At what precision? For how long? Who sees it?
4. Choose and record the legal basis with counsel, check the nDSG principles, and plan how users are informed.
5. List the risks to people – being located, followed, profiled or exposed – not risks to the company.
6. Design measures and defaults: less data, coarser data, shorter retention, opt-in, rate limits, access rules.
7. Write it down in a short review record linked to the ticket.

Step 3 in detail: the data inventory

The best measures cost nothing: dropping heart-rate matching removed a whole category of sensitive data. Minimisation is the cheapest control – if it happens before the schema exists.

Step 4: legal basis and transparency – the same feature through three lenses

Steps 5 and 6: risks to people and the measures that answer them

R3 stays medium on purpose: self-declared ages are imperfect, and an honest residual risk beats a table full of "Low".

Step 7: what you should end up with

The output is not a long document but a short, versioned record next to the code:

# privacy/reviews/nearby-partners.yaml  (example review record)
feature: nearby-running-partners
purpose: "Help opted-in runners find people with similar pace nearby"
not_purposes: [advertising, movement profiles, resale]
data:
  - item: location_cell        # 1 km grid cell, computed on the device
    retention: 24h
    visible_to: [matching-service]
  - item: pace_band
    retention: until profile deleted
    visible_to: [matching-service, matched-users]
dropped: [precise_gps, exact_distance, birth_date, heart_rate_history]
legal_basis:
  gdpr: "explicit opt-in / consent (counsel decision 2026-10-12)"
  ndsg: "principles respected; information at collection; default off"
processors: [push-provider]          # generic payload only
residual_risks:
  - id: R3
    level: medium
    reason: "self-declared age"
dpia: required                       # positions visible to strangers
owner: product-privacy@example.com

This file feeds the record of processing (Lesson 3), the impact assessment (Lesson 4) and the purge jobs (Lesson 9).

Under the hood: why coarse location is harder than it looks

"Round the coordinates" sounds trivial. It is not. One degree of latitude is about 111 km everywhere, but longitude shrinks with the cosine of the latitude: at Basel, 0.01° of longitude is about 0.75 km, 0.01° of latitude about 1.1 km. A cleaner approach snaps positions to roughly equal-sized cells and sends only the cell centre:

import math

def snap(lat, lon, cell_km=1.0):
    """Return the centre of the ~cell_km grid cell that contains (lat, lon)."""
    dlat = cell_km / 111.32                        # ~111.32 km per degree of latitude
    c_lat = (math.floor(lat / dlat) + 0.5) * dlat  # snap latitude first
    dlon = cell_km / (111.32 * math.cos(math.radians(c_lat)))  # use the CELL latitude
    c_lon = (math.floor(lon / dlon) + 0.5) * dlon
    return round(c_lat, 4), round(c_lon, 4)

for p in [(47.5584, 7.5733), (47.5590, 7.5700), (47.5640, 7.5733)]:
    print(p, "->", snap(*p))

Output (computed with Python 3):

(47.5584, 7.5733) -> (47.5611, 7.568)
(47.559, 7.57) -> (47.5611, 7.568)
(47.564, 7.5733) -> (47.5611, 7.568)

Three positions up to about 600 metres apart become the same cell – which is the point. Two subtle bugs matter. Computing the longitude step from the user's latitude instead of the cell's makes the "coarse" value vary slightly with the exact position, quietly leaking detail. And a cell only hides a position if it is snapped on the device; a precise value sent "to be snapped on the server" already sits in request logs and proxies.

If the app showed exact distances, someone could move around and query repeatedly to narrow down another person's position. The defence is design: distance bands computed from cell centres, limits on how often a user may move and search, and alerts on accounts that query from many cells quickly. Lesson 5 turns these into a reusable pattern catalogue.

A second, deeper example: personal data in logs and analytics

The first example was a new feature. The second is existing plumbing – where most unexpected personal data lives. Logs collect emails, IPs and tokens because developers log whole requests; analytics events carry user IDs that are joined back to accounts. Both are usually kept far longer than anyone decided.

Part 1 – redact at the source, not in the log platform

Redaction belongs in the application, before a line is written; otherwise every later system – shippers, vendor storage, backups – holds the raw values. Python's logging filters can rewrite a record first:

import logging, re

EMAIL = re.compile(r"[\w.+-]+@[\w-]+\.[\w.]+")
IPV4 = re.compile(r"\b(\d{1,3}\.\d{1,3}\.\d{1,3})\.\d{1,3}\b")
TOKEN = re.compile(r"(token=)[A-Za-z0-9._-]+")

class RedactFilter(logging.Filter):
    def filter(self, record):
        msg = record.getMessage()          # merge args into the message first
        msg = EMAIL.sub("[email]", msg)
        msg = IPV4.sub(r"\1.0", msg)       # keep the /24 network, drop the host part
        msg = TOKEN.sub(r"\1[redacted]", msg)
        record.msg, record.args = msg, None
        return True

handler = logging.StreamHandler()
handler.setFormatter(logging.Formatter("%(levelname)s %(message)s"))
handler.addFilter(RedactFilter())

log = logging.getLogger("api")
log.addHandler(handler)
log.setLevel(logging.INFO)

log.info("login ok user=%s ip=%s url=/sync?token=%s",
         "anna@example.com", "192.0.2.147", "eyJhbGciOi.abc123")

Expected output (Python 3):

INFO login ok user=[email] ip=192.0.2.0 url=/sync?token=[redacted]

The filter calls getMessage() first, so values passed as arguments are redacted too; it keeps only the network part of the IP, often enough for abuse detection; and it removes the token, which is also a credential. Pattern redaction is a safety net, not a design – the real fix is to stop logging whole URLs and user objects.

Part 2 – pseudonymise the analytics identifier properly

Replacing the email with a hash looks like an easy win. It is a trap: a plain hash is deterministic, so anyone with a list of candidate emails can hash and compare. A keyed hash (HMAC) needs a secret key to compute or test values.

import hashlib, hmac

email = "anna@example.com".strip().lower()

# 1) Plain hash: anyone who can guess the input can recompute it
plain = hashlib.sha256(email.encode()).hexdigest()
print("sha256 :", plain[:16])

# 2) Keyed hash (HMAC): without the key nobody can recompute or test guesses
KEY = b"demo-key-load-me-from-a-secrets-manager"
pseudo = hmac.new(KEY, email.encode(), hashlib.sha256).hexdigest()
print("hmac   :", pseudo[:16])

Output (first 16 hex characters, computed with Python 3):

sha256 : f7d54c22dda5b178
hmac   : 0cbd45a07a9ff210

Anyone can reproduce the first value from the address alone; the second needs the key. Keep the key in a secrets manager outside the analytics environment and plan rotation – a new key breaks linkability with old data.

Be precise: the data is now pseudonymised, not anonymous. The company holds the key, so under both laws it remains personal data. Pseudonymisation reduces risk; it does not take data out of scope. Lesson 6 covers techniques that approach real anonymisation and their limits.

What went wrong if you see this

Seeing the effect: the risk picture before and after the review

A risk matrix shows stakeholders what a review achieved: likelihood from left to right, severity for the person from bottom to top.

Most measures move a risk to the left – less likely – while the harm to someone who is actually stalked stays the same. Only minimisation (coarser or removed data) moves risks downward. That is why reviewers ask "do we need this data?" before "how do we protect it?".

Common mistakes in privacy engineering – and better habits

The same misconceptions appear in almost every team that starts taking privacy seriously. Two deserve a sentence each. "We hashed it, so it is anonymous" is wrong: hashed, encrypted or tokenised data that anyone can link back is still personal data. "Consent solves it" is wrong too: consent is one legal basis among several, it can be withdrawn at any time – so the system must really stop – and it never cures collecting data the feature does not need.

Troubleshooting: symptoms, causes and fixes

Typical findings when a team first tests its privacy promises:

How experienced privacy engineers work

Professionals triage fast, go deep only where people could be harmed, and verify the running system rather than the design document:

1. Intake – about 15 minutesNew personal data? New purpose? Sensitive data or children? New vendor or country? Visible to others? All no: record the triage and move on.
2. Design review – one to two hoursThe seven steps of the worked example.
3. Impact assessment – when risk is highNecessity, risks, measures, residual risk, sign-off (Lesson 4).
4. Build – every pull requestSchema changes carry purpose and retention; tests check redaction, deletion and consent gating.
5. Pre-launch – half a dayInspect what really leaves the device and backend; compare with the review record and notice.
6. After launch – recurringProve purge jobs ran, run a test access request, re-review when purpose or vendors change.

Thinking errors of advanced practitioners

Experienced people trust the diagram over the traffic (three services on the slide, seven third-party hosts in the capture), gold-plate until teams route around review, stop at the database while copies live in the warehouse and backups, and argue law instead of design when removing the data would make the question disappear.

The defender's view: privacy controls that also stop attackers

Every record you do not collect cannot leak, and every purpose-based access rule also limits a compromised account.

• Purpose-based access: support sees ticket fields through a view, not raw tables.
• Access logging: record who read which customer record and why; alert when one account exports 50,000 profiles at 03:00.
• Canary records: a fictional customer no legitimate process touches – any read is a strong signal.
• Breach readiness: the GDPR's 72-hour window (where feasible) and the nDSG's "as soon as possible" assume you can quickly tell whose data was affected – only a current data map makes that possible.

A minimal example of purpose-based access in PostgreSQL – the support role gets a narrow view instead of the table:

-- Support may see contact details, never location or chat content
CREATE VIEW support_customer AS
  SELECT id, first_name, email, created_at
  FROM customers;

REVOKE ALL ON customers FROM support_role;
GRANT SELECT ON support_customer TO support_role;

Test it: as support_role, SELECT * FROM customers; should fail with "permission denied", while the view returns four columns. Lesson 10 adds encryption, key separation and breach response.

Check yourself: privacy engineering basics

You can now…

• Define personal data – and why "identifiable" matters more than "named".
• Assign roles – controller, processor, data subject.
• Compare GDPR and nDSG at overview level and know what to ask counsel.
• Translate the seven principles into engineering controls.
• Run a seven-step feature review and write the record.
• Coarsen location correctly – on the device, with distance bands.
• Redact logs at the source, including arguments and tokens.
• Prefer a keyed hash – and know it is still personal data.
• Triage features with five intake questions.

Glossary

For the primary sources, the Swiss act is published on Fedlex, and the FDPIC website publishes guidance for Swiss organisations.