Privacy by design means identifying how data processing could affect people and embedding proportionate safeguards throughout planning, design, build, operation, and retirement. It is not a policy review added immediately before launch.
Map the Data Journey
For each product journey, document the personal data collected, purpose, source, lawful basis, users, recipients, storage, location, retention, and deletion path. Include analytics, logs, support tools, backups, vendors, and derived data—not only primary database fields.
Name the controller, processor, product owner, system owner, and privacy decision-maker. If the team cannot locate data or ownership, it cannot reliably protect or delete it.
Minimise by Default
Challenge every field and event: is it required for the stated outcome, or merely convenient for a possible future? Collect the least precise and least sensitive data that works. Prefer aggregation or on-device processing when it materially reduces exposure.
Defaults should provide the most privacy-preserving reasonable experience. Optional processing should not be hidden behind confusing choices.
Separate Purpose and Access
Design schemas and services so data collected for one purpose is not automatically available for another. Enforce access by job and workload identity, with stronger controls for sensitive and high-volume data.
Use pseudonymisation where it reduces linkability, but do not describe pseudonymous data as anonymous if re-identification remains possible.
Make Rights Technically Possible
Products should support access, correction, objection or withdrawal where applicable, portability, restriction, and deletion according to the governing requirements. Build identity verification, request tracking, search across systems, exception handling, and evidence.
Avoid a “delete” button that only hides a profile while copies remain indefinitely in search, analytics, exports, and vendors.
Assess High-Risk Processing Early
Before building, evaluate scale, sensitivity, vulnerable people, monitoring, automated decisions, novel technology, and consequences of misuse or error. Record harms to individuals alongside company risk.
Use the assessment to change scope, data, defaults, access, retention, explainability, human review, and vendor selection. Escalate unresolved risk to an accountable decision-maker.
Verify in Delivery and Operation
Add privacy acceptance criteria to stories and architecture reviews. Test permissions, data export, deletion, consent or preference changes, logging redaction, vendor flows, and failure cases.
Monitor unexpected collection and access. Review processing when the purpose, dataset, model, vendor, or jurisdiction changes.
Indonesia's PDP Law regulates personal-data types, data-subject rights, processing, controller and processor duties, transfers, and sanctions. Exact obligations depend on context; involve qualified Indonesian counsel rather than treating this engineering guide as legal advice.
DualByte's cybersecurity service can translate privacy requirements into product architecture, workflows, and verifiable controls.
Sources
Need help with implementation?
Get a free consultation with the DualByte team for your business technology needs.
