Privacy by Design, Risk Assessment and Decision-Making

Introduction

Privacy protection is most effective when it is incorporated into the design of a product, service, business process or information system rather than added after deployment. A late privacy review may identify a legal defect, but correcting that defect can be costly, technically difficult and disruptive to users. Privacy by design therefore connects legal compliance with practical governance, system architecture, procurement, product management and organisational decision-making.

This chapter explains how organisations can apply privacy by design and privacy by default, map personal data, conduct privacy impact assessments (PIAs) and data protection impact assessments (DPIAs), and use risk matrices to select proportionate controls. The discussion uses internationally recognised concepts, with particular reference to the EU General Data Protection Regulation (GDPR). Local law must always be consulted because terminology, thresholds, supervisory guidance and sectoral duties differ between jurisdictions.

Learning Objectives

By the end of this chapter, a learner should be able to:

1. Explain privacy by design and privacy by default.
2. Distinguish data mapping, PIAs and DPIAs.
3. Identify data flows, purposes, actors, risks and controls.
4. Construct and interpret a qualitative privacy risk matrix.
5. Recommend proportionate technical, organisational and governance measures.
6. Support defensible business decisions while respecting individual rights.

1. Privacy as a Design and Governance Responsibility

Privacy is not merely a policy document or a matter for the legal department. It concerns how an organisation collects, uses, stores, shares and deletes information about identifiable or identifiable people. A privacy failure may cause financial loss, discrimination, loss of autonomy, reputational damage, surveillance, identity fraud or physical harm.

A useful distinction is between:

• Compliance risk: the possibility of breaching a legal or regulatory requirement.
• Privacy risk: the possibility that processing adversely affects individuals, even where no explicit legal breach has yet been established.
• Security risk: the possibility of unauthorised access, alteration, disclosure, loss or destruction. Security risk is one important category of privacy risk, but privacy also includes excessive collection, unfair inference, unexpected use and unjustified retention.
• Business risk: the effect of privacy failures on operations, revenue, trust and strategic objectives.

Good decision-making considers all four. A technically secure system may still be privacy-invasive if it collects unnecessary biometric data or makes opaque decisions about people.

2. Privacy by Design and Privacy by Default

Privacy by design means embedding privacy considerations into the architecture, functionality, processes and governance of an activity from its earliest planning stage. Under Article 25 of the GDPR, controllers must implement appropriate technical and organisational measures, taking account of the state of the art, cost of implementation, nature, scope, context and purposes of processing, and the risks to individuals.

Privacy by default is narrower. It requires that, by default, only personal data necessary for each specific purpose is processed. A user should not have to discover and disable excessive collection, broad sharing or indefinite retention in order to obtain a reasonably private service.

2.1 Core design principles

The following principles provide a practical design vocabulary:

These principles are not a licence to ignore trade-offs. For example, fraud prevention may require some monitoring, but the organisation should limit the data, duration, access and purposes to what is justified.

2.2 Design questions

At the conception stage, a project team should ask:

• What problem is the processing intended to solve?
• Is personal data necessary, or could anonymous, aggregated or synthetic data work?
• What is the lawful basis and specified purpose?
• What categories of people and data are involved?
• Could the processing affect children, vulnerable people or marginalised groups disproportionately?
• Who needs access, and for how long?
• What happens if the system is wrong?
• Can people understand, challenge and correct the outcome?
• How will the organisation demonstrate compliance?

3. Data Mapping and Records of Processing

Data mapping is the systematic description of personal-data flows through an organisation. It is more than an inventory of databases. A useful map shows where data originates, how it moves, who controls it, who processes it, where it is stored, how long it is retained and what happens at the end of its lifecycle.

A data map should normally record:

1. Purpose: the defined business or public-interest objective.
2. Data subjects: customers, employees, patients, students or other groups.
3. Data categories: identity, contact, financial, behavioural, location, health, biometric or other information.
4. Source: the individual, a device, a public source, a partner or another system.
5. Processing operations: collection, matching, analysis, disclosure, profiling, transfer, archiving and deletion.
6. Recipients: internal teams, processors, affiliates, regulators or other third parties.
7. Locations and transfers: systems, countries and hosting environments.
8. Retention: the period, trigger for deletion and exceptions.
9. Controls: access restrictions, encryption, logging, pseudonymisation and quality checks.
10. Responsible roles: controller, joint controller, processor, system owner, privacy officer and security owner.

The GDPR record of processing activities (ROPA) is a formal accountability record for many organisations. A data map supports the ROPA, but the two are not identical: a map emphasises flows and relationships, while a ROPA records prescribed information about processing activities.

3.1 A practical mapping method

Begin with a business process rather than with a database. Interview process owners and technical staff, inspect forms and application programming interfaces, review contracts and observe actual workflows. Compare the documented process with system logs because undocumented copies and informal spreadsheets are common sources of risk.

A simple flow description might be:

Mobile application → cloud platform → fraud analytics provider → case-management system → archive or deletion.

For each arrow, ask what data travels, why it travels, whether the recipient needs identifiable data, how the transfer is secured and whether the transfer is lawful.

Data mapping should be maintained as a living governance artefact. It should be updated when a new vendor, purpose, field, country, algorithm or retention period is introduced.

4. Privacy Impact Assessments and DPIAs

A privacy impact assessment is a structured process for identifying and addressing privacy effects. The term PIA is used broadly in many jurisdictions and standards. A DPIA is the specific GDPR process required where processing is likely to result in a high risk to the rights and freedoms of natural persons.

A DPIA is required under GDPR Article 35 before high-risk processing begins. Examples commonly include systematic and extensive evaluation or profiling, large-scale processing of special-category data, and systematic monitoring of publicly accessible areas. Supervisory authorities may publish lists of processing activities that require or do not require a DPIA.

A DPIA is not a one-time form. It should be reviewed when the nature, scope, context or purposes of processing change, or when new risks emerge.

4.1 Main stages of a DPIA

1. Screening and scope. Describe the project and determine whether a DPIA is required. Record the screening decision even where the conclusion is that one is unnecessary.

2. Description of processing. Explain the data, systems, actors, purposes, recipients, locations, retention and lifecycle. The data map is essential evidence.

3. Necessity and proportionality assessment. Ask whether the purpose is legitimate and specific, whether the processing is necessary to achieve it, and whether a less intrusive method could achieve a comparable result. Consider data minimisation, accuracy, transparency, rights and retention.

4. Risk assessment. Identify potential harm to individuals and evaluate the likelihood and severity of that harm.

5. Measures and residual risk. Specify controls, assign owners and reassess the risk after controls are implemented.

6. Consultation and approval. Consult the data protection officer where applicable, relevant technical and business specialists, and affected stakeholders where appropriate. Under GDPR, the controller must consult the supervisory authority before processing where high residual risk cannot be mitigated.

7. Monitoring and review. Establish triggers, metrics, audit arrangements and a review date.

4.2 PIA and DPIA compared

A well-designed organisational PIA method can satisfy or support a DPIA, but simply labelling a document “DPIA” does not make it legally sufficient.

5. Privacy Risk Assessment

Risk assessment should focus on consequences for people, not only on the value of an organisation’s assets. Relevant harms include:

• loss of confidentiality or control;
• financial loss or identity fraud;
• embarrassment, stigma or reputational injury;
• discrimination or exclusion;
• physical or psychological harm;
• surveillance and chilling effects;
• inaccurate decisions and denial of opportunities;
• inability to exercise legal rights; and
• harm caused by aggregation or re-identification.

Threats may arise from malicious actors, careless staff, system defects, poor data quality, excessive functionality, vendor failure or lawful but unexpected secondary use.

5.1 Likelihood and impact

Many organisations use a qualitative matrix. A common heuristic is:

Likelihood and impact are ordinal ratings, such as 1 to 5, rather than precise physical measurements. The multiplication is therefore a prioritisation aid, not a claim that privacy harm behaves according to an exact probabilistic law. If numerical probabilities and monetary consequences are genuinely available, an expected-loss model may be used:

The variables must be defined consistently. Probability is a value from 0 to 1; consequence must use a defined unit, such as monetary loss or an agreed severity scale. In most privacy assessments, reliable numerical data is unavailable, so qualitative ratings and documented reasoning are more defensible.

An illustrative five-by-five matrix is shown below.

An organisation must define its own thresholds. For illustration, scores 1–4 may be low, 5–9 medium, 10–16 high and 17–25 very high. These thresholds are not universal legal rules.

5.2 Inherent and residual risk

Inherent risk is the risk before additional controls are applied. Residual risk is the risk remaining after controls. Existing controls must be described rather than assumed. A strong assessment states why a control changes likelihood, impact or both.

For example, encryption may substantially reduce the impact of a lost device but may not prevent an authorised user from exporting information. Access segregation may reduce the likelihood of inappropriate internal access, while data minimisation reduces both exposure and potential impact.

Risk treatment options are:

• Avoid: do not undertake the processing or remove the risky feature.
• Reduce: apply technical, organisational or contractual controls.
• Share or transfer: allocate specific responsibilities through insurance or contracts, while recognising that legal accountability cannot always be transferred.
• Accept: proceed with documented approval where residual risk is within tolerance.

Acceptance should be informed, authorised and reviewable. It must not be used to bypass a mandatory legal prohibition.

6. Selecting Proportionate Controls

Controls should respond to identified risks and the purpose of processing. Common controls include:

Technical controls

• data minimisation and field-level collection controls;
• encryption in transit and at rest;
• pseudonymisation, tokenisation and separation of identifiers;
• role-based or attribute-based access control;
• multi-factor authentication;
• logging, monitoring and anomaly detection;
• automated retention and deletion mechanisms;
• data-quality validation and correction workflows;
• secure development, testing and change management;
• privacy-preserving analytics, aggregation or differential privacy where suitable; and
• backup, recovery and incident-response controls.

Pseudonymisation reduces linkability but does not generally make data anonymous if an organisation retains additional information capable of re-identifying people. Anonymisation requires a much stronger assessment of reasonably likely means of re-identification.

Organisational and legal controls

• clear allocation of controller and processor responsibilities;
• staff training and confidentiality obligations;
• documented policies and approval gates;
• supplier due diligence and contractual restrictions;
• procedures for access, correction, deletion and objection requests;
• breach response and notification procedures;
• independent review by a data protection officer or privacy function;
• retention schedules and destruction certificates; and
• audits, testing and periodic DPIA review.

Controls should be measurable. “Protect data appropriately” is weaker than “all administrative users must use multi-factor authentication, access is reviewed quarterly, and failed reviews generate a remediation ticket.”

7. Decision-Making in Practice

Privacy decisions are often made under uncertainty. A defensible decision record should identify the objective, alternatives considered, legal basis, affected groups, risk ratings, controls, residual risk, decision-maker and review date.

The least intrusive alternative should be considered explicitly. If a service needs to predict demand, individual-level histories may not be necessary; aggregated statistics may suffice. If identity verification is necessary, storing a permanent copy of an identity document may not be necessary. If location is needed to provide a local service, approximate location may be adequate instead of continuous precise tracking.

Proportionality does not mean selecting the cheapest control. Cost is relevant, but it must be weighed against the severity of potential harm, the scale of processing, the sensitivity of the information, the reasonable expectations of individuals and the feasibility of less intrusive alternatives.

Automated decision-making and artificial intelligence require additional scrutiny. Data minimisation does not eliminate risks of discriminatory proxies, inaccurate training data, opaque explanations, model inversion, prompt leakage or inappropriate retention of inputs. Governance should address dataset provenance, purpose limitation, human oversight, testing for disparate impacts, output logging, challenge procedures and vendor restrictions. An AI system should not be treated as a neutral decision-maker merely because its output is statistically generated.

8. Illustrative Case: University Wellbeing Analytics

This is a fictional illustrative case.

Background

A university proposes a mobile application that combines attendance records, learning-platform activity and optional wellbeing surveys. It intends to identify students who may need support and send an early intervention message.

Problem

The proposal involves profiling, potentially sensitive wellbeing information and the possibility that inaccurate predictions could stigmatise students or affect academic treatment. The project team initially plans to retain detailed event data for five years and provide dashboards to faculties.

Analysis

The data map identifies the university as controller, a cloud provider as processor, the counselling service as a restricted recipient and faculties as proposed users. The purpose is narrowed from “student success analytics” to “offering voluntary support to students showing specified indicators.” Attendance and activity data are assessed as potentially relevant, but continuous location data is rejected as unnecessary.

The DPIA identifies risks of false positives, false negatives, function creep, unauthorised access, discrimination against disabled students and loss of trust. The initial risk of inappropriate disclosure is rated likelihood 3 and impact 5, producing an illustrative score of 15, classified as high under the stated matrix.

Approach and solution

The university adopts the following measures:

• participation is voluntary and does not affect grades;
• the system uses the minimum data needed for a limited support purpose;
• counselling information is not included in faculty dashboards;
• identifiers are separated from analytical data;
• results are visible only to trained support staff;
• students receive a clear explanation and can request human review;
• predictions trigger an invitation to support, never an automatic adverse decision;
• retention is reduced from five years to one academic year unless a separate basis exists;
• model performance and disparate outcomes are reviewed each term;
• the processor is contractually prohibited from reuse; and
• the DPIA is reviewed before any expansion to disciplinary or admissions decisions.

Outcome

Residual risk is reduced but not eliminated. The university approves a limited pilot with governance oversight, student communication and a stop condition if evidence shows unacceptable error or unequal impact. The original broad dashboard is rejected because its benefits are speculative and its privacy risks are not proportionate.

Learning points

The case demonstrates that privacy by design is not necessarily a choice between “use data” and “do not use data.” It can involve narrowing the purpose, reducing data, limiting recipients, preserving human judgement, testing outcomes and refusing secondary uses that were not justified.

9. Challenges and Limitations

Risk matrices can create false precision. Two projects with the same score may involve very different types of harm. A rare but catastrophic disclosure should not automatically be treated as equivalent to a frequent minor inconvenience. Narrative analysis is therefore essential.

Data maps can also become inaccurate when shadow systems, manual exports and vendor integrations are omitted. DPIAs may fail when completed as administrative paperwork after a design has already been fixed. Consultation may be symbolic if affected people cannot influence the decision. Finally, compliance documentation cannot compensate for weak organisational incentives. Leadership, budgets, technical capability and accountability determine whether controls operate in practice.

Best-Practice Checklist

Before approving a new or changed processing activity, confirm that:

• the purpose is specific and justified;
• the minimum necessary data has been identified;
• the data flow and all recipients are mapped;
• retention and deletion are technically feasible;
• privacy by default settings are documented;
• a PIA or DPIA screening decision is recorded;
• risks to individuals, including vulnerable groups, are assessed;
• controls have owners, deadlines and testing criteria;
• individual rights and human review are operational;
• suppliers and international transfers are addressed;
• residual risk is approved by an accountable person; and
• monitoring and review triggers are defined.

Chapter Summary

Privacy by design embeds privacy into systems, services and processes from the beginning, while privacy by default limits processing to what is necessary unless a justified alternative is selected. Data mapping reveals the lifecycle, actors, purposes, destinations and controls associated with personal data. PIAs provide a broad assessment method, while a GDPR DPIA is required for processing likely to create high risk to individuals.

A sound risk assessment identifies possible harms, evaluates likelihood and impact, distinguishes inherent from residual risk, and selects proportionate controls. Risk matrices help prioritise work but are qualitative decision aids rather than exact measures of harm. Effective decisions consider less intrusive alternatives, individual rights, security, transparency, fairness, accountability and operational feasibility. The objective is not simply to produce documentation; it is to make processing safer, more lawful and more respectful of people.

Key Terms

Anonymisation: Processing intended to prevent identification of individuals using reasonably likely means.

Controller: The person or organisation that determines the purposes and means of processing.

Data mapping: Documentation of personal-data sources, flows, uses, recipients, storage and deletion.

Data minimisation: Limiting personal data to what is adequate, relevant and necessary.

Data protection impact assessment (DPIA): A structured assessment required under GDPR for processing likely to result in high risk to individuals.

Data protection officer: A designated specialist role supporting privacy compliance, advice and monitoring where legally required.

Inherent risk: Risk assessed before additional risk treatments are applied.

Joint controller: Two or more parties that jointly determine purposes and means of processing.

Lawful basis: The legal ground authorising processing under applicable law.

Likelihood: An assessment of how probable a harmful event or outcome is.

Personal data: Information relating to an identified or identifiable natural person.

Privacy by default: Configuring systems and services so that only necessary personal data is processed by default.

Privacy by design: Integrating privacy protections into the design and operation of processing activities.

Privacy impact assessment (PIA): A systematic assessment of privacy effects and proposed safeguards.

Pseudonymisation: Processing that separates identifying information while retaining a possibility of re-linking with additional information.

Residual risk: Risk remaining after controls are implemented.

Risk matrix: A structured grid combining qualitative likelihood and impact ratings.

Special-category data: Sensitive data receiving enhanced legal protection under frameworks such as the GDPR.

Transparency: Providing understandable information about processing, its purposes and its consequences.

Review Questions

Short Answer Questions

1. What is the difference between privacy by design and privacy by default?
2. Identify four elements that should appear in a data map.
3. When does the GDPR generally require a DPIA?
4. What is residual risk?
5. Why is pseudonymisation not necessarily anonymisation?

Long Answer Questions

1. Explain how privacy by design can be integrated into the lifecycle of a digital product.
2. Compare a general PIA with a GDPR DPIA, including their purposes and triggers.
3. Describe a method for conducting a data-mapping exercise in a complex organisation.
4. Discuss the strengths and limitations of qualitative privacy risk matrices.
5. Explain how technical, organisational and contractual controls can work together to reduce privacy risk.

Analytical / Application Questions

1. A retailer wants to retain precise customer location data indefinitely to improve marketing. Apply necessity, proportionality, data minimisation and retention principles to recommend a defensible design.
2. A hospital proposes an AI model that predicts readmission using clinical records and social-service data. Identify the likely DPIA issues, stakeholders, risks and controls that should be considered before deployment.
3. A company rates a data breach as likelihood 2 and impact 5 using a five-point matrix. Explain what the resulting score can and cannot establish, and identify additional qualitative questions required before accepting the risk.

Multiple Choice Questions with Answers

Question 1

Which statement best describes privacy by default?

A. Privacy controls are considered only after a security incident.

B. The system processes only the personal data necessary for the specified purpose unless a justified alternative is selected.

C. All personal data is made publicly accessible unless users complain.

D. The organisation transfers privacy responsibility entirely to its processor.

Correct Answer: B. The system processes only the personal data necessary for the specified purpose unless a justified alternative is selected.

Question 2

What is the primary purpose of data mapping?

A. To document personal-data sources, flows, uses, recipients and lifecycle controls.

B. To replace all information-security testing.

C. To determine an organisation’s annual tax liability.

D. To guarantee that data is anonymous.

Correct Answer: A. To document personal-data sources, flows, uses, recipients and lifecycle controls.

Question 3

Under the GDPR, a DPIA is generally required when processing is likely to result in what?

A. A high risk to the rights and freedoms of natural persons.

B. Any use of a company email address.

C. Only a risk of hardware failure.

D. A low-cost improvement to an existing service.

Correct Answer: A. A high risk to the rights and freedoms of natural persons.

Question 4

In the illustrative risk matrix, what is the score for likelihood 4 and impact 3?

A. 7

B. 10

C. 12

D. 15

Correct Answer: C. 12

Question 5

Which statement about pseudonymisation is correct?

A. It always makes data legally anonymous.

B. It separates identifiers but may still permit re-identification using additional information.

C. It removes the need for access controls.

D. It prevents all inaccurate data from being processed.

Correct Answer: B. It separates identifiers but may still permit re-identification using additional information.

Question 6

Which option is an example of risk avoidance?

A. Encrypting stored data.

B. Increasing staff training.

C. Rejecting a proposed feature because its privacy risks are unjustified.

D. Adding a processor contract.

Correct Answer: C. Rejecting a proposed feature because its privacy risks are unjustified.

Question 7

What is residual risk?

A. Risk remaining after controls are implemented.

B. Risk before a project is described.

C. Risk that applies only to processors.

D. Risk that can never be reviewed.

Correct Answer: A. Risk remaining after controls are implemented.

Question 8

Which consideration most directly supports data minimisation?

A. Collecting every available data field for possible future use.

B. Collecting only the data adequate, relevant and necessary for the stated purpose.

C. Keeping all data permanently.

D. Sharing data with every internal department.

Correct Answer: B. Collecting only the data adequate, relevant and necessary for the stated purpose.

Question 9

In the illustrative university case, why was continuous location data rejected?

A. It was impossible to store technically.

B. It was unnecessary for the limited support purpose and would increase intrusiveness.

C. Location data can never be personal data.

D. The processor demanded exclusive ownership of it.

Correct Answer: B. It was unnecessary for the limited support purpose and would increase intrusiveness.

Question 10

Why should a risk-matrix score not be treated as an exact measurement of privacy harm?

A. Likelihood and impact ratings are usually qualitative ordinal judgements.

B. Risk matrices can only be used for financial accounting.

C. Multiplication is never permitted in risk assessment.

D. Privacy risks have no possible consequences.

Correct Answer: A. Likelihood and impact ratings are usually qualitative ordinal judgements.