Article 32 — Security of processing

1. The basic architecture of Article 32

Article 32 should not be understood merely as an "IT security" provision. It is a data protection provision implemented substantially through information-security techniques.

This distinction is important.

An organisation can have an excellent cybersecurity programme and still fail Article 32. Conversely, an organisation does not necessarily violate Article 32 merely because a security incident occurs.

The legal question is not:

"Did a breach happen?"

The more important question is:

"Before and during the processing, did the controller or processor implement security measures appropriate to the risks that could reasonably arise from that processing?"

This produces a crucial distinction between:

Security incident → something went wrong.

and

Article 32 violation → the security arrangements were inadequate in light of the risks.

Example

suppose a sophisticated ransomware attack compromises a hospital despite extensive encryption, network segmentation, multi-factor authentication, immutable backups, vulnerability management, penetration testing and incident-response procedures.

The mere fact that the attack succeeded does not automatically establish that Article 32 was violated.

Conversely, suppose a company stores millions of customer records containing identity documents in an unencrypted database accessible through the public internet. Even if no data have yet been stolen, the organisation may already be in serious difficulty under Article 32 because the security architecture itself is manifestly inadequate.

This is one of the most important conceptual points in the provision:

Article 32 is primarily a preventive and risk-management obligation, not merely a post-breach liability provision.

2. Article 32 and the principle of integrity and confidentiality

Article 32 is closely connected with Article 5(1)(f), which establishes the principle of integrity and confidentiality.

Article 5(1)(f) expresses the principle at a high level.

Article 32 operationalises it.

This relationship can be understood as:

Article 5(1)(f) → personal data must be processed securely.

Article 24 → the controller must implement appropriate measures and demonstrate compliance.

Article 25 → privacy and data protection must be built into processing by design and by default.

Article 32 → specific security measures must be designed around the risks of processing.

Articles 33 and 34 → when security nevertheless fails and a personal data breach occurs, notification obligations may arise.

Thus, Article 32 occupies a central position within the GDPR's accountability architecture.

It is also important that Article 32 does not merely protect confidentiality.

It expressly encompasses:

• confidentiality;

• integrity;

• availability;

• resilience;

• restoration;

• testing and evaluation.

Consequently, a security programme focused exclusively on preventing unauthorised access is incomplete.

Imagine an organisation that encrypts everything but has no viable backups.

It might have excellent confidentiality protection but terrible availability and recovery protection.

A ransomware incident could then make the data inaccessible to the organisation itself.

Article 32 therefore adopts a much broader concept of security.

3. Security is about the processing environment, not merely the database

A common mistake is to think of Article 32 as requiring security "of personal data" in isolation.

The provision is concerned with the security of processing.

That means the relevant security environment includes:

• applications;

• databases;

• cloud infrastructure;

• networks;

• endpoints;

• mobile devices;

• authentication systems;

• access-control systems;

• physical premises;

• paper records;

• employees;

• contractors;

• vendors;

• processors;

• backup infrastructure;

• development environments;

• testing environments;

• APIs;

• logging systems;

• incident-response mechanisms.

Consider an HR department.

The employee database might be encrypted and technically secure. But if HR employees routinely download spreadsheets containing employee salaries onto unencrypted laptops and send them through personal email accounts, the organisation cannot reasonably claim that its processing is secure merely because the central database is protected.

Article 32 therefore requires a systems-level assessment.

4. The risk-based nature of Article 32

The most important phrase in Article 32 is arguably:

"security appropriate to the risk"

The GDPR deliberately avoids prescribing one universal security standard.

It does not say:

Every organisation must use AES-256.

It does not say:

Every organisation must perform penetration testing every six months.

It does not say:

Every organisation must implement multi-factor authentication.

Instead, the GDPR requires organisations to determine what is appropriate in the circumstances of the particular processing operation.

This produces a risk-based model.

The basic sequence should be:

Identify processing → identify threats → identify vulnerabilities → assess likelihood → assess severity → determine risk → select measures → implement measures → test measures → reassess risk.

This is substantially different from a checklist approach.

5. Why the GDPR does not prescribe one fixed security standard

Technology changes rapidly.

A security control considered highly effective in 2016 may be inadequate in 2026.

New threats emerge:

• ransomware;

• credential stuffing;

• supply-chain attacks;

• zero-day vulnerabilities;

• deepfake-enabled social engineering;

• AI-assisted phishing;

• cloud misconfiguration;

• API exploitation;

• insider threats;

• automated scraping;

• credential theft.

If the GDPR prescribed a static list of technologies, Article 32 would quickly become obsolete.

The concept of appropriateness therefore provides technological neutrality.

The organisation must continuously ask:

"Given what we know about the technology, threat environment, nature of our processing and potential consequences, what level of protection is reasonably required?"

6. "Taking into account the state of the art"

The state of the art requirement prevents an organisation from defending outdated security practices simply because those practices were once common.

State of the art does not necessarily mean:

"Use the newest technology."

It means something closer to:

Take account of contemporary knowledge, technological capabilities, security practices and developments relevant to the processing.

Example

if strong encryption is widely available, inexpensive and mature, an organisation processing highly sensitive information may have difficulty justifying completely unencrypted storage.

Similarly, if phishing-resistant authentication mechanisms have become technically feasible for a particular high-risk environment, an organisation should consider whether its existing authentication architecture remains appropriate.

The assessment must nevertheless remain contextual.

The fact that an advanced technology exists does not automatically mean that Article 32 requires every organisation to implement it.

A small organisation processing ordinary contact information may not require the same security architecture as a national health database.

7. State of the art is dynamic

This creates an important compliance challenge.

A company cannot simply conduct a security assessment once and place it in a drawer.

Security controls must evolve.

Suppose a company performs a risk assessment in 2023 and determines that password-based authentication combined with other controls is adequate.

By 2026, the threat landscape may have changed significantly.

The organisation should therefore reassess:

• authentication threats;

• vulnerability exposure;

• attack techniques;

• available security technologies;

• supplier risks;

• regulatory expectations.

Article 32 is therefore inherently dynamic.

8. Costs of implementation

Article 32 expressly requires consideration of the costs of implementation.

This is sometimes misunderstood as a "security budget defence".

It is not.

The provision does not mean:

"If the security measure is expensive, you do not have to implement it."

Instead, cost is one factor in determining proportionality.

Suppose two organisations process identical categories of highly sensitive data.

Organisation A has extensive resources and processes millions of individuals.

Organisation B is a small organisation processing 2,000 individuals.

Their security obligations may not be identical.

But Organisation B cannot simply say:

"Strong security is too expensive."

The relevant question is whether the cost is proportionate to the risks and whether reasonably effective alternatives exist.

Cost therefore operates within the broader balancing exercise.

9. Nature of processing

The nature of processing concerns what kind of processing is occurring and what the processing entails.

Consider:

Example 1

Ordinary newsletter A company processes names and email addresses for a newsletter.

Example 2

Mental-health platform A platform processes psychiatric records, therapy notes and medication information. The security expectations will obviously differ. The second processing operation involves information whose compromise may create serious consequences for individuals. Likewise, biometric authentication, employee monitoring, financial profiling, children's data and criminal-offence information may require stronger security than routine contact information.

10. Scope of processing

The scope concerns the breadth and scale of the processing.

Relevant considerations may include:

• number of data subjects;

• geographical reach;

• volume of data;

• number of systems;

• duration of processing;

• number of personnel with access;

• number of processors;

• number of jurisdictions.

A security failure affecting 50 people is not necessarily equivalent to one affecting 50 million people.

Scale therefore affects risk.

But scale is not the only factor.

A database containing highly sensitive information concerning 500 people could represent greater risk than a database containing basic information about 500,000 people.

11. Context of processing

Context requires attention to the circumstances surrounding the processing.

For example:

A company may process names and addresses.

That sounds low-risk.

But suppose the names and addresses belong to:

• domestic-abuse survivors;

• witnesses;

• political dissidents;

• children;

• protected employees.

The same data fields can produce radically different risks depending upon context.

This is why a purely categorical approach to security is insufficient.

Security cannot be determined solely by looking at the database columns.

12. Purpose of processing

Purpose also matters.

Suppose an organisation collects photographs.

The security requirements may differ depending on whether the photos are:

• ordinary product photographs;

• employee photographs;

• biometric identification templates;

• photographs used for law-enforcement purposes;

• photographs used to infer sensitive characteristics.

The processing purpose influences the potential consequences of compromise or misuse.

13. Likelihood and severity of risks

Article 32 requires consideration of risks with varying likelihood and severity.

This introduces two dimensions.

Likelihood

How likely is the adverse event to occur?

Severity

How serious would the consequences be if it occurred?

A useful conceptual model is:

Risk = likelihood × impact

Although the GDPR does not prescribe a particular mathematical formula, the concept helps organisations structure their reasoning.

14. High likelihood, moderate impact

Suppose an organisation's employees frequently lose unencrypted laptops.

The impact of any individual loss may be moderate, but the likelihood may be high.

Appropriate measures might therefore include:

• device encryption;

• mobile-device management;

• remote wipe;

• automatic screen locking;

• endpoint monitoring;

• employee training.

15. Low likelihood, catastrophic impact

Consider a highly secure research database containing information that could seriously endanger individuals if exposed.

A catastrophic attack may be relatively unlikely.

But the consequences could be enormous.

The organisation may therefore need stronger controls despite the lower likelihood.

This is why an organisation cannot justify weak security simply by claiming:

"Nobody has attacked us yet."

Risk analysis concerns potential future harm, not merely historical incidents.

16. Article 32 does not require perfect security

This is another fundamental point.

No system can realistically guarantee zero risk.

Even highly sophisticated organisations can suffer:

• zero-day attacks;

• insider abuse;

• sophisticated social engineering;

• supply-chain compromises;

• physical disasters.

The GDPR therefore does not demand absolute security.

The legal standard is appropriate security.

This is a proportionality standard.

The objective is to reduce risks to an appropriate level.

17. But "no system is perfectly secure" is not a defence

There is an important limit.

An organisation cannot deliberately maintain inadequate controls and then argue:

"Perfect security is impossible."

That misses the point.

The law does not demand perfection.

It demands reasonable, risk-appropriate protection.

For example:

A company knows that its database is exposed to the internet.

It knows the database contains identity documents.

It knows encryption is available.

It nevertheless refuses to implement basic access controls because "all systems can be hacked anyway."

That is very different from suffering an attack despite robust security.

18. Technical and organisational measures

Article 32 deliberately refers to both technical andorganisational measures.

This is crucial.

Cybersecurity is not merely an IT problem.

Technical measures

Examples

include:

• encryption;
• pseudonymisation;
• firewalls;
• access controls;
• MFA;
• intrusion detection;
• endpoint protection;
• network segmentation;
• secure configuration;
• logging;
• vulnerability management;
• backups.

Organisational measures

Examples

include:

• security policies;
• employee training;
• incident-response procedures;
• access approval processes;
• supplier-management procedures;
• risk assessments;
• security governance;
• disciplinary procedures;
• business continuity plans;
• security awareness programmes. A technically sophisticated system can still be insecure if employees routinely circumvent controls.

19. Why one security measure is never enough

Article 32 refers to measures in the plural because effective security normally requires layers of protection.

Imagine an organisation uses passwords as its sole security control.

If credentials are stolen, the attacker gets access.

Now introduce:

Password + MFA + least privilege + network segmentation + monitoring + encryption + incident response.

An attacker may still succeed, but compromising one layer does not automatically compromise everything.

This is commonly understood as a defence-in-depth approach.

Article 32 strongly supports such layered thinking.

20. Pseudonymisation

Pseudonymisation is expressly identified as an example of an Article 32 security measure.

Under the GDPR, pseudonymisation involves processing personal data so that the data cannot be attributed to a particular individual without additional information, with that additional information kept separately and protected.

For example:

A hospital assigns:

Patient → P-483920

The analytics team receives:

P-483920 | Treatment outcome | Age bracket | Treatment date

The identity mapping is kept separately.

If the analytics database is compromised, the attacker may face greater difficulty identifying the individual.

But pseudonymisation does not make the data anonymous.

This distinction is extremely important.

21. Pseudonymisation is not anonymisation

Suppose a company replaces:

"Shubhank Suman"

with:

"User 78291"

If the company possesses the mapping table, the individual remains identifiable.

Therefore the information remains personal data.

Pseudonymisation reduces risk.

Anonymisation, when genuinely effective, removes the data from the GDPR's personal-data framework.

This distinction affects:

• applicability of GDPR;

• security assessments;

• data-sharing;

• retention;

• data-subject rights.

22. Encryption

Encryption is another expressly identified security measure.

Encryption transforms readable information into an unintelligible form using cryptographic techniques.

The importance of encryption lies in reducing the consequences of unauthorised access.

For example:

A stolen laptop containing encrypted customer data may create substantially less risk than a stolen laptop containing plaintext customer records.

Encryption can apply:

• at rest;

• in transit;

• sometimes in use through specialised techniques.

23. Encryption is not automatically sufficient

This is a classic Article 32 trap.

An organisation might say:

"Everything is encrypted, therefore we comply."

Not necessarily.

Questions remain:

• Who controls the keys?

• Where are keys stored?

• Who can decrypt?

• Are keys rotated?

• Are encryption algorithms obsolete?

• Is data encrypted during transmission?

• Are backups encrypted?

• Are logs protected?

• Are endpoints protected?

• Is access appropriately restricted?

Poor key management can undermine otherwise strong encryption.

24. Confidentiality

Confidentiality means ensuring that personal data are not accessed or disclosed by unauthorised persons.

Relevant controls can include:

• role-based access control;

• least privilege;

• MFA;

• encryption;

• identity management;

• physical access restrictions;

• secure authentication;

• confidentiality agreements;

• employee training.

But confidentiality also has an organisational dimension.

Suppose a company gives every employee access to its entire customer database.

Even if all employees are trusted, the access architecture may be difficult to justify.

The better approach is:

Access should be limited according to legitimate business need.

25. Integrity

Integrity concerns the accuracy, completeness and reliability of data and systems against unauthorised or accidental alteration.

Consider a financial institution.

If an attacker changes:

Account balance: €10,000

to:

Account balance: €100

the problem is not confidentiality.

The information was not necessarily disclosed.

The problem is integrity.

Security therefore includes protecting data from unauthorised modification.

Relevant controls include:

• access controls;

• audit logs;

• change management;

• integrity checks;

• digital signatures;

• database controls;

• versioning;

• segregation of duties.

26. Availability

Availability means ensuring that authorised users can access systems and information when needed.

This becomes particularly important in:

• healthcare;

• banking;

• emergency services;

• critical infrastructure;

• cloud services.

Imagine a hospital whose patient records become inaccessible for twelve hours because of ransomware.

Even if the attacker never steals the information, the incident may create severe risks.

This demonstrates why Article 32 is broader than confidentiality.

27. Resilience

Resilience goes beyond availability.

A resilient system can:

1. withstand disruption;

2. continue essential functions;

3. operate in degraded conditions where necessary;

4. recover effectively.

Consider a cloud architecture with several independent availability zones.

If one fails, another can continue serving users.

That is resilience.

A single-server architecture may technically be secure but operationally fragile.

28. Availability versus resilience

The distinction is subtle.

Availability asks:

Can the system be accessed?

Resilience asks:

Can the system continue functioning or recover effectively when subjected to disruption?

A system may normally have excellent availability but poor resilience.

For example:

A company has 99.99% uptime but relies on one data centre.

A major physical disaster destroys that data centre.

Its normal availability statistics may have been excellent, but its resilience architecture may have been inadequate.

29. Restoration after physical or technical incidents

Article 32(1)(c) specifically requires the ability to restore availability and access to personal data following a physical or technical incident.

Examples

include:

Physical

• fire;

• flood;

• earthquake;

• physical destruction of servers;

• theft of storage media.

Technical

• ransomware;

• database corruption;

• hardware failure;

• software failure;

• cyberattack;

• system misconfiguration.

The organisation must have designed its environment so that recovery is actually possible.

30. Backups are not enough

Another major compliance trap is:

"We have backups."

The real question is:

Can those backups actually restore the necessary data within an appropriate timeframe?

Consider ransomware.

The attacker encrypts:

• production servers;

• backup servers;

• network storage.

If backups are connected to the same environment, they may also be compromised.

A meaningful backup strategy may therefore require:

• offline backups;

• immutable backups;

• geographically separated copies;

• access restrictions;

• backup encryption;

• restoration testing.

The existence of a backup is not the same as recoverability.

31. "Timely manner"

Article 32 does not prescribe a universal recovery deadline.

The appropriate recovery period depends on the circumstances.

For example:

A social-media application may tolerate some downtime.

A hospital's critical patient-management system may not.

Therefore, organisations should determine appropriate recovery objectives.

Two useful concepts are:

Recovery Time Objective (RTO) How quickly should the system be restored?

Recovery Point Objective (RPO) How much data loss is acceptable?

These concepts are not themselves GDPR requirements, but they can be useful tools for implementing Article 32.

32. Regular testing, assessment and evaluation

Article 32(1)(d) is especially important because security is not static.

The organisation must test whether its controls actually work.

A security policy saying:

"All employees must use MFA"

is not enough.

The organisation should determine whether:

• MFA is actually enabled;

• exceptions exist;

• employees circumvent it;

• legacy systems remain password-only;

• privileged accounts are protected.

This is the difference between documented security andeffective security.

33. Security testing as a "meta-measure"

Testing does not necessarily protect data directly.

Instead, testing determines whether the existing controls are effective.

Examples

include:

• penetration testing;
• vulnerability assessments;
• phishing simulations;
• backup restoration tests;
• disaster-recovery exercises;
• access-right reviews;
• incident-response exercises;
• configuration reviews;
• security audits. The exact frequency depends on risk.

34. "Regularly" does not mean "once a year"

A common compliance misconception is:

"We conduct an annual security audit, therefore we comply."

Not necessarily.

Frequency should correspond to:

• risk;

• system changes;

• threat developments;

• vulnerabilities;

• technological changes;

• incident history.

A high-risk environment may require substantially more frequent testing.

A low-risk environment may justify less frequent testing.

35. Testing must lead to remediation

Testing without remediation can become security theatre.

Suppose a penetration test discovers a critical vulnerability.

The company produces a report but does nothing.

The fact that a penetration test occurred does not automatically demonstrate Article 32 compliance.

A mature programme should have:

Identify → assess → prioritise → remediate → retest.

Documentation of this cycle can be extremely important when demonstrating accountability.

36. Article 32(2): specific risks

Article 32(2) identifies several risks:

• destruction;

• loss;

• alteration;

• unauthorised disclosure;

• unauthorised access.

These correspond closely to the concept of a personal data breach.

This is significant because the security analysis should not be limited to hacking.

37. Destruction

Destruction means personal data are rendered unavailable or eliminated.

Examples

• accidental deletion;
• database corruption;
• ransomware destruction;
• physical destruction of servers. An organisation should consider both malicious and accidental destruction.

38. Loss

Loss may occur where data become unavailable or are effectively lost without necessarily being deliberately destroyed.

Examples

• lost laptop;
• lost USB drive;
• misplaced paper files;
• corrupted storage;
• lost encryption keys. The distinction between destruction and loss can sometimes be difficult, but the practical obligation is similar:

Protect the availability and recoverability of personal data.

39. Alteration

Alteration concerns unauthorised or accidental modification.

Examples

• manipulated customer records;
• altered medical information;
• corrupted employee records;
• malicious changes to payment information. Integrity controls are therefore essential.

40. Unauthorised disclosure

Disclosure occurs when personal data become accessible to persons who should not receive them.

Examples

• sending a salary spreadsheet to the wrong employee;
• emailing customer information to the wrong recipient;
• publicly exposing a database;
• accidentally publishing personal data online. This illustrates that Article 32 is not solely about cyberattacks. Human error is also a major security risk.

41. Unauthorised access

Access concerns situations in which an unauthorised person obtains access to personal data.

Examples

• stolen credentials;
• compromised administrator account;
• former employee retaining access;
• excessive permissions;
• exposed API;
• insecure cloud configuration.

Strong identity and access management is therefore central to Article 32.

42. Article 32 and data minimisation

An important but sometimes overlooked point is that security can be improved by reducing the quantity of data requiring protection.

Suppose a company stores:

• name;

• address;

• phone number;

• date of birth;

• passport number;

• bank details;

• biometric information;

when only name and email are actually required.

The company has unnecessarily expanded its attack surface.

Data minimisation under Article 5(1)(c) therefore complements Article 32.

Sometimes the best security measure is:

Do not collect or retain the data in the first place.

43. Article 32 and storage limitation

The same reasoning applies to retention.

Every additional month during which personal data remain stored creates additional exposure.

Suppose a company has no legitimate reason to retain former customers' identity documents for ten years.

Even perfect encryption cannot eliminate all risks.

Deleting unnecessary information reduces the potential impact of future incidents.

Thus:

Data minimisation + storage limitation + security controls

can collectively produce substantially better protection than security controls alone.

44. Article 32 and Article 25

Article 25 and Article 32 overlap but should not be conflated.

Article 25

Focuses on:

data protection by design and by default.

Article 32

Focuses on:

security of processing.

Example

when designing a new healthcare application:

Article 25 may require the organisation to design the application so that it collects only necessary information and exposes the minimum amount of data by default.

Article 32 then requires appropriate security measures protecting the processing environment.

The two provisions operate together.

45. Article 32 and Article 24

Article 24 establishes the controller's broader responsibility for GDPR compliance.

Article 32 addresses one specific dimension:

security.

Thus, Article 32 should be incorporated into the organisation's broader accountability framework.

The organisation should be able to demonstrate:

• what risks it identified;

• what controls it selected;

• why those controls were considered appropriate;

• how they are implemented;

• how they are tested;

• what happened when weaknesses were identified.

46. Article 32 and DPIAs

Article 32 is also closely connected to Article 35 and DPIAs.

A DPIA assesses risks to individuals arising from processing.

Security risk assessment examines risks such as:

• unauthorised access;

• loss;

• destruction;

• alteration;

• disclosure.

Where a DPIA is required, the security analysis should not operate in isolation.

Ideally, the organisation should maintain a coherent risk-management framework rather than conducting separate, contradictory assessments for every GDPR provision.

47. Article 32 and processors

One of the most significant aspects of Article 32 is that it directly applies to processors.

This is important because security cannot be delegated away.

Suppose:

Company A = controller Cloud Provider B = processor

Company A cannot simply say:

"Security is the cloud provider's responsibility."

Nor can Company B say:

"The controller owns the data, so security is entirely the controller's responsibility."

Both have direct obligations under Article 32 within their respective roles.

48. Relationship with Article 28

Article 28 reinforces this arrangement.

The processor agreement must address the processor's security obligations.

The processor must implement appropriate Article 32 measures and assist the controller in complying with relevant obligations.

This means security clauses in a Data Processing Agreement should not merely say:

"Processor shall maintain appropriate security."

A robust contractual framework should address matters such as:

• security standards;

• access controls;

• encryption;

• incident management;

• audit rights;

• testing;

• subcontractors;

• vulnerability management;

• business continuity;

• backup;

• deletion;

• personnel security.

49. Controller versus processor security responsibilities

Consider a SaaS provider.

The SaaS provider controls:

• its infrastructure;

• platform security;

• employee access;

• server security;

• application security.

The customer controls:

• its account users;

• permissions;

• uploaded data;

• internal access;

• configurations under its control.

Both parties may therefore have different Article 32 responsibilities.

A breach caused by a customer's failure to revoke a former employee's account may raise different issues from a breach caused by the SaaS provider's vulnerable infrastructure.

Article 32 therefore requires allocation of security responsibilities, not merely contractual labels.

50. Article 32(3): codes of conduct

Article 32 allows adherence to an approved code of conduct to be used as an element demonstrating compliance.

This is an accountability mechanism.

A sector-specific code may help an organisation demonstrate that its security architecture reflects recognised industry practices.

But there is an important limitation:

A code of conduct is evidence of compliance, not a blanket exemption from Article 32.

51. Certification mechanisms

The same applies to approved certification mechanisms.

Certification may provide useful evidence that an organisation has implemented particular security practices.

But certification does not automatically mean:

"GDPR compliance guaranteed."

A certification addresses the scope and criteria of the particular certification.

The organisation remains responsible for its processing.

52. ISO 27001 and Article 32

An information-security management certification such as ISO/IEC 27001 can be highly relevant to an Article 32 compliance programme.

But one must avoid the simplistic argument:

"We are ISO 27001 certified, therefore Article 32 is satisfied."

The GDPR does not create an automatic equivalence.

Certification can be evidence.

It does not replace the organisation's own GDPR-specific risk assessment.

53. Article 32(4): persons acting under authority

Article 32(4) addresses the human element of security.

Controllers and processors must ensure that persons under their authority who have access to personal data do not process that data except:

• on instructions; or

• where required by Union or Member State law.

This reflects the principle that legitimate access does not equal unrestricted processing authority.

54. Employee access does not mean employee freedom

Suppose an HR employee has access to employee records.

That does not mean the employee can:

• download records for personal use;

• share them with friends;

• inspect celebrity employees out of curiosity;

• sell information;

• access records unrelated to their duties.

Access must remain within the authorised purpose and instructions.

55. Who counts as a person under authority?

The provision is broad.

It can encompass:

• employees;

• temporary workers;

• interns;

• contractors;

• consultants;

• certain personnel of service providers.

The crucial question is not the person's job title.

The question is whether the person acts under the authority of the controller or processor and has access to personal data.

56. Article 29 and Article 32(4)

Article 29 contains a closely related rule concerning processing under the authority of the controller or processor.

Article 32(4) reinforces this from the security perspective.

Together they create an important governance requirement:

People with access to personal data must understand the limits of their authority.

This means organisations should have:

• written instructions;

• confidentiality obligations;

• training;

• access controls;

• disciplinary mechanisms;

• monitoring;

• revocation procedures.

57. The insider threat

Article 32(4) is particularly important because employees themselves can create security risks.

Consider:

An employee working in a bank accesses the account records of a famous person out of curiosity.

No hacker was involved.

Nevertheless, the processing may be unauthorised.

Therefore, security programmes must consider insider risk, not merely external attackers.

58. Joiner, mover, leaver controls

A practical way to implement Article 32(4) is through lifecycle access management.

Joiner

When someone joins:

• create appropriate accounts;

• assign least-privilege access;

• provide training.

Mover

When someone changes roles:

• review existing permissions;

• remove unnecessary access;

• assign new permissions.

Leaver

When someone leaves:

• immediately disable accounts;

• revoke credentials;

• recover devices;

• remove remote access;

• review tokens and privileged credentials.

Failure to manage leavers is a common security vulnerability.

59. Least privilege

The principle of least privilege is highly relevant.

A person should receive only the access necessary to perform their authorised role.

Suppose:

Payroll employee → payroll data

does not necessarily justify:

Payroll employee → medical records + marketing database + customer authentication database.

Reducing unnecessary access reduces both the probability and potential impact of misuse.

60. Physical security

Article 32 is not limited to digital security.

Imagine a company maintains excellent cybersecurity but leaves paper files containing medical records in an unlocked reception area.

The processing environment is still insecure.

Physical measures can include:

• locked rooms;

• visitor controls;

• secure disposal;

• access badges;

• CCTV where appropriate;

• clean-desk procedures;

• secure storage;

• restricted server rooms.

61. Cloud computing and Article 32

Cloud environments create complicated responsibility questions.

A controller may use:

• SaaS;

• PaaS;

• IaaS;

• managed databases;

• cloud storage;

• cloud backup.

The organisation must understand what security controls are provided by the cloud provider and which remain its responsibility.

A contract saying:

"The provider is responsible for security"

is not enough.

The organisation must understand the actual allocation of responsibilities.

62. Shared responsibility model

For example:

The cloud provider may secure:

• physical infrastructure;

• underlying hardware;

• certain network components.

The customer may remain responsible for:

• identity management;

• permissions;

• configuration;

• encryption keys;

• application security;

• uploaded data.

An improperly configured cloud storage bucket may therefore create an Article 32 problem for the customer even though the cloud provider's infrastructure itself is secure.

63. Remote work

Article 32 also has major implications for remote work.

Potential risks include:

• personal devices;

• unsecured Wi-Fi;

• family members accessing devices;

• printing confidential records at home;

• screen exposure;

• uncontrolled downloads;

• lost laptops;

• weak authentication.

Relevant measures may include:

• device encryption;

• VPN where appropriate;

• MFA;

• MDM;

• remote wipe;

• secure configuration;

• endpoint protection;

• clear remote-work policies.

64. Bring Your Own Device

BYOD environments require particular attention.

If employees use personal phones or laptops to access company data, the organisation should consider:

• encryption;

• device authentication;

• separation of personal and corporate data;

• remote wipe;

• application controls;

• access restrictions;

• device security requirements.

The fact that the device belongs to the employee does not eliminate the organisation's Article 32 obligations.

65. AI systems and Article 32

Article 32 has increasing importance for AI systems.

Consider an organisation using an external AI service to process:

• employee information;

• customer support conversations;

• legal documents;

• medical information.

Security questions include:

• Is data encrypted?

• Who can access prompts?

• Are inputs retained?

• Who can access logs?

• Are administrator privileges restricted?

• Are models or systems isolated?

• Are outputs exposed to unauthorised users?

• How are API keys secured?

• What happens when the AI provider suffers an incident?

The novelty of AI does not eliminate Article 32.

It makes risk assessment more important.

66. Generative AI and prompt leakage

Suppose employees paste confidential customer information into a generative AI platform.

Even if the company's own network is secure, the employee's processing decision may create:

• unauthorised disclosure;

• uncontrolled external processing;

• retention risks;

• access risks.

Article 32(4), combined with Article 29 and organisational policies, therefore supports clear rules regarding authorised use of AI tools.

67. Security versus convenience

Article 32 can create tension between security and usability.

For example:

Very strict authentication controls can reduce security risks but increase friction.

Very long retention of logs may improve investigation capability but increase the quantity of personal data stored.

Extensive redundancy may improve availability but create additional copies of personal data.

This is why Article 32 cannot be read independently of other GDPR principles.

Security itself must operate within the broader data-protection framework.

68. Security measures can themselves create privacy risks

This is an advanced but important point.

Consider employee monitoring.

An organisation may implement extensive surveillance to detect insider threats.

But excessive monitoring may itself involve extensive processing of employee personal data.

The solution is not:

"Security always overrides privacy."

Instead, the organisation must balance security with:

• necessity;

• proportionality;

• purpose limitation;

• data minimisation;

• transparency.

Article 32 is part of GDPR, not an exemption from GDPR.

69. The problem of employee monitoring

Suppose a company records every keystroke of every employee indefinitely.

The company argues:

"This is necessary for security."

That assertion is not automatically sufficient.

The organisation must establish:

• what threat exists;

• why monitoring is necessary;

• why less intrusive measures are insufficient;

• how long data are retained;

• who can access them;

• whether monitoring is proportionate.

Security measures themselves must be appropriately designed.

70. Security incidents do not automatically equal non-compliance

This point deserves emphasis because it is often misunderstood.

Imagine two companies.

Company A

• no MFA;

• weak passwords;

• unpatched systems;

• no tested backups;

• no access review.

It suffers a breach.

Company B

• MFA;

• encryption;

• segmentation;

• vulnerability management;

• tested backups;

• incident response;

• regular penetration testing.

It suffers a sophisticated zero-day attack.

Both experienced breaches.

But their Article 32 positions may be radically different.

The occurrence of a breach is therefore not conclusive evidence of Article 32 non-compliance.

71. Conversely, no breach does not prove compliance

The reverse is equally important.

A company may have:

• poor passwords;

• unencrypted data;

• excessive permissions;

• no backups;

and yet never have suffered a known breach.

That does not prove compliance.

Article 32 is concerned with whether appropriate measures were implemented in light of foreseeable risks.

72. Documentation is crucial

Although Article 32 does not contain a detailed documentation provision equivalent to Article 30, documentation becomes extremely important through the broader accountability principle.

An organisation should be able to explain:

Why did we choose these controls?

Rather than merely:

What controls do we have?

For example:

Risk: stolen employee credentials.

Assessment: high likelihood, high impact.

Controls: MFA, conditional access, phishing-resistant authentication, monitoring.

Testing: quarterly review and simulated phishing.

Residual risk: moderate.

This is far more persuasive than a generic security policy.

73. Risk register approach

A useful Article 32 compliance structure is a security risk register.

For each processing activity, record:

This demonstrates a reasoned risk-based approach.

74. Residual risk

Security controls rarely eliminate risk completely.

Suppose the initial risk is:

High

After implementing:

• encryption;

• MFA;

• monitoring;

• backups;

• segmentation;

the residual risk might become:

Low or Medium.

The organisation should determine whether that residual risk is acceptable.

The important thing is that the organisation can demonstrate why.

75. Article 32 and proportionality

Article 32 embodies proportionality.

Imagine two systems:

System A

Public newsletter database.

System B

National health database.

Requiring identical security architecture for both would be irrational.

The GDPR therefore permits differentiated controls.

But proportionality works both ways.

The organisation cannot select weak security merely because stronger controls would be inconvenient.

The question is whether the chosen security level is justified by the processing risks.

76. The "checklist trap"

One of the biggest compliance mistakes is treating Article 32 as a checklist:

☑ Encryption ☑ Firewall ☑ Antivirus ☑ Backup ☑ MFA

Therefore:

"Compliant."

This is legally and technically simplistic.

A controller could have every item on that list and still have:

• excessive permissions;

• insecure APIs;

• poor key management;

• vulnerable applications;

• untested backups;

• inadequate incident response.

Article 32 is fundamentally risk-based rather than checklist-based.

77. Security by design

The strongest Article 32 programmes integrate security into the architecture from the beginning.

Example

when developing a new application, security should be considered during:

• requirements;

• architecture;

• coding;

• testing;

• deployment;

• maintenance;

• retirement.

Adding security after deployment can be considerably more expensive and less effective.

This also connects Article 32 with Article 25.

78. Secure software development

For organisations developing software, Article 32 may require consideration of:

• secure coding;

• code review;

• dependency management;

• vulnerability scanning;

• penetration testing;

• secrets management;

• secure APIs;

• authentication;

• authorisation;

• logging;

• patching.

Security therefore extends into the software-development lifecycle.

79. Supply-chain security

An organisation's security may depend heavily on third parties.

Consider:

Controller → Processor → Subprocessor → Cloud provider

A weakness in any layer may affect personal data.

Therefore, vendor due diligence is important.

Organisations should evaluate:

• security certifications;

• incident history;

• security architecture;

• subcontractors;

• vulnerability management;

• breach notification procedures;

• data location;

• access controls.

80. Business continuity and disaster recovery

Article 32's availability and restoration requirements make business continuity particularly relevant.

A mature organisation should ask:

What happens if our primary environment becomes unavailable?

Then:

What happens if our backup environment also fails?

Then:

How quickly can critical services be restored?

These questions transform Article 32 from a theoretical legal requirement into operational resilience planning.

81. Incident response

Security cannot be measured solely by prevention.

An organisation must also be capable of detecting and responding to incidents.

An effective incident-response programme should address:

1. detection;

2. containment;

3. investigation;

4. eradication;

5. recovery;

6. notification;

7. lessons learned.

The connection with Articles 33 and 34 is obvious.

Weak incident response can turn a manageable security event into a serious regulatory problem.

82. Article 32 and Article 33

Article 32 concerns preventing and mitigating security risks.

Article 33 concerns notification of certain personal data breaches to the supervisory authority.

Therefore:

Article 32 = security controls

Article 33 = regulatory response after a qualifying breach

A breach can trigger Article 33 even where the controller did everything reasonably possible to comply with Article 32.

Again, the two questions are related but distinct.

83. Article 32 and Article 34

Article 34 concerns communication of certain breaches to affected individuals.

A serious confidentiality breach involving sensitive information may require communication even if the organisation had extensive security measures.

Therefore:

Security compliance does not eliminate breach-notification obligations.

84. What regulators may examine

In an investigation, a supervisory authority may reasonably be interested in:

• risk assessments;

• security policies;

• access-control policies;

• encryption architecture;

• authentication;

• logs;

• penetration tests;

• vulnerability scans;

• patching records;

• backup arrangements;

• restoration tests;

• employee training;

• incident reports;

• processor contracts;

• security audits;

• remediation records.

This is why Article 32 compliance should be treated as a continuous governance process rather than a one-time certification exercise.

85. The strongest compliance evidence

The strongest evidence usually tells a coherent story:

Risk identified

Risk assessed

Control selected

Reason documented

Control implemented

Control tested

Weakness identified

Remediation undertaken

Control retested

This demonstrates genuine accountability.

86. A practical Article 32 control framework

An organisation can structure its Article 32 programme around the following pillars:

Governance

• security policies;

• roles and responsibilities;

• risk ownership.

Identity and access

• MFA;

• least privilege;

• privileged-access management;

• access reviews.

Data security

• encryption;

• pseudonymisation;

• secure deletion;

• key management.

Infrastructure

• segmentation;

• firewalls;

• secure configurations;

• patch management.

Application security

• secure development;

• vulnerability management;

• penetration testing.

Resilience

• backups;

• redundancy;

• disaster recovery;

• business continuity.

Human security

• training;

• confidentiality;

• insider-threat management.

Monitoring

• logging;

• detection;

• alerting.

Incident response

• response plans;

• escalation;

• investigation;

• notification.

Assurance

• testing;

• audits;

• certification;

• continuous improvement.

87. Difficult question: Can the data subject waive security?

A particularly interesting issue is whether a data subject can consent to weaker security.

Example

suppose a customer says:

"I don't care if my information is encrypted. Just send it to me by ordinary email."

Can the organisation rely on that choice to eliminate its Article 32 obligations?

There are serious reasons to reject a broad waiver theory.

Article 32 imposes a legal obligation on the controller and processor.

The organisation cannot necessarily contract out of mandatory GDPR obligations simply because an individual accepts additional risk.

Consent does not transform an otherwise unlawful processing practice into lawful processing merely because the individual agreed to it.

The safer approach is therefore to treat Article 32 as imposing an objective baseline that cannot casually be waived.

88. Difficult question: Is Article 32 a minimum or maximum standard?

It is a minimum legal obligation, not a ceiling.

If the risks justify stronger security than the examples in Article 32, stronger measures should be implemented.

Example

Article 32 does not expressly say:

"Use phishing-resistant MFA."

But if the risk environment makes such controls appropriate, they may become necessary as part of the overall security architecture.

89. Difficult question: Must every organisation encrypt everything?

No.

Encryption is expressly mentioned, but the wording is:

"as appropriate."

Whether encryption is required depends on:

• sensitivity;

• risk;

• state of the art;

• technical feasibility;

• cost;

• consequences of compromise.

Nevertheless, encryption will often be strongly indicated for high-risk personal data, especially when data are transmitted or stored in environments vulnerable to unauthorised access.

90. Difficult question: Does pseudonymisation eliminate GDPR obligations?

No.

Pseudonymised data remain personal data where the individual can still be identified using additional information.

Therefore:

Pseudonymisation reduces risk.

It does not automatically:

remove GDPR applicability.

91. Difficult question: Does certification guarantee compliance?

No.

Certification can be evidence.

It does not transfer legal responsibility.

A certified organisation can still:

• misconfigure systems;

• ignore vulnerabilities;

• fail to test controls;

• process data outside certification scope;

• suffer inappropriate access controls.

Article 32 remains a contextual, risk-based obligation.

92. Difficult question: What happens if the controller and processor disagree?

Suppose the controller believes that MFA is essential.

The processor says:

"Our existing authentication is sufficient."

The processor cannot simply rely on the controller's position, because it has its own Article 32 obligation.

At the same time, the controller cannot outsource its responsibility.

The contractual relationship should therefore clearly establish:

• security requirements;

• responsibilities;

• standards;

• audit mechanisms;

• escalation procedures.

93. Article 32 as a continuous obligation

Perhaps the most important practical lesson is that Article 32 is not satisfied once.

Security must evolve with:

• new threats;

• new technology;

• new processing;

• organisational changes;

• new vendors;

• new vulnerabilities;

• new attack techniques.

A company that was compliant in 2022 may not necessarily remain compliant in 2026.

94. A complete hypothetical example

Consider a company operating an online healthcare platform.

It processes:

• names;

• addresses;

• health information;

• prescriptions;

• payment information.

Step 1: Risk identification

Potential threats include:

• credential theft;

• ransomware;

• insider misuse;

• database compromise;

• accidental disclosure;

• system outage.

Step 2: Risk assessment

Health information creates potentially severe consequences.

The scale of the platform increases the potential impact.

Therefore, several risks may be high.

Step 3: Security measures

The company implements:

• encryption;

• pseudonymisation;

• MFA;

• least privilege;

• privileged-access management;

• network segmentation;

• secure development;

• vulnerability management;

• logging;

• monitoring;

• tested backups;

• disaster recovery;

• employee training.

Step 4: Testing

The company conducts:

• penetration testing;

• vulnerability scans;

• access reviews;

• phishing simulations;

• backup restoration tests.

Step 5: Incident

Ransomware compromises one server.

Step 6: Response

The organisation isolates the server and restores the environment from immutable backups.

Step 7: GDPR analysis

The organisation assesses whether a personal data breach occurred.

If personal data were compromised, Articles 33 and potentially 34 become relevant.

But the fact that an incident occurred does not automatically establish that Article 32 was violated.

The regulator would need to examine whether the organisation's security measures were appropriate to the risks.

95. Another hypothetical: Article 32 failure without a breach

Consider a company holding passport copies.

It stores them:

• without encryption;

• on an internet-accessible server;

• with one shared administrator password;

• without MFA;

• without vulnerability management.

No known breach has occurred.

Nevertheless, the security architecture may already present a substantial Article 32 problem.

This illustrates why:

Article 32 is preventive.

The regulator does not have to wait until harm occurs before security obligations matter.

96. Another hypothetical: sophisticated attack despite strong controls

Now imagine another company with:

• encryption;

• MFA;

• segmentation;

• EDR;

• secure backups;

• regular penetration testing;

• employee training;

• incident-response procedures.

A novel zero-day attack nevertheless compromises a server.

This does not automatically establish Article 32 non-compliance.

The central issue becomes whether the organisation's measures were appropriate given what could reasonably have been known and implemented at the relevant time.

97. Article 32's central legal test

A useful way of remembering Article 32 is:

1. What was being processed?
2. What could go wrong?
3. How likely was it?
4. How severe would the consequences be?
5. What security measures were reasonably available?
6. Were those measures proportionate to the risk and state of the art?
7. Were they actually implemented?
8. Were they tested?
9. Were weaknesses corrected?

That is essentially the intellectual structure of Article 32.

98. The most important compliance mistakes

The following approaches are particularly dangerous:

"We have a firewall."

Too narrow.

"We use encryption."

Encryption alone is insufficient.

"We are ISO certified."

Certification is evidence, not immunity.

"We have never had a breach."

Historical absence of incidents does not prove compliance.

"Our processor handles security."

The controller retains responsibility and the processor has its own obligations.

"Our employees signed confidentiality agreements."

Organisational commitments must be supported by technical and operational controls.

"We have backups."

Backups must actually work.

"We perform an annual audit."

Frequency must reflect risk.

"Security is an IT issue."

Article 32 is an organisational governance obligation.

99. The relationship between Articles 29 and 32(4)

Article 29 establishes the basic principle that persons acting under the authority of the controller or processor must process personal data only on instructions, subject to legal requirements.

Article 32(4) embeds this principle specifically into the security framework.

This means an organisation's security programme should not stop at technology.

It must control human behaviour.

Training, access governance, supervision and disciplinary mechanisms are therefore genuine components of Article 32 compliance.

100. Final conceptual understanding

Article 32 should ultimately be understood as a risk-based, dynamic, proportionate and accountability-driven security obligation.

It does not prescribe one universal security architecture.

It requires the organisation to determine what security is appropriate in light of:

• the state of the art;

• implementation costs;

• nature of processing;

• scope;

• context;

• purpose;

• likelihood of harm;

• severity of harm.

The four expressly identified categories of measures provide the core operational framework:

1. Reduce the consequences of compromise through measures such as pseudonymisation and encryption.

2. Protect the security properties of the processing environment through confidentiality, integrity, availability and resilience.

3. Recover from incidents through restoration and tested backup/recovery capabilities.

4. Continuously validate security through regular testing, assessment and evaluation.

Article 32(4) adds the human dimension by requiring that people with authorised access do not use that access outside their authority.

The deepest lesson is therefore this:

Article 32 does not ask whether an organisation has security controls. It asks whether the organisation has a security system that is appropriate to the risks created by its particular processing, whether that system actually works, and whether the organisation continuously reassesses and improves it.

That is why Article 32 is much more than a cybersecurity checklist. It is a continuous risk-governance obligation connecting privacy law with information security, organisational governance, vendor management, business continuity, incident response, accountability and individual rights.