The General Data Protection Regulation (GDPR) regulates the processing of personal data<\/a> within its territorial scope. A compliance programme cannot begin with a generic privacy notice or a template consent banner. It needs an accurate account of what personal information the organisation collects, why it uses the information, where it travels, which systems and suppliers receive it, and when it is deleted. That account needs to reflect actual products and work processes rather than the descriptions in a procurement spreadsheet. A customer database, analytics platform, employee payroll system, and device telemetry service may have different purposes and legal requirements even when they share infrastructure.<\/p>\n Personal data can identify a person directly or indirectly. Names and contact details are obvious examples, but online identifiers, location information, and combinations of apparently ordinary attributes can also identify people. Pseudonymisation can reduce certain risks without automatically taking information outside GDPR. Organisations should distinguish data that remains identifiable from information genuinely anonymised so that individuals are no longer identifiable by means reasonably likely to be used. The distinction matters when building analytics and testing datasets: copying production records into a development environment is not harmless simply because it has a different label.<\/p>\n A processing inventory should record the controller or processor role, categories of people and data, purpose, lawful basis, recipients, retention, transfer arrangements, and safeguards. GDPR Article 30 describes records-of-processing requirements and exceptions. The operational objective goes further than producing a document for regulators: the record should tell an engineer, business owner, or privacy professional which systems must change when a purpose changes, a contract ends, or a person exercises a legal right.<\/p>\n Article 5 sets out principles that include lawfulness, fairness, transparency, purpose limitation, data minimisation, accuracy, storage limitation, security, and accountability. Article 6 sets out possible bases for lawful processing. Consent is one basis, but it is not the default for every system. Processing may instead be necessary for a contract, legal obligation, vital interests, public task, or legitimate interests where the conditions apply. The organisation needs to determine and document the appropriate basis for each activity rather than switch between bases opportunistically when a user withdraws permission.<\/p>\n A marketing team might want to reuse customer-support transcripts to personalise offers. Even if it can technically access the transcripts, the proposed new purpose requires a distinct legal and fairness assessment. Compatibility with the original purpose, notices, lawful basis, the reasonable expectations of people, and potential risks all matter. Similarly, requesting a passport scan to deliver a simple software trial would be difficult to justify under data minimisation unless a specific requirement makes that information necessary.<\/p>\n Special categories of personal data, such as health or biometric information used to uniquely identify someone, are subject to additional restrictions under Article 9. An Article 6 basis alone does not make every special-category processing activity permissible. Product teams should recognise this early, especially in employment, insurance, education, and health-related services, where apparently routine features may reveal sensitive details.<\/p>\n A controller determines the purposes and essential means of processing; a processor acts on a controller’s instructions. A technology company may be a processor for a client’s hosted customer records while independently acting as controller for its own recruiting and billing data. The same organisation can occupy different roles for different activities, so one blanket claim that it is ‘only a processor’ is rarely adequate.<\/p>\n Article 28 requires suitable contractual arrangements when a controller uses a processor. The contract should address documented instructions, confidentiality, assistance, security, subcontracting, deletion or return, and audit or information obligations. A supplier’s assurance statement is not enough if the service enables uncontrolled onward access or retains customer copies indefinitely. Procurement reviews should therefore combine contract terms with realistic security and architecture evidence.<\/p>\n For cross-border operations, identify where data is accessed as well as where it is stored. An EU-region database may still be accessible to an overseas support team. Transfers governed by GDPR Chapter V may require an adequacy decision, appropriate safeguards such as standard contractual clauses, or a valid exception, depending on the circumstances. Teams should consult current regulatory guidance instead of assuming that choosing a cloud region resolves every international-transfer question.<\/p>\n Transparency is an engineering as well as a legal obligation. Notices should explain purposes, lawful bases, relevant recipients, retention, and rights in understandable language. The description must match the actual behaviour of the product. A privacy notice stating that information is kept for thirty days is misleading if logs, backups, third-party exports, or model-training pipelines retain copies for substantially longer. Internal verification can reveal these mismatches before a complaint does.<\/p>\n GDPR provides rights that may include access, rectification, erasure, restriction, portability, objection, and protections concerning certain automated decisions, subject to conditions and exceptions. Building a functional rights workflow means being able to identify related records, verify the requester’s identity without collecting unnecessary new information, determine which exemptions apply, respond within applicable timelines, and preserve evidence of the decision. Some requests require legal assessment; they should not be treated as an unconditional delete button.<\/p>\n Consider a user who requests erasure after closing an account. The organisation may erase profile details from active systems while retaining limited financial records under a legal obligation. It must also consider downstream processors, search indexes, archives, and the practical limits of backup restoration. Clear explanations of what was deleted, what was retained, and why are more useful than a generic acknowledgement that the request is complete.<\/p>\n Article 25 addresses data protection by design and by default. In practice, this includes collecting only needed fields, using restrictive initial sharing settings, separating production and test access, limiting retention, and selecting privacy-preserving defaults before launch. Retrofitting access controls after users have shared large datasets is usually harder than restricting the exposure at the point of collection.<\/p>\n Data protection impact assessments (DPIAs) are required when a type of processing is likely to result in high risk to people’s rights and freedoms. The assessment should identify the activity, necessity, proportionality, risks, and measures intended to address them. Large-scale systematic monitoring or sensitive-data processing may be relevant warning signs, but no single buzzword automatically determines the outcome. Where high residual risk cannot be adequately reduced, consultation with the relevant supervisory authority may be required before processing starts.<\/p>\n A privacy review should be an actual release control: who is responsible for a decision, what evidence was considered, what conditions must be met, and when the feature needs reassessment. Teams implementing automated profiling or AI systems should also document training data provenance, inference outputs, model retention, user-facing explanations, and the accuracy of representations made about automated decisions.<\/p>\n Article 32 calls for security appropriate to the risk, taking account of factors such as the nature of processing and available measures. Encryption, access control, authentication, logging, backups, vulnerability management, and staff training can all contribute, but none alone proves compliance. Encryption does not prevent an authorised account from misusing data, and a strong identity provider does not fix unrestricted exports by a connected application.<\/p>\n A practical security review asks which personal information would be exposed if a system administrator account were compromised, a cloud bucket were published accidentally, or a supplier’s API token were stolen. Least-privilege permissions, separation of duties, service-account rotation, and detection of unusual exports should follow from those scenarios. Incident exercises should include legal, engineering, communications, and supplier-management teams because breach response is not just a technical containment problem.<\/p>\n Under Article 33, a controller generally must notify the supervisory authority without undue delay and, where feasible, within 72 hours after becoming aware of a personal-data breach unless the breach is unlikely to result in a risk to individuals’ rights and freedoms. Article 34 may require communication to affected people where the breach is likely to result in high risk, subject to its conditions. A processor must notify its controller without undue delay after becoming aware of a breach. These are risk- and role-dependent duties; not every security incident triggers the same notice.<\/p>\n Accountability means being able to demonstrate what was decided and what controls actually operated. Useful evidence includes a maintained inventory, legal-basis records, security assessments, retention schedules, processor contracts, training logs, access reviews<\/a>, incident reports, and records of rights requests. The objective is not to accumulate policy files; it is to prove that policies correspond to behaviour in the systems handling information.<\/p>\n Retention is a good test of that discipline. A policy may say that inactive customer records are removed after a certain period, but engineers need deletion jobs, exception handling, logs, and tests showing that the policy is followed. If a backup is restored, the organisation needs to avoid reintroducing information that should not return to active use. These details make a difference when auditors or regulators evaluate whether commitments were meaningful.<\/p>\nLawful basis and purpose limitation shape product decisions<\/h3>\n
Controller and processor responsibilities are not interchangeable<\/h3>\n
Give people meaningful information and workable rights<\/h3>\n
Privacy by design depends on architecture and governance<\/h3>\n
Security measures and breach response must fit actual risks<\/h3>\n
Accountability is built from evidence, not slogans<\/h3>\n