Privacy, Data Protection, and Secure Telemetry

Collect only data needed for a stated purpose.

17.1 Privacy by design

Collect only data needed for a stated purpose. Define retention, access, sharing, deletion, correction, and export behavior. Privacy obligations depend on jurisdiction, data type, sector, and contractual context; involve qualified legal/privacy professionals for compliance decisions.

17.2 Data classification

Example classification scheme:

Restricted / highly sensitive For each class, define allowed storage, access, transmission, logging, backup, and deletion rules.

17.3 Data minimization and retention

Avoid collecting fields “just in case.” Set retention periods.

Remove stale copies and derived datasets.

Consider backups, caches, search indexes, analytics, and exported files.

Use aggregation or pseudonymization where suitable.

Understand that pseudonymized data may still be personal data and can sometimes be re-identified.

17.4 Logging without leaking data

Log security-relevant facts: event type, timestamp, outcome, actor identifier where appropriate, resource category, correlation ID, and source context. Avoid passwords, session tokens, private keys, full payment credentials, and unnecessary personal data.

Sanitize or structure untrusted fields to prevent log forging. Protect logs against unauthorized access and alteration, synchronize time, and define retention.

Redacting before the event leaves the process Output (CPython 3.13.1):

Allowlisting the fields you *do* log is stronger than blocklisting sensitive ones; redaction like this is a safety net for fields that slip through.

import json
import re

SENSITIVE_KEYS = {"password", "token", "authorization", "card_number", "secret"}
EMAIL = re.compile(r"[^@\s]+@[^@\s]+")

def redact(event: dict) -> dict:
    clean = {}
    for key, value in event.items():
        if key.lower() in SENSITIVE_KEYS:
            clean[key] = "[REDACTED]"
        elif isinstance(value, str):
            clean[key] = EMAIL.sub("[EMAIL]", value)
        else:
            clean[key] = value
    return clean

event = {
    "event": "login_failed",
    "user_id": "u-17",
    "password": "hunter2-example",
    "note": "reset requested for [email protected]",
    "correlation_id": "c-9f2e",
}
print(json.dumps(redact(event)))

{"event": "login_failed", "user_id": "u-17", "password": "[REDACTED]", "note": "reset requested for [EMAIL]", "correlation_id": "c-9f2e"}

logredact

17.5 Privacy threat modeling

Unexpected secondary use Inference from telemetry Exposure through logs, analytics, crash reports, or support tools

17.6 Data-subject and deletion workflows

Where required by product commitments or law, build reliable processes for access, correction, export, deletion, and consent changes. Deletion may need to cover primary stores and downstream processors while accounting for legally required retention and backup lifecycle.

Exercise

Design a data inventory for a learning platform: account data, progress, grades, logs, analytics, and support tickets. Define purpose, access, retention, and deletion for each.

Quiz

? Which belongs in a security event log?
+ Event type, timestamp, outcome, actor ID and correlation ID :: Enough to investigate without leaking secrets.
- The submitted password on failed logins :: Never log passwords.
- Full session tokens :: Anyone reading the log could reuse them.
- Full card numbers :: Payment credentials must not be logged.

? Is pseudonymised data always anonymous?
- Yes — names have been removed. :: Other fields can re-identify people.
+ No — it may still be personal data and can sometimes be re-identified. :: The course states this directly.
- Only if hashed with SHA-256. :: Hashing identifiers can often be reversed by enumeration.
- Only in Europe. :: Re-identification is a technical fact everywhere.

? A deletion request arrives. What may need to change? (select all that apply)
+ The primary database :: Obviously.
+ Search indexes and caches :: Derived copies hold the same data.
+ Downstream processors and analytics exports :: Copies outside the main system count too.
- Nothing in backups, ever :: Backups follow a documented lifecycle and legal retention; they cannot simply be ignored.