Law and regulation / Directly applicable EU regulation

GDPR / AVGGovern personal data throughout its lifecycle

The GDPR governs how organizations process personal data and how people can exercise their rights. Security is one part of a wider accountability model that also covers purpose, lawful basis, transparency, minimization, retention, processors and international transfers.

Start with applicability

What it actually covers

A system may be technically secure yet collect too much data, retain it too long or use it for an unexpected purpose. GDPR asks teams to justify and explain processing, protect people through design and operation, and show how decisions were made.

Scope

It applies to processing in the context of an EU establishment and can also reach non-EU organizations that offer goods or services to, or monitor the behavior of, people in the EU. The duties differ for controllers and processors and depend on the type and risk of processing; some rules have specific thresholds or exceptions.

Boundary

Consent is one possible lawful basis, not a universal requirement or a cure for every processing activity. GDPR is not an information-security certificate: ISO/IEC 27001 or 27701 can help organize controls and evidence, but neither proves that a particular use of personal data is lawful. A security incident is reportable under GDPR only when it is a personal-data breach meeting the relevant risk test.

The substance

Key areas to understand

An original operational reading of the official framework or legal text. Check the source for the authoritative wording.

01

Purpose, principles and lawful basis

Define why personal data is processed, select an Article 6 basis for each purpose, apply the Article 5 principles and be able to demonstrate the choices. Additional Article 9 conditions matter for special-category data.

02

People's rights and transparency

Provide clear information and a workable route for access, correction, erasure, restriction, portability, objection and the safeguards around qualifying automated decisions, subject to each right's conditions.

03

Accountability by design

Assign controller and processor roles, maintain processing records where required, use appropriate processor agreements, assess high-risk processing through a DPIA, and appoint a data protection officer when the legal conditions are met.

04

Security and breach response

Use risk-appropriate technical and organizational safeguards and regularly evaluate them. A controller notifies the authority within 72 hours after awareness of a personal-data breach unless risk to people is unlikely; affected people may need prompt notice when high risk is likely. Processors alert controllers without undue delay.

05

International transfers

When personal data moves outside the EEA, identify the transfer, legal route and supplementary safeguards where needed; a cloud hosting location alone does not answer the transfer question.

From reference to work

A practical starting sequence

These steps organize work; they are not a claim that a short checklist completes the requirement.

  1. Inventory purposes and data flows

    Map categories of people and data, systems, recipients, retention periods, transfer locations and the owner of each processing purpose.

  2. Make rights operational

    Route requests to an accountable team, verify identity proportionately, locate data across vendors and backups, document decisions and meet applicable response deadlines.

  3. Put privacy reviews into change management

    Check new analytics, AI, monitoring and vendor changes for lawful basis, minimization, notices, processor terms, DPIA triggers and transfer implications before launch.

  4. Practice breach triage

    Separate a general security event from a personal-data breach, assess risk to people, preserve awareness time, coordinate controller-processor notifications and document even non-reportable breaches.

Make it inspectable

Evidence to look for

The right records depend on the entity, scope and chosen assessment route.

Illustrative situation

What this could look like

An organization wants to add employee-behavior analytics. Before launch it identifies the purpose and lawful basis, reduces collection to what is needed, updates employee notices, reviews the vendor contract and transfer route, assesses whether a DPIA is required, and sets access and retention limits. A later leak is triaged against GDPR breach risk, not reported solely because a security alert exists.

Keep the role clear

Consent is one possible lawful basis, not a universal requirement or a cure for every processing activity. GDPR is not an information-security certificate: ISO/IEC 27001 or 27701 can help organize controls and evidence, but neither proves that a particular use of personal data is lawful. A security incident is reportable under GDPR only when it is a personal-data breach meeting the relevant risk test.

Related, not equivalent

Where ISO/IEC can help

ISO/IEC 27701 can extend a management system with privacy information management, while 27001 and 27002 support information-security controls. These are useful operating tools but do not decide the lawful basis, individuals' rights or transfer conditions under GDPR.

Common distinctions

Questions worth asking

Do we always need consent?

No. Article 6 provides several lawful bases. Choose the basis that actually fits the purpose and document it; consent has its own strict conditions and is not interchangeable with other bases.

Is every cyber incident a 72-hour GDPR report?

No. First determine whether personal data was breached and assess risk to people. A controller reports to the supervisory authority within 72 hours unless that risk is unlikely; higher risk can also require notice to affected people.

Does ISO/IEC 27701 certification demonstrate GDPR compliance?

It may support privacy governance evidence, but GDPR compliance is assessed against the actual processing, roles, lawful bases, rights, safeguards and applicable law.

Primary-source trail

Read the official material

Research checked 2026-10-20. Edition, applicability and implementation rules can change. The links below take you to the responsible publisher or authority.