Data Protection, Privacy and Secure Development

Introduction

Modern organisations depend on data and software. Customer records, employee information, payment details, health information, intellectual property and operational logs support everyday decisions and services. At the same time, poorly protected data and insecure software can create financial loss, legal exposure, safety risks and damage to public trust.

Data protection and secure development are therefore connected disciplines. Data protection asks how information should be classified, collected, used, shared, retained and destroyed. Secure development asks how software can be designed and operated so that confidentiality, integrity, availability and privacy are protected throughout its life. Both require technical controls, sound governance and responsible human behaviour.

This chapter presents practical foundations for a certificate-level cybersecurity practitioner. It focuses on the data lifecycle, privacy principles, data loss prevention, secure disposal, secure software development, threat modelling, common web vulnerabilities, security testing and DevSecOps.

Learning Objectives

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

• classify information according to sensitivity and business impact;
• explain how data is protected throughout its lifecycle;
• apply minimisation, retention, loss-prevention and disposal controls;
• distinguish privacy from information security;
• describe secure software development lifecycle activities;
• perform a basic threat-modelling exercise;
• recognise common web vulnerabilities and suitable mitigations;
• explain the purpose and limitations of security testing; and
• describe how DevSecOps integrates security into software delivery.

1. Data Protection as a Lifecycle Discipline

Data protection is not a single product or configuration. It is a coordinated set of administrative, technical and physical safeguards applied from the moment data is created or collected until it is securely destroyed. A useful lifecycle is:

1. create or collect;
2. classify and record;
3. store and use;
4. share or transfer;
5. retain or archive; and
6. dispose or destroy.

Controls must remain appropriate as data changes location and purpose. For example, a customer document may be collected through a web form, stored in a database, copied into a backup, transmitted to a payment provider, included in an audit log and eventually deleted. Deleting the original file does not necessarily delete all copies.

Figure: A data lifecycle in which protection controls continue across collection, use, sharing, retention and disposal.

2. Data Classification and Handling

Classification assigns a protection category to data so that people and systems can handle it consistently. A simple organisational scheme is shown below.

Classification should reflect both sensitivity and impact. A publicly available document may have high integrity requirements if an altered version could cause harm. A low-sensitivity dataset may become sensitive when combined with other datasets; this is known as aggregation risk.

Handling rules should specify who may access the data, where it may be stored, whether it may be emailed or copied to removable media, how it must be encrypted, how long it should be retained and how it must be destroyed. Labels alone are insufficient: the organisation must enforce the rules through access controls, storage settings, monitoring and user training.

3. Privacy Principles and Security Controls

Privacy concerns the appropriate collection and use of information about identifiable people. Information security is broader: it protects information and systems against unauthorised disclosure, alteration, destruction or interruption. Security is necessary for privacy, but privacy also includes questions of purpose, fairness, transparency and individual rights.

Common privacy principles include:

• Purpose limitation: collect and use information for specified, legitimate purposes.
• Data minimisation: collect only what is necessary for the stated purpose.
• Accuracy: keep personal information correct and provide ways to correct it.
• Storage limitation: do not retain information longer than necessary.
• Transparency: explain what is collected, why, how it is used and with whom it is shared.
• Accountability: document decisions and demonstrate compliance.
• Individual participation: where applicable, support access, correction, deletion or objection rights.

Legal obligations differ by jurisdiction and sector. Organisations must therefore consult applicable privacy and records-management requirements rather than assuming that one global rule applies. Important governance questions include who determines the purpose of processing, who processes data on another party’s behalf, where data is transferred, how incidents are reported and how third parties are assessed.

Privacy by Design and Default

Privacy should be considered before implementation rather than added after deployment. Examples include using a short-lived identifier instead of a full name, collecting an age range instead of an exact birth date, making optional data fields genuinely optional and setting the least intrusive sharing option as the default.

Anonymisation aims to remove the ability to identify individuals, while pseudonymisation replaces direct identifiers with codes. Pseudonymised data may still be personal data if the code or additional information can reconnect it to a person. Removing names alone is not necessarily anonymisation because combinations of attributes can re-identify people.

4. Minimisation, Retention and Disposal

Data Minimisation

Before collecting a field, ask:

1. What decision or service requires it?
2. Is the field necessary, or merely convenient?
3. Can a less precise value serve the purpose?
4. Who will access it?
5. What risks arise if it is exposed?

Minimisation reduces breach impact, storage cost, attack surface and compliance obligations. It also improves data quality by discouraging the accumulation of irrelevant information.

Retention Management

Retention should be based on business need, legal obligations, contractual commitments and risk. A retention schedule identifies the record category, event that starts the retention period, retention duration, legal hold requirements, owner and disposal method. Retention is not the same as indefinite backup preservation. Backup copies should have their own lifecycle and deletion policy.

A legal hold or investigation may suspend ordinary deletion. Staff must know how to preserve relevant information without altering it. Retention periods should be reviewed when a service, law, contract or business purpose changes.

Secure Disposal

Disposal must make recovery impractical for the expected adversary and technology. Appropriate methods include:

• cryptographic erasure by securely destroying encryption keys, where encryption and key management are reliable;
• secure erasure using a method appropriate to the storage medium;
• physical destruction of media when reuse is not permitted; and
• certified disposal by an approved provider, with records of assets and certificates.

Simply deleting a file usually removes a directory reference rather than destroying every recoverable representation. Reformatting may also be inadequate. Disposal should cover production data, temporary files, cached data, exported reports, removable media, cloud snapshots and backups. A disposal record should identify what was destroyed, when, by which method and under whose authorisation.

5. Data Loss Prevention and Access Control

Data loss prevention (DLP) seeks to prevent unauthorised disclosure, accidental exposure and inappropriate movement of sensitive information. DLP may inspect email, web traffic, endpoints, cloud storage and removable media. Detection may use labels, regular expressions, dictionaries, file fingerprints or machine-learning classifiers.

DLP controls commonly include:

• blocking or quarantining an outbound message;
• warning a user and requiring a business justification;
• preventing copying to an unauthorised USB device;
• applying encryption or rights management;
• alerting security staff for investigation; and
• recording events for audit.

DLP is not a substitute for sound access control. Least privilege grants only the access required for a task. Separation of duties prevents one person from completing a sensitive process without oversight. Strong authentication, periodic access reviews, privileged-access management and timely removal of leavers’ accounts support these principles.

DLP has limitations. False positives can interrupt legitimate work, while encrypted files, screenshots, photographs and novel data formats can evade inspection. Controls should be risk-based, tested with representative workflows and accompanied by clear escalation procedures. Monitoring must also respect privacy and applicable employment or communications laws.

6. Secure Software Development Lifecycle

A secure software development lifecycle (SSDLC) integrates security into requirements, design, implementation, testing, release and maintenance. Security activities should occur early because defects discovered late are generally more expensive and disruptive to correct.

Security requirements should be testable. “The service must be secure” is vague; “administrative functions require multi-factor authentication and are logged” is more actionable. Privacy requirements should address collection, access, retention, deletion and user transparency.

Secure Coding Foundations

Developers should validate input according to expected type, length, range and format; encode output for its destination; use parameterised database queries; apply safe error handling; protect secrets outside source code; use well-maintained libraries; and avoid custom cryptography. Authentication, authorisation and session management deserve explicit design rather than assumptions.

Secrets such as API keys and passwords should be stored in an approved secret-management system, rotated when appropriate and excluded from source repositories and logs. Passwords should be stored using a suitable slow, salted password-hashing function rather than reversible encryption or plain hashing.

7. Threat Modelling

Threat modelling is a structured method for identifying what can go wrong, why it could happen and how risk can be reduced. It is most valuable during requirements and design, but it can be repeated when architecture or threats change.

A practical process is:

1. Define scope: identify the system, users, data and important business functions.
2. Identify assets: include personal data, credentials, transactions, service availability and intellectual property.
3. Draw data flows: show processes, stores, external entities and trust boundaries.
4. Identify threats: consider spoofing, tampering, repudiation, information disclosure, denial of service and elevation of privilege.
5. Assess risk: consider likelihood, impact and existing controls.
6. Choose mitigations: redesign, reduce exposure, add controls, transfer or formally accept the risk.
7. Validate: assign owners and revisit the model after changes.

A simple risk expression is often used for prioritisation:

Likelihood and impact may be qualitative categories such as low, medium and high. This expression is not a precise probability law; it is a communication and prioritisation aid. Its usefulness depends on consistent scales and documented assumptions.

For example, a public API accepts an account identifier and returns account details. Threat modelling may reveal that an attacker can alter the identifier and retrieve another user’s data. The mitigation is not merely logging; the service must enforce server-side authorisation for the authenticated user and test for cross-account access.

8. Common Web Vulnerabilities

Injection

Injection occurs when untrusted input is interpreted as commands or queries. SQL injection is reduced by parameterised queries, safe database APIs, least-privileged database accounts and input validation. Validation is useful but should not be the sole defence because attackers can exploit parser differences and unexpected encodings.

Broken Access Control

A user may be authenticated yet not authorised to access a particular object or operation. Every sensitive request must perform server-side authorisation checks. Hiding a button in the interface is not an access-control mechanism.

Cross-Site Scripting

Cross-site scripting (XSS) occurs when attacker-controlled content is executed in another user’s browser. Context-appropriate output encoding, safe templating, input constraints, content security policy and careful handling of rich text reduce risk. Cookies should use appropriate Secure, HttpOnly and SameSite attributes.

Cross-Site Request Forgery

Cross-site request forgery (CSRF) tricks a browser into sending an unwanted request using an existing session. Anti-CSRF tokens, SameSite cookie settings, origin checks and re-authentication for high-risk actions are common defences. CSRF protections must be applied to state-changing operations, not only to login pages.

Security Misconfiguration

Examples include default passwords, unnecessary services, verbose production errors, permissive cloud storage, missing security headers and exposed management interfaces. Secure baselines, configuration review, automated checks and change management reduce this risk.

Identification and Authentication Failures

Weak passwords, credential stuffing, insecure recovery processes, missing multi-factor authentication and poorly managed sessions can allow account takeover. Controls include strong authentication, rate limiting, breached-password screening, secure session invalidation and monitoring for anomalous activity.

Vulnerable Components

Third-party libraries and build tools introduce inherited risk. Organisations should maintain an inventory, monitor advisories, pin or constrain versions appropriately, verify package integrity, remove unused dependencies and have a process for emergency updates. A software bill of materials can improve visibility but does not itself remove vulnerabilities.

Insecure Design and Logging Failures

A system can be implemented exactly as specified and still be insecure if the design permits excessive data exposure or unsafe business logic. Logging should support detection and investigation without recording passwords, tokens or unnecessary personal data. Logs require integrity, access control, time synchronisation, retention and alerting.

9. Security Testing

Security testing uses multiple techniques because no single method detects every defect.

• Static application security testing (SAST): examines source or compiled code without executing the application. It can identify patterns early but may generate false positives and miss runtime behaviour.
• Dynamic application security testing (DAST): tests a running application from the outside. It can reveal observable runtime issues but may not understand internal logic.
• Interactive application security testing (IAST): combines runtime observation with instrumentation and can provide contextual findings.
• Software composition analysis (SCA): identifies known vulnerabilities and licence information in dependencies.
• Fuzz testing: supplies unexpected or malformed inputs to discover crashes and failures.
• Manual review and penetration testing: examine business logic and attack paths that automated tools may miss.

Testing must be authorised and conducted safely. Production testing can cause outages, alter data or trigger monitoring responses. Findings should be triaged by severity, exploitability, affected assets and business impact. A scan report is not proof that a system is secure; it is evidence that particular tests produced particular results at a particular time.

10. DevSecOps

DevSecOps extends DevOps by making security a shared, continuous responsibility. Security activities are integrated into version control, build pipelines, infrastructure provisioning, deployment and operations rather than postponed to a final inspection.

A simplified pipeline may include:

1. developer commits code;
2. automated unit and security checks run;
3. dependencies and container images are scanned;
4. infrastructure configuration is checked;
5. an artefact is built reproducibly and signed;
6. deployment policies and approvals are evaluated;
7. monitoring detects operational problems; and
8. feedback creates backlog items and improvements.

Pipeline controls must be proportionate. Blocking every low-confidence finding encourages teams to bypass security; ignoring all findings provides no protection. Teams should define severity thresholds, exception expiry dates, ownership and service-level expectations. Security champions can help development teams interpret findings, while security specialists provide governance and expert support.

Infrastructure as code enables repeatable review and testing, but insecure code can reproduce insecure infrastructure at scale. Cloud identities, network rules, storage permissions, secrets and logging must be treated as code-controlled security concerns.

11. Applied Case: Illustrative Online Health-Appointment Service

Background

A fictional clinic launches an online appointment service. Patients create accounts, submit contact and health information, choose appointments and receive email reminders. The service uses a web application, a cloud database, an email provider and a support dashboard.

Problem

An initial review finds that the application stores more information than necessary, permits support staff to view all patient notes, retains cancelled appointments indefinitely and includes patient email addresses in verbose application logs. A test also shows that changing an appointment number in a request may expose another patient’s appointment.

Analysis

The data is highly sensitive because it includes health information. The appointment number is an object reference, not proof of authorisation. The support dashboard violates least privilege, and indefinite retention conflicts with storage limitation unless a documented legal or clinical need exists. Logs create a secondary disclosure channel.

Threat modelling identifies information disclosure, account takeover, unauthorised modification and service interruption. Trust boundaries exist between patients, the web application, the database, the email provider and support staff.

Approach and Solution

The clinic adopts the following measures:

• documents a data inventory and classification scheme;
• removes nonessential demographic fields from registration;
• enforces server-side authorisation for every appointment request;
• separates clinical notes from ordinary scheduling data;
• limits support access by role and records privileged activity;
• masks or excludes health information and email addresses from routine logs;
• encrypts sensitive data in transit and at rest;
• establishes retention schedules for active records, cancelled appointments and backups;
• applies parameterised queries and output encoding;
• adds SAST, dependency scanning, DAST and manual authorisation tests to the pipeline;
• tests backup restoration and secure disposal; and
• creates an incident process for privacy breaches and lost credentials.

Outcome

The service reduces unnecessary collection and limits the number of systems containing sensitive data. Authorisation tests prevent cross-patient access, while role separation reduces internal exposure. The clinic still recognises that encryption and scanning do not eliminate all risk; governance, monitoring, user education and periodic review remain necessary.

Learning Points

The case demonstrates that privacy, access control, secure coding, retention and testing are interdependent. A technically functional application may still be unsafe if its data model, permissions and operational practices are poorly designed.

12. Governance, Ethics and Contemporary Developments

Cybersecurity professionals often handle information that can affect people’s employment, finances, health or reputation. Ethical practice requires confidentiality, proportionality, accuracy and respect for legitimate authority. Security monitoring should collect sufficient evidence for protection and investigation without becoming unjustified surveillance.

Artificial intelligence can assist with code review, anomaly detection, data classification and vulnerability prioritisation. However, AI-generated code may contain insecure assumptions, reproduce bias or expose confidential source material to an unauthorised service. AI outputs require human review, controlled data handling, testing and clear accountability. Automated classification can also create false positives and false negatives, especially for images, context-dependent information and multilingual data.

Contemporary organisations increasingly use cloud services, APIs, mobile applications, containers and software supply chains. These technologies make identity, configuration, dependency provenance, secrets management and continuous monitoring central security concerns. Zero-trust approaches reinforce the principle that access should be continuously evaluated rather than granted solely because a user or device is inside a network boundary.

Best-Practice Checklist

• Maintain a current data inventory and classification policy.
• Collect only what has a defined purpose.
• Apply least privilege and review access regularly.
• Encrypt sensitive information appropriately and protect keys.
• Define retention, legal-hold and disposal procedures.
• Control email, cloud sharing, removable media and endpoint copying.
• Threat-model important systems before implementation.
• Use secure coding standards and parameterised interfaces.
• Track dependencies and remediate vulnerabilities according to risk.
• Test authentication, authorisation and business logic—not only inputs.
• Integrate security checks into development pipelines.
• Log useful security events while minimising sensitive content.
• Plan for incidents, restoration, notification and lessons learned.
• Reassess controls when technology, purpose, suppliers or regulations change.

Chapter Summary

Data protection is a lifecycle responsibility covering collection, classification, storage, use, sharing, retention and disposal. Classification translates sensitivity and impact into practical handling rules. Privacy requires purpose limitation, minimisation, transparency, accuracy, storage limitation and accountability; security controls support these principles but do not replace them.

Retention schedules, legal holds and secure disposal prevent unnecessary accumulation. DLP, least privilege, encryption and monitoring reduce unauthorised disclosure, although they require careful tuning and privacy-aware governance. Secure development incorporates security and privacy into requirements, design, coding, testing, release and operation. Threat modelling identifies assets, trust boundaries, threats and mitigations before weaknesses become expensive to correct.

Common web risks include injection, broken access control, XSS, CSRF, misconfiguration, authentication failures and vulnerable components. SAST, DAST, SCA, fuzzing and manual testing provide complementary evidence rather than a guarantee of security. DevSecOps embeds proportionate controls and shared responsibility into delivery pipelines. The central professional lesson is that secure systems result from coordinated design, technology, process and ethical judgement.

Key Terms

Data lifecycle: The stages through which data passes from creation or collection to disposal.

Data classification: Assignment of a sensitivity category and handling requirements to information.

Data minimisation: Collecting and retaining only information necessary for a defined purpose.

Privacy: Appropriate and fair control over information about identifiable people.

Pseudonymisation: Replacing identifiers with codes while retaining a possible method of re-identification.

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

Retention schedule: A documented rule specifying how long a record is kept and when disposal occurs.

Legal hold: A requirement to preserve information despite ordinary deletion rules.

Data loss prevention: Controls that detect or prevent unauthorised movement or disclosure of data.

Least privilege: Granting only the access needed for an authorised task.

Secure software development lifecycle: Security activities integrated across software development and operation.

Threat modelling: Structured identification and treatment of threats to a system.

Trust boundary: A point where data or control moves between different levels of trust.

Injection: Treating untrusted input as executable commands or queries.

Cross-site scripting: Execution of attacker-controlled script in another user’s browser.

Static application security testing: Analysis of code or compiled artefacts without executing the application.

Software composition analysis: Examination of third-party components for vulnerabilities and licence issues.

DevSecOps: Integration of security into collaborative, automated development and operations practices.

Software bill of materials: An inventory of components included in a software product.

Review Questions

Short Answer Questions

1. What are the principal stages of the data lifecycle?
2. Why is pseudonymisation not necessarily anonymisation?
3. State two benefits and one limitation of data loss prevention.
4. What is the purpose of threat modelling?
5. Distinguish SAST from DAST.

Long Answer Questions

1. Explain how data classification should influence storage, access, sharing, retention and disposal decisions.
2. Discuss the relationship between privacy principles and information-security controls.
3. Describe a secure software development lifecycle and explain why security should begin during requirements and design.
4. Compare injection, broken access control and cross-site scripting, including suitable mitigations.
5. Explain how DevSecOps changes the roles, processes and technologies used to manage software security.

Analytical / Application Questions

1. A company discovers that a shared cloud folder contains employee identity documents and has anonymous public access. Analyse the immediate and longer-term actions required.
2. Design a basic threat model for a mobile banking application. Identify assets, trust boundaries, three threats and appropriate mitigations.
3. A development team receives 200 automated vulnerability findings before a release. Propose a risk-based triage and remediation approach that avoids both ignoring the findings and blocking delivery unnecessarily.

Multiple Choice Questions with Answers

Question 1

Which practice best demonstrates data minimisation?

A. Collecting every available customer attribute for future use

B. Collecting only the fields required for a documented service purpose

C. Keeping all historical records indefinitely

D. Copying sensitive data into several departmental systems

Correct Answer: B. Collecting only the fields required for a documented service purpose

Question 2

Which control directly addresses broken access control in an appointment application?

A. Hiding the appointment identifier from the user interface

B. Checking authorisation on the server for every requested appointment

C. Increasing the length of the application log

D. Changing the database font encoding

Correct Answer: B. Checking authorisation on the server for every requested appointment

Question 3

What is the main purpose of a retention schedule?

A. To specify how long records are kept and when disposal occurs

B. To make all backups permanent

C. To replace access-control reviews

D. To guarantee that no data breach can occur

Correct Answer: A. To specify how long records are kept and when disposal occurs

Question 4

Which technique examines source code without executing the application?

A. DAST

B. SAST

C. Penetration testing

D. Fuzz testing

Correct Answer: B. SAST

Question 5

Which practice most directly reduces SQL injection risk?

A. Parameterised database queries

B. Disabling application logs

C. Using longer usernames

D. Hiding the database hostname

Correct Answer: A. Parameterised database queries

Question 6

Why can deleting a file fail to destroy the data completely?

A. Deletion always increases file permissions

B. Copies may remain in backups, caches or other storage locations

C. Encryption makes every file public

D. Classification labels reproduce the file

Correct Answer: B. Copies may remain in backups, caches or other storage locations

Question 7

In threat modelling, what is a trust boundary?

A. A point where data or control crosses between different trust levels

B. A password expiration date

C. A physical fence around a data centre

D. A software licence agreement

Correct Answer: A. A point where data or control crosses between different trust levels

Question 8

Which statement best describes DevSecOps?

A. Security is performed only by a separate team before release

B. Security is integrated into development, delivery and operations

C. Security testing is prohibited in automated pipelines

D. Developers are excluded from security decisions

Correct Answer: B. Security is integrated into development, delivery and operations

Question 9

Which control is most appropriate for preventing unauthorised copying to removable media?

A. Data loss prevention policy and endpoint enforcement

B. Publicly displaying the classification policy

C. Removing all system clocks

D. Increasing screen brightness

Correct Answer: A. Data loss prevention policy and endpoint enforcement

Question 10

Why is a software bill of materials useful?

A. It proves that every component is vulnerability-free

B. It provides visibility into components that require assessment and updating

C. It replaces authentication testing

D. It guarantees that suppliers follow the same laws

Correct Answer: B. It provides visibility into components that require assessment and updating