Data Classification and Sensitivity Handling Questions

Classifying data by sensitivity and applying controls proportionate to that classification: identifying personal, sensitive, and special-category data and tagging it through its lifecycle. Covers classification schemes, labeling, and how classification drives access, encryption, and retention decisions. Includes assessing the impact of a given data type on privacy and security risk.

HardTechnical

28 practiced

The company encourages posting case studies and code samples, but many projects contain IP and customer data. Discuss legal, privacy, and IP considerations when producing public artifacts, and propose a safe process for creating sanitized code, architecture diagrams, and anonymized data while obtaining necessary approvals.

Sample Answer

Key considerations- Legal/IP: NDAs, client contracts, and ownership clauses can restrict disclosure of code, diagrams, and performance metrics. Trade secrets and patented algorithms require extra protection. Open-source license compatibility (MIT/Apache/GPL) must be respected.- Privacy: PII/PHI under GDPR/CCPA/HIPAA must not be exposed. Even “hashed” identifiers can be re-identified if linked to other datasets—apply privacy impact analysis.- Security: Remove credentials, keys, endpoints, internal URLs, and config that reveal infrastructure or attacker vectors.

Safe process (operational checklist)1. Intake & classification - Tag projects as public/internal/confidential during planning. - Maintain an artifacts registry (code, diagrams, datasets) with sensitivity labels.2. Legal & compliance gating - Require a short disclosure request form for proposed public artifacts (what, why, audience). - Legal/Privacy teams review for contract/NDA conflicts and, if applicable, obtain client consent. - Run a Data Protection Impact Assessment (DPIA) for datasets.3. Sanitization standard operating procedures - Code: remove/replace credentials, provider-specific IDs, and customer-specific logic. Replace with generic interfaces and stubs. Add a comment block describing removed elements and why. - Architecture diagrams: abstract service names, replace hostnames/IPs with placeholders, redact internal-only components or show them as "private services". Keep data flows but omit implementation details that reveal vulnerabilities. - Data: never publish raw PII. Use one of: (a) synthetic data generated to match schema and statistical properties; (b) aggressive anonymization with k-anonymity/differential privacy where required; (c) sampled/aggregated metrics only. Document anonymization technique and residual risk.4. Security review & automated checks - Run SAST/secret-scan tools and automated checks in CI before publishing. - Peer review by engineering lead for technical correctness and by privacy officer for data artifacts.5. Licensing & contributor terms - Choose a license consistent with company policy; add CLA or contributor guidelines when accepting external changes.6. Approvals & audit trail - Maintain an approval workflow (submit → legal/privacy/security review → engineering sign-off → publishing) and record decisions and redacted artifacts in the registry.7. Monitoring & takedown - Publish under a controlled channel (company blog/GitHub org). Monitor for misuse, and have a defined takedown/rollback process.

Trade-offs & rationale- Abstraction vs. usefulness: more redaction reduces risk but may reduce educational value. Use layered artifacts: a safe public version plus an internal deep-dive for partners under NDA.- Automation reduces human error (secret scanning, templated redaction), but final legal sign-off is necessary for contractual risk.

This process balances legal/privacy compliance with the company goal of knowledge-sharing while creating a clear, auditable path to publish safe, useful artifacts.

Unlock Full Question Bank

Get access to hundreds of Data Classification and Sensitivity Handling interview questions and detailed answers.

Join thousands of developers preparing for their dream job.