Privacy by Design and Default Questions

Embedding privacy into architecture and the development lifecycle: the privacy-by-design principles, privacy-protective defaults, and on-device or edge processing to minimize data exposure. Covers integrating privacy controls into product and program design and into engineering workflows rather than bolting them on. Includes designing privacy-first solutions and reference architectures.

EasyTechnical

86 practiced

Propose a practical data classification scheme with four tiers (for example: public, internal, confidential, restricted). For each tier define handling rules, encryption and access-control requirements, and retention policy examples. Then explain how you'd implement this classification across relational databases, object storage (S3), and analytics datasets (data lake) so that enforcement can be automated.

Sample Answer

Proposed four-tier classification1) Public- Handling: No special controls; data may be published.- Encryption/Access: Transit TLS; at-rest optional.- Retention: 1–7 years depending on business need; archive via public buckets.2) Internal- Handling: Only company employees; no external sharing without approval.- Encryption/Access: TLS + at-rest AES-256; role-based access (RBAC).- Retention: 3–7 years; auto-archive to lower-cost storage after 1 year.3) Confidential- Handling: Business-sensitive (customer PII, contracts). Need need-to-know and approval for sharing.- Encryption/Access: TLS, at-rest envelope encryption (KMS with key rotation), MFA for admin access, ABAC for fine-grain.- Retention: Policy-driven (e.g., 7 years); automated deletion/secure purge after retention.4) Restricted- Handling: Regulated/high-risk (PCI, PHI). Minimal copying; logging and approval required.- Encryption/Access: TLS, HSM-backed keys, column-level or field-level encryption, strict separation of duties, VPC-only access.- Retention: Shortest legally required window; immutable storage (WORM) where required.

How to implement and automate across stores- Metadata & Tagging: Define classification tags in a canonical schema (sensitivity, retention_period, owner, legal_hold). Require tags at ingest via DLP and data catalog (Glue/Atlas).- Relational DBs: Use schema/column metadata for classification. Enforce via: - Column-level encryption (transparent data encryption or application crypto) for Confidential/Restricted. - Fine-grained access with RBAC/ABAC (IAM + DB roles), dynamic masking, audit logging, and automated retention jobs (scheduled stored procedures) reading catalog retention metadata.- Object storage (S3): Apply object tags and bucket policies. Use S3 default encryption with KMS key policies per classification, IAM conditions for access, S3 Object Lock for Restricted, lifecycle rules driven by tags to transition/archive/delete.- Data lake/analytics: Register datasets in a data catalog (Glue/Hive/Atlas) with tags. Use a policy engine (Ranger/Databricks Unity Catalog) to enforce row/column-level policies, and query-time masking. Prevent accidental export with DLP scans and query governance. Automate retention with scheduled jobs that consult catalog metadata.- Central enforcement: Policy-as-code (OPA/Rego or AWS IAM SCPs) driven from catalog tags; CI pipeline checks (pre-merge) for missing classification; event-driven remediation (Lambda/functions) that quarantine untagged assets, rotate keys, or apply default quarantine policies. Use logging/monitoring (CloudTrail, Audit) and periodic compliance reports.

Why this works- Single source of truth (metadata catalog) + tags enable consistent enforcement across heterogeneous systems.- Combining access controls, encryption, and automated retention protects data while enabling analytics workflows.

HardTechnical

83 practiced

Design a deterministic encryption/tokenization scheme that supports fraud detection which requires consistent tokens across services while reducing re-identification risk. Requirements: tokens must be stable (same raw value -> same token), support key rotation without invalidating tokens, and perform at 1M requests/sec. Discuss algorithms (FPE, HMAC-based tokens), stateless vs lookup tokenization, key-versioning, and performance implications.

Sample Answer

Clarify requirements- Deterministic: same plaintext -> same token everywhere (needed for cross-service fraud signals).- Rotatable keys: must be able to change keys without breaking token matching.- Low re-identification risk: tokens must not allow easy plaintext recovery or cross-correlation.- 1M req/sec: high throughput, low-latency, horizontally scalable.

Proposed solution (stateless deterministic tokenization using keyed HMAC + optional FPE):1) Token format: version||scheme||payload - version: key version id (1 byte or 4 chars) - scheme: algorithm id (e.g., HMAC-SHA256, FPE-AES) - payload: deterministic body (see below), base64/url-safe encoded2) Payload generation (stateless): - Preferred default: truncated HMAC: payload = Truncate(HMAC_K(version, context||plaintext), N) - context = tenant/service identifier + data type to reduce cross-domain correlation. - Truncate to length balancing collision risk and reversibility (e.g., 128 bits). - Option: use FPE (FF1/FF3) when partial reversibility is required for downstream services; FPE uses AES with tweak = context, deterministic.3) Key-versioning & rotation: - Each token includes version prefix. Verification: try current key; if mismatch, try previous N versions. - Rotation process: create new tokens with new version. Lazy re-tokenization: accept old tokens for a configurable window; regenerate tokens on write or access. - Key derivation: master KMS/HSM key -> per-version derived keys (HKDF) to limit exposure.4) Stateless vs lookup: - Stateless (HMAC/FPE): best for 1M RPS: no DB lookup, horizontally scalable, simpler latency. - Lookup tokenization (random tokens mapped in DB): stronger unlinkability and revocation, but needs highly-available, low-latency store (e.g., in-memory cluster like Redis/Scylla) and write amplification — risk for 1M RPS reads/writes. - Hybrid: use stateless tokens for fast read/joins; use lookup for high-value fields (PII) or when revocation/auditing required.5) Fraud-detection considerations: - Use deterministic tokens across services + shared context to enable join signals. - To limit cross-system correlation by attackers, include per-tenant/service context and rotate keys; also consider adding a static salt unique per logical privacy domain.6) Performance & scaling to 1M RPS: - HMAC-SHA256 truncated: cheap CPU ops — one modern core can do hundreds of thousands of HMACs; scale horizontally across instances behind LB. - Use SIMD-accelerated crypto, TLS offload, and keep keys in in-memory secure stores (cache from KMS). - Benchmark: aim for <1ms per token on optimized C libs; with 100 instances at 10k RPS each you get 1M RPS. - Avoid sync KMS calls per request: fetch key material periodically and cache with secure memory.7) Security trade-offs: - Truncated HMAC is irreversible but deterministic; collisions possible if too short—choose >=128 bits. - FPE preserves format but is reversible if key compromised; use FPE only when needed and keep keys in HSM. - Stateless tokens cannot be revoked immediately; mitigate with short rotation windows and optional revocation lists for high-risk tokens (store revocation bloom filter in fast cache).8) Operational & compliance: - Store audit logs of rotations, derivations, and access. - Use KMS with HSM-backed key material, role-based access, and automated rotation policies. - Pen-test for correlation attacks, evaluate entropy and collision rates.

Summary- Use deterministic truncated HMAC with per-tenant context and version prefix as default: stateless, high-performance, low re-identification risk.- Use FPE selectively when format-preserving reversible tokens are required.- Implement key-versioning with lazy re-tokenization, cache derived keys, and scale horizontally to achieve 1M RPS. Trade-offs: stateless favors throughput; lookup offers revocation/strong unlinkability at the cost of complexity and ops overhead.

HardTechnical

68 practiced

Design a company-wide Privacy-by-Design program for a 2,000-employee SaaS company. Include: governance structure, privacy design review gates, architecture guardrails, developer tooling (CI checks, linters), training and awareness, integration with procurement, metrics/KPIs, and a phased rollout plan with estimated cost considerations and staffing needs.

Sample Answer

Requirements & scope:- Protect personal data across product, platform, and corporate systems for 2,000 employees; comply with GDPR/CCPA and customer contractual controls; build repeatable Privacy-by-Design (PbD) into SDLC, procurement and infrastructure.

Governance:- Privacy Council: CPO (chair), CTO, Head of Security, Head of Legal, VP Product, Head of Procurement, two engineering leads. Meets biweekly.- PbD Working Group: privacy engineers, solution architects, SRE, QA, one product owner — executes program.- RACI for decisions, escalation path to Exec Risk Committee.

Privacy design review gates (aligned to SDLC):- Concept/Requirements: Privacy Impact Assessment (PIA) checklist + data mapping.- Design: Threat model & data flow diagram; choice of data minimization/encryption patterns.- Pre-implementation: Design review sign-off from PbD WG; automated policy checks added to branch.- Pre-release: Privacy test suite pass + accessibility of data subject controls.- Post-release: Periodic audit & telemetry review.

Architecture guardrails:- Default-deny for data access; strict least-privilege IAM roles.- Data classification + storage tiers; PII encrypted at rest and in transit.- Tokenization/PSP patterns for sensitive fields; centralized consent and audit log service.- Retention policies enforced by lifecycle jobs; anonymization APIs for analytics.

Developer tooling (CI checks, linters):- Pre-commit hooks and linters flag: hardcoded secrets, PII logging, use of unapproved cloud storage.- CI pipeline gates: SBOM, SCA, privacy smoke tests, automated PIA policy checks (e.g., OpenPolicyAgent rules), regression tests for consent flows.- IaC scanners to ensure encryption and network controls.

Training & awareness:- Role-based curriculum: engineers (secure coding + data minimization), product (privacy requirements), procurement/legal (clauses and vendor risk).- Mandatory onboarding + annual refreshers; tabletop exercises for DSARs and breaches; quick reference cheat-sheets.

Procurement integration:- Vendor risk questionnaire, mandatory DPA & SOC2/ISO evidence for vendors handling PII, automated gating in procurement workflow, centralized vendor register with expiration/controls.

Metrics / KPIs:- Number of services with completed PIAs- % of new projects passing privacy gate at design stage- Time-to-approve PIAs- Number of privacy findings by severity and time-to-remediate- DSAR SLA adherence and mean time to fulfill- % of codebases with privacy linter enabled

Phased rollout (12–18 months):- Phase 0 (0–3m): Pilot — form governance, choose pilot product team, implement basic linters, PIA template, and one consent/audit service. Staffing: 0.5 FTE Privacy Lead + 1 privacy engineer + 0.5 legal + use existing security resources. Cost: ~$150k (tooling, consulting).- Phase 1 (3–9m): Expand — integrate CI checks org-wide, train core teams, IaC scans, procurement integration, add 2 privacy engineers. Cost: additional ~$350–500k (licenses, training, 3 hires).- Phase 2 (9–18m): Operate at-scale — automate reporting, analytics pipelines, embed privacy champions in teams (1 per 8 teams), full vendor registry. Staffing total: ~4–6 privacy engineers, 1 program manager, 1 privacy operations analyst. Annual run-rate incremental cost: ~$1–1.5M (salaries + tooling + audits).

Trade-offs:- Balance developer velocity vs. gate strictness — start with advisory mode then tighten enforcement.- Use a combination of open-source and commercial tools to optimize cost/time.

Why this works (role perspective):- Aligns technical guardrails with product decision points, provides automated developer feedback in CI, integrates procurement and legal, and measures impact with clear KPIs — enabling scalable, architecturally-driven PbD that supports sales assurance and customer requirements.

MediumSystem Design

85 practiced

Design an identity and access model that integrates SSO (SAML/OIDC), RBAC, and ABAC for a multi-tenant SaaS platform where tenants require per-tenant isolation and custom roles. Explain where policies are stored, how tokens propagate role/attribute claims, enforcement points in microservices, and how to audit access at tenant vs resource level.

Sample Answer

Requirements:- Multi-tenant SaaS with strong tenant isolation and per-tenant custom roles- Support SSO via SAML/OIDC- Combine RBAC (roles, permissions) and ABAC (attributes, policies)- Enforce in microservices with centralized policy engine and detailed audit at tenant/resource level

High-level architecture:Identity Provider (IdP: SAML/OIDC) → Auth Service / Token Issuer → Policy Store & Policy Engine (e.g., OPA/Gatekeeper or custom PDP) → API Gateway / Envoy (PDP calls) → Microservices (PEP + local cache) → Audit/Logging + SIEM

Components & responsibilities:1. IdP — authenticates users, provides federation. Maps external groups -> tenant identities.2. Auth Service — issues JWT access & refresh tokens after IdP auth. Enriches tokens with stable claims: tenant_id, user_id, role_ids (assigned per tenant), and a signed attribute-set hash (pointer).3. Policy Store — per-tenant RBAC definitions (roles → permission sets) and ABAC policies (Rego/XACML). Stored in tenant-scoped namespaces in a durable DB (encrypted): e.g., policies/{tenant_id}/roles, policies/{tenant_id}/abac.4. Policy Engine (PDP) — centralized OPA cluster that evaluates RBAC+ABAC using token claims + runtime attributes (resource owner, time, IP). Policy engine reads tenant-scoped policies and caches them with TTL; supports policy versioning.5. PEPs: - API Gateway / Envoy: primary PEP for coarse-grained checks (authN, common authZ via PDP). Validates tokens, calls PDP with input {tenant_id, user_id, role_ids, resource, action, attributes}. - Microservices: lightweight PEP libraries that perform fine-grained checks and call local PDP cache or central PDP for complex policies.6. Attributes propagation: Tokens include tenant_id, user_id, role_ids, and attribute pointers (attribute_set_id + signature). Services fetch runtime attributes from Attribute Service (attribute_set_id) or rely on claims for low-latency checks. Sensitive attributes are fetched with mTLS between services.7. Token design: Short-lived access tokens (JWT) with minimal claims, plus reference to attribute set and policy version. Refresh tokens for re-issue. Token contains policy_version and attribute_hash to detect stale policy/attribute changes.8. Enforcement flow: - Incoming request: Gateway validates JWT, retrieves tenant policies (if cache miss), calls PDP with full input. PDP returns allow/deny + obligations (e.g., mask fields). - Microservice verifies gateway decision and enforces data filtering (ABAC obligations) and resource-level checks (owner matches user_id).9. Auditing: - Every PDP decision is logged with: timestamp, tenant_id, user_id, role_ids, resource_id, action, decision, policy_version, input snapshot. Use structured logs forwarded to centralized audit store partitioned by tenant. - Resource-level audit entries created by microservices for sensitive operations (data changed, cross-tenant attempts). - SIEM/Analytics supports per-tenant queries and global monitors; retain logs per regulatory needs. Use append-only storage and signed entries for non-repudiation.10. Tenant isolation and custom roles: - Policies and role definitions are tenant-scoped; policy store enforces namespace separation and RBAC for tenant admins to manage roles via a Management API that authenticates and authorizes changes. - Policy deployment: tenant admin UI triggers policy updates; system stamps new policy_version and invalidates PDP cache for that tenant, causing tokens with mismatched policy_version to require re-evaluation.Trade-offs:- Central PDP simplifies policy management but requires caching for latency; local caches increase complexity for invalidation.- Embedding many attributes in tokens improves latency but increases token size and revocation complexity—hence hybrid: minimal claims + attribute pointer.This design provides per-tenant customization, scalable enforcement across microservices, and detailed auditability at tenant and resource levels.

MediumSystem Design

95 practiced

Design an architecture to implement GDPR 'right to be forgotten' (erasure) that deletes a user's personal data across production databases, message queues, data lake, analytics outputs, caches, search indices, and backups. Describe detection (data mapping), orchestration (workflow), verification (prove deletion), and challenges related to immutable backups and derived datasets.

Sample Answer

Requirements (clarify): user requests erasure across OLTP DBs, queues, caches, search, data lake/analytics, derived models/reports, and backups. Need verifiable audit trail, configurable scope (full/partial), SLA, and minimal service disruption.

1) Detection / Data Mapping- Maintain a centralized Data Catalog / Metadata Graph (e.g., Apache Atlas, DataHub) mapping PII to data assets, columns, topics, indices, and ML models. Tag all data producers to emit schema+PII tags. Combine automated scanners (regex, fingerprinting) with manual owner annotations. Keep lineage links from source -> transformed datasets -> reports/models.

2) Orchestration / Workflow- Use an Erasure Orchestrator service (serverless/workflow engine like Temporal or Step Functions) that: - Accepts erasure request (user id, scope, timestamp) - Queries Catalog for affected assets and owners - Enqueues targeted deletion tasks: - OLTP: delete/anonymize rows (soft-delete + physical purge async) - Message queues: purge messages by key where possible, or mark as redacted downstream - Cache / search indices: delete keys and reindex affected shards (Elasticsearch, Redis) - Data lake: run targeted rewrite jobs (ETL) to remove/replace PII partitions (Spark/Databricks with ACID tables like Delta Lake/Hudi/Iceberg) - Analytics outputs: refresh materialized views/dashboards or mark redacted - ML models: log model inputs containing PII; flag models for retraining or apply influence-aware unlearning - Coordinates order: remove from sources first, then secondary stores, then analytics. - Tracks state, retries, notifies owners.

3) Verification / Proof- Produce an Erasure Report: per-asset proof entries include before/after checksums, sample queries showing zero results, tombstone records, job run logs, and immutable audit record (append-only ledger). Use cryptographic hashes or signed attestations per deletion task. Expose API for compliance team.

4) Immutable Backups & Derived Data Challenges- Backups: cannot delete immutable snapshots. Approaches: - Maintain encryption per-user keying: delete the user-specific encryption key (crypto-shred) to render backed-up PII unrecoverable. - If crypto-shred impossible, document exception, minimize retention, and ensure legal counsel.- Derived datasets/models: If deletion changes downstream aggregates, either: - Recompute aggregates/materialized views without the user (costly) or - Maintain differential metadata to subtract user's contribution at query time. - For ML, perform targeted retraining or use machine unlearning techniques; if full retraining impractical, document residual risk and mitigation.

Trade-offs & operational notes:- Strong consistency vs availability: real-time full purge may be slow; prefer staged approach with clear SLAs.- Performance: rewrites of large lakes costly — design tables with per-user partitioning or index to limit rewrite scope.- Organizational: require data owners, runbooks, and regular audits. Automate tests in CI for erasure flows.

This architecture balances automation, auditability, and practicality while highlighting technical mitigations for immutable backups and derived data.

Unlock Full Question Bank

Get access to hundreds of Privacy by Design and Default interview questions and detailed answers.

Join thousands of developers preparing for their dream job.