Data Security and Privacy Engineering

Introduction

Data is an organisational asset, a record of human activity, and a potential source of harm. A customer record may support service delivery, but the same record may enable identity theft if disclosed. Effective data security therefore requires more than placing a firewall around a database. It requires an engineered understanding of what data exists, why it is processed, where it moves, who may use it, how long it should be retained, and how it should be destroyed.

Data security protects confidentiality, integrity, and availability. Privacy engineering adds requirements concerning purpose, fairness, transparency, individual rights, proportionality, and lawful processing. These disciplines overlap but are not identical: encrypted processing can be secure while still being excessive or unjustified from a privacy perspective.

This chapter presents a lifecycle-based approach to classifying, mapping, protecting, retaining, sharing, backing up, and disposing of data. It also examines access control, encryption, tokenisation, anonymisation, pseudonymisation, and data loss prevention (DLP).

Learning Objectives

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

1. Classify organisational data according to sensitivity, criticality, and regulatory impact.
2. Map data flows throughout collection, use, storage, sharing, archival, and destruction.
3. Apply data minimisation, purpose limitation, retention, and secure disposal principles.
4. Select suitable access-control, encryption, tokenisation, anonymisation, and pseudonymisation controls.
5. Design backup and DLP controls that support both resilience and privacy.
6. Evaluate trade-offs, limitations, ethical issues, and governance responsibilities in data-security decisions.

1. Foundations of Data Security and Privacy Engineering

1.1 Security objectives

The traditional security triad is:

• Confidentiality: only authorised subjects can access data.
• Integrity: data remains accurate, complete, and protected from unauthorised alteration.
• Availability: authorised users can access data when required.

Privacy engineering broadens the analysis. Important privacy properties include:

• Purpose limitation: collect and use data for specified legitimate purposes.
• Data minimisation: process no more personal data than necessary.
• Transparency: explain processing in an understandable manner.
• Accountability: demonstrate that controls and decisions are appropriate.
• Data subject control: support access, correction, deletion, objection, and portability rights where applicable.
• Privacy by design and default: incorporate privacy into architecture rather than adding it after deployment.

A useful distinction is between personal data, which relates to an identified or identifiable person, and sensitive or special-category data, whose misuse may create heightened harm. Examples include health, biometric, financial, authentication, location, and children's data. Exact legal categories vary by jurisdiction; classification must therefore consider applicable law and contractual obligations.

1.2 Data as a lifecycle

Data normally passes through these stages:

1. Collection or creation: information is entered, observed, generated, or received.
2. Classification and registration: ownership, sensitivity, purpose, and retention requirements are recorded.
3. Use and processing: applications query, transform, analyse, or combine the data.
4. Storage: data resides in databases, files, endpoints, cloud services, caches, or backups.
5. Sharing and transfer: information moves between departments, suppliers, jurisdictions, or systems.
6. Archiving: data is retained for legal, historical, audit, or operational reasons but is no longer routinely used.
7. Disposal: data is securely deleted, cryptographically erased, overwritten where appropriate, or physically destroyed.

Security must apply at every stage. For example, deleting a production record does not achieve disposal if it remains in an accessible export, email attachment, snapshot, or backup.

2. Data Classification and Discovery

2.1 Classification dimensions

A practical classification scheme combines several dimensions rather than relying on one label.

Classification should be assigned to data sets and, where necessary, to individual fields. A database containing names and public product descriptions should not automatically receive the same classification as a database containing passwords or medical histories. Conversely, combining apparently harmless fields can create sensitive inferences.

2.2 Discovery methods

Data discovery combines interviews, architecture review, configuration inspection, database catalogues, endpoint scanning, cloud inventories, and automated content inspection. Discovery should identify structured data, such as database columns, and unstructured data, such as documents, images, chat messages, source code, and logs.

Automated discovery is useful but imperfect. Pattern matching may identify a sequence resembling a payment-card number while missing a scanned document or a locally meaningful identifier. Results require sampling, validation, and documented confidence levels. Data owners must confirm business meaning and retention requirements.

2.3 A data inventory

A useful inventory records:

• data element or data set;
• source and collection method;
• purpose and lawful basis where applicable;
• owner and processor;
• classification and affected individuals;
• systems, locations, and jurisdictions;
• recipients and transfer mechanisms;
• retention period and disposal method;
• security controls;
• data-quality and privacy risks.

The inventory becomes a foundation for risk assessment, incident response, access reviews, data-subject requests, and supplier oversight.

3. Data Mapping and Flow Analysis

A data-flow map represents movement rather than merely listing storage locations. It should show actors, processes, repositories, interfaces, trust boundaries, transformations, and external recipients. Arrows should be annotated with data type, protocol, direction, frequency, and protection.

A simple mapping process is:

1. Define the business process and its boundaries.
2. Identify collection points and data subjects.
3. Trace data through applications, queues, APIs, reports, caches, logs, and backups.
4. Mark trust boundaries and external processors.
5. Record transformations, such as aggregation, tokenisation, or pseudonymisation.
6. Validate the map with system owners and operational staff.
7. Link each flow to purpose, access rules, retention, and control evidence.

Data-flow mapping supports threat modelling. For every flow, ask: what could be intercepted, misdirected, altered, duplicated, over-collected, or retained unnecessarily? It also reveals “shadow copies” created by spreadsheets, test environments, monitoring tools, and support tickets.

A privacy impact assessment or data protection impact assessment is appropriate where processing is likely to create significant risks, such as large-scale profiling, systematic monitoring, sensitive data processing, or novel technologies. The assessment should describe necessity, proportionality, risks, mitigations, residual risk, and consultation requirements.

4. Minimisation, Purpose, Quality, and Retention

4.1 Data minimisation

Minimisation has at least four dimensions:

• Volume: collect fewer records or fields.
• Granularity: use age bands instead of exact birth dates where possible.
• Precision: reduce location or time precision when exact values are unnecessary.
• Accessibility: restrict how many people and systems can reach the data.

Minimisation is not the same as deleting useful information indiscriminately. The correct test is whether each element is necessary and proportionate for a defined purpose. A design review should challenge optional fields, default collection, indefinite logs, and reuse for unrelated analytics.

4.2 Data quality

Incorrect data can cause both operational and privacy harm. Systems should provide validation, provenance, correction workflows, confidence indicators, and controls against inappropriate inference. Data quality policies should specify who may amend a record and how changes are audited.

4.3 Retention schedules

Retention should be based on documented business, legal, contractual, and evidential needs. A schedule normally specifies the trigger, duration, responsible owner, storage state, review date, and disposal method. “Keep forever” is rarely a sound default because it expands breach impact, discovery costs, and privacy risk.

Retention must cover secondary copies. A practical policy distinguishes:

• active operational data;
• temporary working copies;
• replicated data;
• immutable backups;
• legal holds;
• archives;
• test and development data.

A legal hold may suspend routine deletion, but it should be scoped, documented, and reviewed. It should not become an excuse for indefinite retention of unrelated records.

4.4 Secure disposal

Disposal methods depend on media and threat model. Logical deletion may be sufficient for some encrypted cloud records if keys are securely destroyed; it is not automatically sufficient for every storage technology. Disposal should include verification, exception handling, supplier certificates where appropriate, and records of what was destroyed and when.

5. Access Control and Accountability

Access control answers four questions: who is requesting access, what resource is involved, what operation is requested, and under what conditions should it be allowed?

Core principles include:

• Least privilege: grant only the access needed for an approved task.
• Need to know: access depends on a legitimate information need.
• Separation of duties: divide incompatible powers, such as creating and approving payments.
• Default deny: access is denied unless explicitly authorised.
• Time limitation: use expiry dates and just-in-time elevation.
• Periodic review: managers and data owners recertify access.
• Strong authentication: use phishing-resistant multi-factor authentication for high-risk access.

Common models include:

• RBAC: permissions are assigned to job roles.
• ABAC: policy evaluates attributes such as department, device state, location, data classification, and time.
• DAC: resource owners control permissions.
• MAC: centrally enforced labels determine access.

RBAC is manageable for stable duties but can create role explosion. ABAC provides context sensitivity but requires reliable attributes, policy testing, and explainability. Privileged access management should record approvals, sessions, commands where proportionate, and emergency access (“break glass”) events.

Access logs should be protected from alteration and reviewed using risk-based methods. Logging personal data creates its own retention and access obligations; logs should therefore be minimised and segregated.

6. Cryptographic Protection

6.1 Encryption concepts

Encryption transforms plaintext into ciphertext using an algorithm and key. Symmetric encryption uses the same secret key for encryption and decryption and is efficient for bulk data. Asymmetric cryptography uses a public/private key pair and supports key exchange, signatures, and identity binding, but is generally less efficient for bulk encryption. Modern systems commonly use hybrid designs: asymmetric mechanisms establish or protect a symmetric session key, while authenticated encryption protects the data.

Confidentiality alone is insufficient. Prefer authenticated encryption, which detects unauthorised modification. Key management is often more important than algorithm selection. A sound lifecycle includes generation, storage, distribution, rotation, backup, revocation, access logging, and destruction. Keys should be separated from data, protected by hardware or managed key services where appropriate, and accessible only to authorised services.

Encryption at rest protects storage media and snapshots; it does not automatically protect data from an authorised but compromised application. Encryption in transit protects communications between endpoints; it does not validate that the recipient is trustworthy. End-to-end encryption can reduce intermediary exposure but may limit inspection, recovery, and DLP capabilities.

6.2 Hashing and passwords

A cryptographic hash is a one-way digest used for integrity checks and indexing. Hashing is not encryption. Passwords should be stored using a slow, salted, adaptive password-hashing scheme rather than reversible encryption or an unsalted general-purpose hash. Salts must be unique and stored with the password verifier; they prevent identical passwords from producing identical stored values and frustrate precomputed tables.

7. Tokenisation, Pseudonymisation, and Anonymisation

7.1 Tokenisation

Tokenisation replaces a sensitive value with a token. A protected token vault or cryptographic mechanism maintains the relationship between token and original value. A payment token may be usable for a defined merchant or transaction context without exposing the underlying card number.

Tokenisation reduces exposure but is not automatically anonymisation. If the token can be linked back to the individual, or the vault can reverse it, the information remains personal data. Token format, collision handling, vault availability, key management, and authorised detokenisation require careful design.

7.2 Pseudonymisation

Pseudonymisation separates direct identifiers from a record and replaces them with a pseudonym, while retaining an additional means of re-identification under controlled conditions. It reduces routine exposure and supports analytics, but the data remains personal where re-identification is reasonably possible.

Controls include separate identity stores, distinct access authorities, strong linkage keys, limited re-identification procedures, audit trails, and suppression of unnecessary quasi-identifiers.

7.3 Anonymisation

Anonymisation aims to make identification infeasible using reasonably likely means, considering auxiliary data, cost, time, and available technology. Removing names is not enough: combinations such as postcode, date of birth, and gender may identify individuals. Aggregation, generalisation, suppression, perturbation, and differential privacy may help, but each can reduce analytical utility.

Anonymisation is a risk assessment, not a permanent label. New datasets, public auxiliary information, machine-learning techniques, or improved computing power can change re-identification risk. Small groups and rare attributes require particular caution.

8. Backup, Recovery, and Data Loss Prevention

8.1 Backup engineering

Backups support availability and integrity, but they also create copies that require confidentiality and retention controls. A backup strategy should define recovery point objective (RPO), the maximum tolerable amount of data loss measured in time, and recovery time objective (RTO), the target time to restore service.

A common resilience principle is the 3-2-1 approach: maintain at least three copies, on at least two types of media, with at least one copy offline or otherwise isolated. It is a guideline, not a universal guarantee. Critical environments may require immutable, geographically separated, encrypted backups and independent recovery credentials.

Backups must be tested through realistic restoration exercises. A successful backup job does not prove recoverability. Testing should verify completeness, application consistency, access permissions, malware screening, and the ability to operate when the primary identity system is unavailable.

8.2 Data loss prevention

DLP identifies and controls unauthorised movement of sensitive data. It may operate at endpoints, email gateways, web proxies, cloud applications, databases, and network boundaries. Detection can use labels, exact-data matching, fingerprints, regular expressions, machine learning, and contextual signals.

Actions include blocking, quarantine, encryption, redaction, warning, approval workflows, and audit-only monitoring. DLP should begin with high-confidence, high-impact use cases. Excessive blocking creates alert fatigue and encourages circumvention. Policies must account for legitimate sharing, accessibility, false positives, encrypted archives, screenshots, APIs, and personal devices.

9. Integrated Design Method

A practical privacy and security engineering workflow is:

1. Define purpose and obligations. Identify business objectives, lawful requirements, contracts, and affected people.
2. Inventory and classify. Record data elements, sensitivity, criticality, owners, and locations.
3. Map flows. Trace collection, processing, transfers, copies, analytics, backups, and disposal.
4. Assess risk. Consider threat actors, accidental disclosure, misuse, inference, availability failure, and discriminatory outcomes.
5. Minimise. Remove unnecessary fields, shorten retention, reduce precision, and limit copies.
6. Select controls. Combine authentication, authorisation, encryption, tokenisation, segregation, monitoring, DLP, and recovery controls.
7. Test and validate. Conduct access reviews, configuration checks, restoration tests, penetration tests, privacy assessments, and re-identification testing where relevant.
8. Operate and improve. Monitor control performance, investigate exceptions, update maps, and revise controls when systems or risks change.

Security architecture should use defence in depth. No single control is reliable in every circumstance, and controls can conflict. For example, extensive logging may improve detection while increasing privacy exposure. The design should therefore minimise logs, restrict access, set retention limits, and document the balancing decision.

10. Illustrative Case: Health-Service Appointment Platform

Background

A regional health provider operates an online appointment platform. It processes names, contact details, appointment reasons, clinician notes, payment information, and audit logs. A cloud supplier hosts the application, while an analytics supplier receives extracts.

Problem

An assessment discovers that the analytics extract contains full names and exact appointment times, although analysts need only age bands, service categories, regional aggregates, and a stable record identifier. Support staff have broad database access, backups are retained indefinitely, and a spreadsheet export is emailed weekly.

Analysis

The data map shows four unnecessary exposure paths: identifiable analytics extracts, broad support access, uncontrolled email exports, and indefinite backup retention. Appointment reasons may reveal sensitive health information. The spreadsheet is also outside central monitoring and may be copied to personal devices.

Approach and solution

The provider first defines purposes and assigns an information owner. It removes names and exact times from analytics, replaces the patient identifier with a controlled pseudonym, and aggregates small groups to reduce re-identification risk. The linkage table is held by a separate service with stricter access.

Support access is redesigned using RBAC plus temporary elevation, multi-factor authentication, ticket-based approval, and session logging. Database fields are encrypted at rest and communications use authenticated secure transport. Payment data is tokenised through a specialist provider rather than stored in the appointment database.

The weekly spreadsheet is replaced by a governed dashboard. DLP monitors attempted exports and requires approval for exceptional transfers. Backups are encrypted, separated from production credentials, made immutable for a defined period, and tested through quarterly restoration exercises. A retention schedule distinguishes clinical records, operational logs, temporary extracts, and backups. Disposal is verified and recorded.

Outcome

Routine analytics no longer receives direct identifiers, support personnel cannot browse records without a documented need, and uncontrolled email exports are eliminated. The organisation retains sufficient information for care, billing, audit, and service improvement while reducing exposure and improving evidence of compliance.

Learning points

1. Mapping revealed risks that were invisible in the main database design.
2. Pseudonymisation reduced routine exposure but did not remove privacy obligations.
3. Access, retention, DLP, and backup controls must be designed together.
4. Usable alternatives, such as governed dashboards, are more effective than simply banning business activity.

11. Governance, Ethics, and Contemporary Developments

Data security is a governance responsibility, not solely an IT function. Data owners approve purposes and access; security teams define technical controls; privacy professionals assess proportionality and rights; procurement teams manage suppliers; and senior leadership accepts or rejects residual risk.

Organisations should maintain policies for classification, access, encryption, retention, incident response, supplier processing, and secure disposal. Contracts should address confidentiality, subprocessors, breach notification, location, assistance with rights requests, deletion or return, audit, and secure development.

Ethical review is essential when data is used for profiling or artificial intelligence. Even properly protected data can produce discriminatory outcomes if collection is biased, labels are inaccurate, or models infer sensitive characteristics. Training data should be minimised, provenance recorded, access restricted, and outputs evaluated for privacy leakage and unfair impact. Synthetic data can reduce exposure but may preserve or amplify patterns from its source; it must not be assumed safe without testing.

Contemporary architectures increasingly use zero-trust principles, confidential computing, privacy-enhancing technologies, decentralised identity, automated classification, and policy-as-code. These tools are valuable but do not replace governance. Automated classification can mislabel data; confidential computing can complicate operations; and privacy-enhancing techniques may reduce analytical accuracy or make results difficult to interpret.

Challenges and Limitations

Several recurring challenges affect implementation:

• Incomplete visibility: mergers, cloud services, shadow IT, and legacy systems create unknown copies.
• Classification ambiguity: sensitivity can depend on context and combinations of fields.
• Control tension: monitoring may conflict with minimisation; encryption may conflict with inspection and recovery.
• Operational complexity: key rotation, access recertification, and deletion across replicas require automation.
• Human behaviour: staff may bypass controls if approved workflows are slow or unusable.
• Third-party dependency: suppliers may create new locations, subprocessors, and transfer risks.
• Anonymisation limits: auxiliary data and future analytical methods can enable re-identification.
• Backup persistence: deletion from production does not immediately remove every protected recovery copy.

A mature programme measures not only whether a control exists, but whether it works. Useful indicators include percentage of mapped systems, overdue access reviews, unauthorised-transfer events, restoration-test success, unresolved retention exceptions, encryption-key coverage, and time to fulfil rights requests. Metrics should inform decisions rather than encourage superficial compliance.

Chapter Summary

Data security and privacy engineering apply controls across the entire data lifecycle. Classification identifies sensitivity, integrity, availability, regulatory, ownership, and retention characteristics. Data mapping reveals flows, copies, trust boundaries, transformations, and external recipients. Minimisation, purpose limitation, quality controls, retention schedules, and verified disposal reduce unnecessary exposure.

Access control should combine least privilege, need to know, separation of duties, strong authentication, time-limited privilege, and review. Encryption protects data when keys are properly managed; hashing is distinct from encryption. Tokenisation substitutes a protected value, pseudonymisation reduces routine identifiability while preserving controlled re-identification, and anonymisation seeks to make identification infeasible but must account for auxiliary data and changing technology.

Backups provide resilience but create additional sensitive copies. RPO, RTO, isolation, immutability, encryption, and restoration testing are essential. DLP combines detection, context, and proportionate actions to control unauthorised movement. Effective programmes integrate technology, governance, ethics, supplier management, and usable operational processes.

Key Terms

Anonymisation: Processing intended to make identification infeasible using reasonably likely means.

Attribute-Based Access Control (ABAC): Access decisions based on subject, resource, action, and environmental attributes.

Availability: The ability of authorised users to access systems or data when required.

Data classification: Categorisation of data according to sensitivity, criticality, regulation, or business value.

Data-flow map: A representation of how data moves between people, systems, processes, and repositories.

Data minimisation: Limiting data collection and processing to what is necessary for a defined purpose.

Data Loss Prevention (DLP): Controls that detect and restrict unauthorised disclosure or movement of data.

Encryption: Transformation of plaintext into protected ciphertext using a cryptographic key.

Integrity: Protection of data from unauthorised or improper alteration.

Key management: Generation, storage, distribution, rotation, use, revocation, and destruction of cryptographic keys.

Least privilege: Granting only the permissions required for an approved task.

Pseudonymisation: Replacing identifiers while retaining a separately controlled means of re-identification.

Purpose limitation: Using data only for specified, legitimate, and compatible purposes.

Recovery Point Objective (RPO): The maximum acceptable amount of data loss expressed as a time interval.

Recovery Time Objective (RTO): The target time within which a service or system should be restored.

Retention schedule: A documented rule specifying how long data is kept and how it is disposed of.

Role-Based Access Control (RBAC): Assigning permissions to roles associated with job functions.

Tokenisation: Replacing a sensitive value with a token linked through a protected mechanism.

Trust boundary: A point where data or control crosses between environments with different security assumptions.

Review Questions

Short Answer Questions

1. What are the three objectives of the traditional information-security triad?
2. Why is pseudonymised data generally still considered personal data?
3. State two dimensions of data minimisation.
4. What is the difference between encryption and hashing?
5. Why must backup restoration be tested rather than merely scheduled?

Long Answer Questions

1. Explain how an organisation should create and maintain a lifecycle-based data inventory and data-flow map.
2. Compare RBAC and ABAC, including their strengths, limitations, and suitable use cases.
3. Explain the differences between tokenisation, pseudonymisation, and anonymisation.
4. Discuss how retention, legal holds, backups, and secure disposal should be coordinated.
5. Describe a defence-in-depth architecture for protecting sensitive data in a cloud-hosted application.

Analytical / Application Questions

1. A university collects full birth dates, home addresses, and national identifiers for a student analytics project that only requires age bands and campus region. Analyse the minimisation, classification, access, and retention changes you would recommend.
2. A company has encrypted backups, but the backup administrator uses the same credentials as the production database administrator. Evaluate the risk and propose improvements to key management, segregation, monitoring, and recovery testing.
3. An analytics team requests a dataset containing pseudonymous customer IDs, precise timestamps, postcode, age, and rare service categories. Assess re-identification risk and design a safer release process, explaining what analytical utility may be lost.

Multiple Choice Questions with Answers

Question 1

Which principle requires an organisation to collect and process only the information necessary for a defined purpose?

A. Data minimisation

B. Availability

C. Separation of duties

D. Non-repudiation

Correct Answer: A. Data minimisation

Question 2

Which statement best describes pseudonymisation?

A. It permanently destroys all links to an individual.

B. It replaces identifiers while retaining a controlled means of re-identification.

C. It encrypts data without using keys.

D. It makes data publicly accessible without restriction.

Correct Answer: B. It replaces identifiers while retaining a controlled means of re-identification.

Question 3

What is the primary purpose of a data-flow map?

A. To calculate processor speed

B. To show how data moves between systems, actors, and repositories

C. To replace all access-control policies

D. To determine an employee's salary

Correct Answer: B. To show how data moves between systems, actors, and repositories

Question 4

Which control most directly supports the principle of least privilege?

A. Giving all staff administrator access

B. Granting only permissions required for an approved task

C. Retaining all logs indefinitely

D. Disabling authentication for internal users

Correct Answer: B. Granting only permissions required for an approved task

Question 5

Why is authenticated encryption preferred over confidentiality-only encryption?

A. It detects unauthorised modification as well as protecting confidentiality.

B. It eliminates the need for key management.

C. It makes passwords unnecessary.

D. It guarantees that authorised applications cannot be compromised.

Correct Answer: A. It detects unauthorised modification as well as protecting confidentiality.

Question 6

Which statement about tokenisation is correct?

A. A token is always anonymous data.

B. Tokenisation replaces a sensitive value with a value linked through a protected mechanism.

C. Tokenisation means storing passwords in plaintext.

D. Tokenisation removes the need for access control.

Correct Answer: B. Tokenisation replaces a sensitive value with a value linked through a protected mechanism.

Question 7

In backup planning, RPO primarily describes:

A. The maximum acceptable time to restore service

B. The maximum acceptable amount of data loss measured in time

C. The number of administrators required

D. The encryption algorithm selected

Correct Answer: B. The maximum acceptable amount of data loss measured in time

Question 8

Which practice best tests whether backups are genuinely useful?

A. Checking that a backup job produced a success message

B. Performing realistic restoration exercises

C. Increasing the backup file name length

D. Removing backup encryption

Correct Answer: B. Performing realistic restoration exercises

Question 9

What is a major limitation of simple anonymisation by removing names?

A. It always prevents statistical analysis.

B. Other attributes may still identify people when combined with auxiliary data.

C. It makes data more confidential than encryption in every case.

D. It automatically deletes all copies.

Correct Answer: B. Other attributes may still identify people when combined with auxiliary data.

Question 10

Which DLP response is generally most proportionate for an uncertain, low-confidence detection?

A. Automatically destroy the user's device

B. Use monitoring or warning while validating the rule

C. Publish the data externally

D. Disable all organisational email permanently

Correct Answer: B. Use monitoring or warning while validating the rule