Privacy and Data Protection by Design

Privacy by design is a way of developing the product

Privacy and data protection by design means considering the rights, expectations and potential adverse consequences for people when the purposes and means of data processing are first decided—and continuing to do so as the product, service and operating environment evolve. It is not a notice added shortly before launch.

Data protection by default means that the initial product configuration processes only the personal data necessary for each defined purpose, for the necessary period and with appropriately limited accessibility. Optional collection or disclosure should not quietly become the starting condition.

Privacy, cybersecurity and safety overlap—but are not interchangeable

Cybersecurity protects properties such as confidentiality, integrity and availability against threats. Safety risk management addresses physical injury or damage to health. Privacy considers the broader problems people can experience because data is processed, even when no security incident or physical harm occurs.

One event can create all three. A disclosed therapy record can violate privacy; altered therapy data can create a safety risk; and the same weak access-control design can enable both. Use MTL-108 — Medical-device Cybersecurity and MTL-105 — Medical-device Risk Management alongside this topic, while keeping the questions and evidence distinct.

Establish accountability before allocating controls

A medical-device ecosystem can involve the manufacturer, health-care provider, patient, app operator, cloud provider, analytics service, distributor and research partner. Privacy obligations depend on what each party determines and does, not simply on who owns the technology.

• Identify which organisation determines each processing purpose and the essential means.
• Confirm controller, joint-controller, processor, covered-entity, business-associate or other relevant roles with qualified privacy or legal specialists.
• Separate product operation, customer administration, support, vigilance, research, analytics and commercial uses.
• Define who answers individual requests, provides notices, obtains any required authorisation and reports incidents.
• Assign product ownership for the data inventory, retention rules, supplier controls and privacy requirements.
• Record decisions and unresolved assumptions rather than relying on informal statements that “the customer owns the data”.

Legal roles and lawful grounds vary by jurisdiction and relationship. Product teams should provide accurate technical facts and implement approved requirements; they should not invent a legal basis or transfer accountability through interface wording.

Build a complete data inventory and flow model

Teams cannot minimise or protect data they have not identified. Map data across the device, mobile application, local infrastructure, cloud services, support tools, logs, backups, exports and suppliers.

Include data that identifies indirectly. Device identifiers, precise timestamps, rare conditions, location, usage patterns and combinations of apparently ordinary attributes can make a person identifiable. Record data provenance and every transformation that changes sensitivity or meaning.

Use MTL-121 — Data, Connectivity and Interoperability for identity, provenance, interface and data-integrity controls across technical and organisational boundaries.

Separate purposes and test necessity

Describe each purpose in terms a person and a reviewer can understand. “Improve the service”, “business purposes” or “analytics” is too broad to guide design. Device operation, safety monitoring, technical support, product improvement, scientific research and marketing are different purposes and may require different data, controls and decisions.

• State the intended outcome and the people or organisations that benefit.
• Identify the minimum data and processing needed to achieve that outcome.
• Challenge whether identity, precise location, fine-grained time or long-term history is necessary.
• Separate required product functions from optional services and secondary uses.
• Identify incompatible or prohibited uses and prevent uncontrolled repurposing.
• Define accuracy, availability and retention needs for each purpose rather than for the database as a whole.
• Record the approved legal basis or authorisation supplied by the accountable function.
• Reassess the purpose when data, algorithms, recipients, business models or product claims change.

Purpose decisions should appear in the product definition and design inputs. MTL-103 — User Needs and Design Inputs explains how to turn stakeholder needs and obligations into testable requirements.

Minimise collection, detail, duration and access

Data minimisation is broader than collecting fewer fields. Consider precision, sampling rate, identifiability, retention, replication, recipients, permissions and whether processing can occur locally.

Privacy-protective defaults should work without expert configuration. Optional sharing, analytics or discoverability should not be enabled merely because users can later find a setting to disable them.

Analyse privacy risk from the person’s perspective

A privacy-risk assessment asks how product or service operations with data could create problems for individuals. Consider likelihood, impact, affected populations, power imbalance and the difficulty of detecting or reversing the consequence.

• Unwanted observation of a condition, behaviour, therapy, location or relationship.
• Exposure, embarrassment, stigma or damage to personal and professional relationships.
• Unfair treatment, discrimination, exclusion or loss of access to employment, insurance or services.
• Manipulation, profiling or decisions that a person cannot understand or challenge.
• Loss of autonomy where refusal is impractical or optional processing is tied to essential care.
• Inaccurate or misattributed data that follows a person across systems.
• Re-identification of pseudonymised, aggregated or supposedly anonymous information.
• Disproportionate effects on children, vulnerable patients or small and identifiable populations.
• Persistent consequences because data cannot realistically be withdrawn, corrected or deleted.

Do not reduce privacy impact to the financial cost of a breach. Privacy harm can arise from intended processing performed exactly as designed.

Use architecture to reduce exposure

Privacy controls are strongest when the architecture removes unnecessary data and trust rather than depending entirely on policies and user vigilance.

Architecture should make data flows and trust boundaries reviewable. Use MTL-112 — Systems Engineering, Architecture and Interfaces to allocate privacy functions and dependencies across devices, software, services and external organisations.

Treat de-identification claims carefully

Pseudonymised data remains linkable through separately held information and will generally still be personal data under regimes such as the GDPR. Anonymous data requires a much stronger conclusion that individuals are not identifiable by reasonably likely means.

• Define the intended protection goal: removal of direct identifiers, pseudonymisation, tokenisation, aggregation or anonymisation.
• Consider singling out, linkability and inference—not only name and address fields.
• Assess auxiliary datasets available to recipients and foreseeable attackers.
• Protect keys, mapping tables, linkage services and rare-value combinations.
• Limit query results, export detail and repeated access that can enable reconstruction.
• Test re-identification risk in the context of the actual dataset and recipients.
• Reassess when new data is added, populations shrink or external datasets become available.
• Describe limitations accurately; do not label pseudonymous data “anonymous”.

Where identity is necessary for safe care, preserve correct association and reconciliation. Privacy minimisation must not introduce patient misidentification or remove information required for safe clinical interpretation.

Make privacy behaviour understandable and controllable

People should be able to understand what data is used, for which purposes, by whom, for how long and with what consequences. Provide information at the time and place it supports a decision, not only in a long general notice.

Consent is only one possible legal basis and is not valid merely because a checkbox exists. The accountable privacy function must determine when it is appropriate. Apply MTL-116 — Usability and Human Factors so privacy information and controls work for the intended users and environments.

Control access, disclosure and support activity

Authorisation should reflect purpose and context rather than a broad job title. Clinical users, customer administrators, manufacturer support teams, service partners and automated integrations need different access.

• Define access by role, organisation, patient relationship, data class, action and time.
• Separate routine support from exceptional access to identifiable clinical information.
• Use approval, user presence, temporary credentials or audited elevation where appropriate.
• Limit exports, bulk queries and administrative interfaces that bypass normal product controls.
• Record privacy-relevant access and disclosure without placing excessive personal data in logs.
• Provide meaningful audit information to the responsible organisation and affected people where required.
• Terminate access promptly when staff, contracts, devices or customer relationships change.
• Test that denial and revocation work across caches, replicas, sessions, backups and integrations.

Encryption and authentication support confidentiality, but they do not decide whether an authorised recipient should receive the data for a particular purpose.

Govern analytics, AI and secondary use explicitly

Product telemetry, support records and clinical datasets can appear valuable for improvement, research or AI development. A new business value does not automatically make an existing dataset suitable for a new purpose.

• Separate technical telemetry from identifiable clinical and behavioural information.
• Define the specific secondary purpose, population, recipients and expected benefit.
• Reassess compatibility, legal basis, transparency, expectations and privacy risk.
• Minimise detail and consider aggregation, local analytics, synthetic data or controlled research environments.
• Evaluate selection bias, sensitive inferences, re-identification and effects on under-represented groups.
• Control training, validation and test datasets, model artefacts, prompts, logs and derived features.
• Prevent secondary datasets and models from being used for unapproved decisions or commercial purposes.
• Define deletion and withdrawal implications realistically, including limitations once aggregate knowledge or models exist.

Document whether the activity belongs to product development, post-market surveillance, research, customer service or another controlled process. Each has different governance and evidence needs.

Extend privacy controls through suppliers and transfers

Cloud hosting, analytics, support, identity, messaging and software-development services can process or expose personal data. Procurement labels alone do not establish that their configuration and use meet the product’s privacy needs.

Supplier agreements should reflect the approved purpose and design. Do not permit a provider to reuse product data for its own analytics or model training simply because the function is hidden in general service terms.

Use privacy impact assessment as a design activity

A data-protection or privacy impact assessment should begin while alternatives remain open. It brings the purpose, data flows, people, risks, legal advice and controls into one reviewable decision process.

• Describe the processing, purposes, technologies, participants, data and recipients.
• Assess necessity, proportionality, individual expectations and available alternatives.
• Identify effects on people, including vulnerable groups and cumulative or indirect consequences.
• Record applicable advice, consultation and responsibilities.
• Define technical and organisational controls and the evidence required to show they work.
• Evaluate residual risk and establish escalation or prior consultation where required.
• Assign approval and actions rather than treating the assessment as an informational document.
• Review it when purpose, data, algorithms, architecture, suppliers, territories or risk change.

The assessment should connect to design reviews and change control. Use MTL-104 — Design Controls and Technical Documentation to organise the resulting decisions, traceability and objective evidence.

Verify privacy requirements as product behaviour

Privacy claims should be tested with the same discipline as other design inputs. Review documents, inspect configurations and exercise the product across normal, exceptional and adversarial situations.

Use realistic data classes and representative configurations without exposing real patient information unnecessarily. MTL-106 — Verification and Validation provides the wider framework for protocols, acceptance criteria, test environments, anomalies and conclusions.

Privacy work across the lifecycle

Build a connected privacy evidence chain

A reviewer should be able to trace from each approved purpose and privacy risk to product requirements, design decisions, supplier controls, test evidence and lifecycle monitoring. The record should show not only that controls exist, but why the selected processing is necessary and proportionate.

Common misconceptions