Article 40 — Codes of conduct

At a glance

Instrument	Codes of conduct (voluntary, sector specific)
Who drafts	Associations and bodies representing categories of controllers or processors
Approval	Competent supervisory authority; EU wide codes via EDPB and Commission
Value	Demonstrates compliance and accountability; may support transfers under Art. 46(2)(e)

Overview and purpose of Article 40

Article 40 GDPR forms part of Section 5 of Chapter IV, dealing withCodes of Conduct and Certification in the controller and processor framework.

The basic idea behind Article 40 is relatively simple:

The GDPR establishes general rules that apply across many different industries, but the way those rules should operate in practice can differ considerably from one sector to another.

A bank, a hospital, an advertising platform, a university, a cloud-service provider and a small online retailer may all process personal data, but the practical risks and operational methods involved can be completely different.

A Code of Conduct (CoC) therefore acts as a sector-specific operational rulebook. It helps translate broad GDPR requirements into concrete practices that controllers and processors in a particular sector can actually implement.

For example, the GDPR requires processing to be fair and transparent. That is a general legal requirement. A sector-specific code could go further by explaining:

• what information should be given to customers;

• how frequently privacy notices should be updated;

• how consent should be recorded;

• how particular categories of data should be handled;

• how complaints should be processed;

• what security practices are expected;

• how data breaches should be communicated; and

• what constitutes good practice in that particular industry.

Thus, a CoC should not merely repeat the GDPR. Its value lies in giving practical meaning to the GDPR in a particular processing environment.

The EDPB describes Codes of Conduct as a voluntary accountability mechanism capable of providing sector-specific rules and practical guidance for controllers and processors.

This makes Article 40 particularly important from an accountability perspective. It is not simply about creating another document containing privacy rules. The objective is to establish a framework through which an entire sector can develop consistent and demonstrable data-protection practices.

What exactly is a Code of Conduct?

A Code of Conduct can be understood as a sector-specific set of data-protection rules and practices voluntarily adopted by controllers or processors belonging to the relevant category.

In practical terms, imagine that an industry association representing online retailers develops a GDPR Code of Conduct.

Instead of every small retailer independently trying to determine what GDPR compliance means for:

• cookie management,

• customer profiling,

• direct marketing,

• retention periods,

• data-subject requests,

• breach notification,

• processor management, and

• security controls,

the industry association could develop a common framework addressing those issues.

The code therefore provides a practical "rulebook" explaining what compliant processing should look like within that particular sector.

Example

Suppose the GDPR requires organisations to ensure transparency when profiling customers. A general GDPR provision tells the retailerwhat legal principle applies. A sector-specific Code of Conduct could explain how an online retailer should operationalise that principle, for example:

1. disclose that behavioural profiling occurs;

2. explain the categories of information used;

3. explain the purpose of profiling;

4. provide information regarding relevant rights;

5. establish an internal process for handling objections;

6. document the profiling activity; and

7. establish review procedures.

That is the fundamental practical function of a CoC.

A Code of Conduct is a voluntary accountability tool

One of the most important concepts in Article 40 is that Codes of Conduct are generally voluntary.

There are two separate questions here:

Question 1: Is a sector required to create a Code of Conduct?

Generally, no.

Article 40 encourages the development of Codes of Conduct, but the existence of the mechanism does not mean that every industry must create one.

Question 2: Is a controller or processor automatically required to join an existing Code?

Generally, no.

A controller or processor ordinarily chooses whether to undertake to apply an applicable Code.

Therefore:

GDPR obligation ≠ automatic Code of Conduct obligation.

The Code supplements the GDPR; it does not replace the GDPR.

Important distinction

Voluntary does not mean legally meaningless.

Once an organisation voluntarily undertakes to comply with an approved Code, compliance with the Code becomes an important organisational commitment.

It can also provide evidence of accountability and may be considered when assessing the organisation's compliance posture.

Why sector-specific Codes are necessary

The GDPR is intentionally technology-neutral and sector-neutral.

That creates flexibility, but it also creates a practical problem.

A broad legal standard may not always tell an organisation exactly what it should do in a particular operational environment.

For example:

Banking

A bank may deal with:

• financial information;

• transaction data;

• fraud detection;

• credit assessments;

• customer authentication;

• account monitoring.

Healthcare

A healthcare organisation may deal with:

• medical records;

• diagnoses;

• treatment information;

• genetic information;

• patient histories;

• emergency situations.

Online advertising

An advertising business may deal with:

• behavioural data;

• device identifiers;

• online activity;

• profiling;

• audience segmentation;

• targeted advertising.

The legal principles may be the same, but their practical implementation is very different.

A Code of Conduct allows the sector itself to identify these characteristics and develop practical compliance standards.

Special importance for SMEs

Article 40 expressly recognises the needs of micro, small and medium-sized enterprises.

This is important because GDPR compliance can be disproportionately difficult for smaller organisations.

A multinational corporation may have:

• a dedicated privacy team;

• a DPO;

• security engineers;

• external counsel;

• compliance software;

• internal audit functions.

A small business may have only:

• one owner;

• a few employees;

• an outsourced IT provider; and

• limited legal expertise.

A sector-specific Code can therefore reduce the compliance burden by providing a structured framework.

Example

Consider 5,000 small online retailers. Without a sectoral Code, each business may independently attempt to determine:

• how to respond to access requests;
• how to maintain records;

• how to handle cookies;

• how to select processors;

• how to respond to breaches;

• how long certain data should be retained.

A properly designed Code can provide a common baseline.

This does not mean that SMEs receive an exemption from the GDPR.

Rather, the Code can make compliance more accessible, proportionate and operationally achievable.

The four principal actors

The Article 40 framework involves several different actors.

Code Owner

The first actor is the Code Owner.

This is generally an association or other representative body representing categories of controllers or processors.

The Code Owner develops the Code.

Examples could include

• an industry association;
• a trade association;
• a sectoral organisation;
• an organisation representing a category of processors;

• another sufficiently representative body.

The important issue is representativeness.

A random individual company cannot simply create a document and call it an Article 40 Code of Conduct.

The EDPB framework expects the body to demonstrate that it genuinely represents the relevant category and understands the processing activities and needs of that sector.

Supervisory Authority

The relevant supervisory authority reviews the Code.

The supervisory authority examines whether the Code complies with the GDPR and whether it provides sufficient appropriate safeguards.

It therefore plays an important gatekeeping role.

The DPA is not simply registering whatever the industry association submits.

There is an actual substantive assessment.

Controllers and processors

Controllers and processors may voluntarily undertake to comply with the approved Code.

Once they undertake to apply it, they become subject to the Code's requirements and monitoring arrangements.

This is particularly important because Article 40 is not merely a mechanism for writing voluntary guidance.

The framework contemplates monitoring of adherence.

Monitoring Body

The fourth actor is the Monitoring Body under Article 41.

Its function is to monitor whether participating controllers and processors comply with the Code.

This creates a distinction between:

Code Owner → creates the rules

and

Monitoring Body → monitors compliance

and

Supervisory Authority → retains regulatory powers

This separation is fundamental to understanding Article 40.

Article 40(1): Encouragement of Codes of Conduct

The first part of Article 40 is directed towards:

1. Member States;

2. supervisory authorities;

3. the EDPB; and

4. the European Commission.

Their role is to encourage the development of Codes of Conduct.

This does not mean that these bodies themselves necessarily draft every Code.

Rather, they should facilitate the development and functioning of the Code mechanism.

The provision therefore creates a distinction between:

voluntary development by sectors

and

institutional encouragement by regulatory authorities.

"Shall encourage" versus "shall adopt"

This distinction is important.

The provision does not say that every sector must adopt a Code.

Instead, it requires the relevant public and regulatory actors to encourage their development.

Therefore:

Development and adherence remain voluntary, while the encouragement of the mechanism is an institutional obligation.

For example, the EDPB can facilitate the mechanism by issuing guidance explaining:

• how Codes should be drafted;

• how approval works;

• what monitoring arrangements should look like;

• how representative a Code Owner should be;

• how Codes should provide operational meaning to GDPR principles.

The EDPB Guidelines on Codes of Conduct are therefore an important practical resource for understanding how Article 40 operates.

"Specific features" of the processing sector

A Code cannot simply be a generic GDPR summary.

The sector-specific element is fundamental.

The Code should identify the characteristics of the processing environment for which it has been designed.

Example: healthcare

A healthcare Code might need to address:

• confidentiality;
• patient access;
• medical record retention;

• emergency disclosures;

• data sharing between healthcare providers;

• access by healthcare professionals;

• security of medical information.

Example: advertising

An advertising Code may need to address:

• profiling;
• targeted advertising;
• transparency;

• consent mechanisms;

• online identifiers;

• data sharing;

• advertising intermediaries.

The Code should therefore answer:

"What does GDPR compliance look like in this particular industry?"

That is much more useful than simply reproducing Article 5 or Article 6.

Risk-based approach

The development of a Code should also consider the risk likely to result from the processing for the rights and freedoms of individuals.

This means that Code drafting should not be purely formal.

The Code Owner should ask:

• What personal data are being processed?

• Why are they being processed?

• Who is affected?

• What could go wrong?

• How serious could the consequences be?

• What safeguards are appropriate?

• What practical controls are realistically available?

Example

A Code dealing with ordinary customer contact information may require relatively straightforward safeguards. A Code involving highly sensitive profiling of vulnerable individuals would require significantly stronger safeguards. Therefore, the level of protection should correspond to the risk.

Stakeholder consultation

The material also highlights the importance of consultation with relevant stakeholders, including data subjects.

This is a significant point.

A Code should not be drafted solely from the perspective of the industry.

The Code Owner should consider:

• controllers;

• processors;

• industry participants;

• privacy professionals;

• regulators where appropriate;

• civil society;

• data subjects.

Why?

Suppose an industry association develops a Code that makes compliance extremely convenient for companies but gives consumers very little meaningful information.

Such a Code may technically describe industry practice but fail to provide adequate protection for individuals.

Consultation helps identify these problems before approval.

Who can prepare a Code?

Article 40 is primarily concerned with associations and other representative bodies.

The EDPB guidance recognises that potential Code Owners can include:

• trade associations;

• representative associations;

• sectoral organisations;

• academic organisations;

• interest groups.

The critical question is not merely the label attached to the organisation.

The real issue is whether the organisation is sufficiently representative and capable of understanding the sector.

Can an individual company submit a Code?

Generally, the Article 40 mechanism is not intended for a single controller simply creating a private compliance manual.

The Code Owner must represent a category of controllers or processors.

Example

A single bank creating: "XYZ Bank GDPR Code" is different from: "National Banking Association GDPR Code of Conduct"

The second has a fundamentally different representative character.

The purpose of Article 40 is to develop sector-wide or category-wide standards rather than private internal policies.

Representativeness

Representativeness is therefore an important threshold issue.

The EDPB approach considers factors such as:

• the number of organisations potentially applying the Code;

• the proportion of the sector represented;

• the Code Owner's experience in the relevant sector;

• whether it understands the processing activities;

• whether it can identify the needs of its members.

Grey area

There is no simple universal numerical threshold saying: "A Code Owner must represent X% of the industry." The question is therefore contextual. A smaller but highly specialised sectoral organisation could potentially have stronger representative credentials than a very large but generic organisation.

Preparation, amendment and extension

Article 40 is not limited to creating a Code for the first time.

It also covers:

• amendments; and

• extensions.

This is important because privacy practices evolve.

Technology changes.

Business models change.

Regulatory expectations change.

Therefore, a Code may need to be updated.

Example

Suppose a Code originally dealt only with traditional customer databases. Several years later, the sector adopts extensive AI-based profiling. The Code may need to be amended to address:

• profiling;

• automated decision-making;

• model training;

• data minimisation;

• transparency;

• human oversight.

An extension may similarly expand the Code into an additional processing activity or category of participants.

The central function: "specifying" GDPR application

One of the most important conceptual points is that a Code should specify how the GDPR applies.

The Code is therefore not supposed to create an alternative legal regime.

It should translate the existing legal regime into operational rules.

Think of it as:

GDPR principle → sector-specific rule → operational procedure

For example:

1. GDPR principle: transparency
2. Sector-specific rule: customers must be informed in a particular context

Operational procedure: notice must appear at a particular stage, contain specified information and be available through specified channels.

This is where the Code creates value.

A Code should not merely reproduce the GDPR

This is one of the most important examination and practical points.

A Code that merely says:

"Controllers must comply with the GDPR."

provides little additional value.

Likewise, simply copying Articles 5, 6, 12, 13, 15 and 32 into a document does not necessarily create an effective Code of Conduct.

The EDPB approach expects a Code to provide operational meaning.

It should answer questions such as:

• What does fairness mean in this sector?

• What does transparency mean in this particular processing environment?

• What information should actually be provided?

• At what stage?

• Through which mechanism?

• How should a data-subject request be handled?

• What practical safeguards should be implemented?

• What evidence should an organisation retain?

"Operational meaning" of GDPR principles

This is perhaps the most important practical concept in Article 40.

Consider the GDPR principle of data minimisation.

A generic legal statement would be:

Only personal data that are necessary for the purpose should be processed.

A sectoral Code should go further.

For example, it might establish:

• categories of information normally necessary for a particular service;

• categories that should generally not be collected;

• circumstances in which additional information may be justified;

• documentation requirements where additional data are collected;

• review mechanisms for unnecessary data.

The Code has therefore transformed an abstract legal principle into an operational standard.

Topics that a Code may address

The topics listed in Article 40(2) are not merely decorative examples. They demonstrate the breadth of issues a sectoral Code can operationalise.

The list is non-exhaustive.

It can therefore cover other GDPR-relevant issues where appropriate.

Fair and transparent processing

A Code can explain what fair and transparent processing means within the sector.

Example

Suppose an online marketplace uses customer behaviour to determine product recommendations. A Code could establish:

• what information should be disclosed;
• how recommendation systems should be explained;

• how customers should be informed about profiling;

• how objections should be handled;

• how transparency information should be presented.

The objective is to prevent transparency from becoming merely a formal privacy-notice exercise.

Legitimate interests

Codes can also provide sector-specific guidance regarding legitimate interests.

This is particularly useful because legitimate interest assessments often require contextual analysis.

A Code could identify:

• common legitimate interests within a sector;

• relevant balancing considerations;

• typical risks to individuals;

• safeguards that should be implemented;

• circumstances where legitimate interests may be inappropriate.

Important limitation

A Code cannot simply declare:

"Processing X is always lawful because the sector considers it a legitimate interest."

The lawful basis still has to satisfy the GDPR.

The Code can provide a structured framework for applying the law, but it cannot override the legal requirements.

Collection of personal data

A Code can specify practical collection standards.

For example:

• what information should normally be collected;

• when collection should occur;

• what notices should accompany collection;

• how excessive collection should be prevented;

• how collection channels should be designed.

This can be particularly valuable for industries with standardised customer journeys.

Pseudonymisation

A Code may establish sector-specific pseudonymisation practices.

For example, an industry could develop common approaches regarding:

• separation of identifiers;

• access controls;

• key management;

• re-identification risks;

• technical safeguards;

• testing and review.

Important distinction

Pseudonymisation does not automatically mean that the resulting information ceases to be personal data.

This is a critical technical and legal point.

If the information can still be linked back to an individual, it may remain personal data for GDPR purposes.

Therefore, a Code cannot treat pseudonymisation as an automatic exemption from GDPR.

Information provided to the public and data subjects

Codes can standardise how privacy information is communicated.

This could include:

• content;

• timing;

• format;

• accessibility;

• language;

• layered notices;

• sector-specific terminology.

Example

A banking Code might specify that privacy information concerning fraud monitoring should be presented in a manner that ordinary customers can understand. The purpose is not merely to produce a legally exhaustive notice. The objective is meaningful transparency.

Data-subject rights

Codes can provide practical procedures for handling:

• access requests;

• rectification;

• erasure;

• restriction;

• objection;

• portability;

• other applicable rights.

For example, a Code could establish:

1. where requests should be submitted;

2. how identity should be verified;

3. who should handle the request;

4. how records should be maintained;

5. how exceptions should be assessed;

6. how responses should be communicated.

This can create consistency across an industry.

Children and parental consent

Codes may also address:

• information given to children;

• child-friendly communication;

• protection of children;

• consent mechanisms;

• verification of parental responsibility where applicable.

This is particularly relevant for:

• educational technology;

• social media;

• gaming;

• children's services;

• online platforms.

Important nuance

A Code cannot simply replace the legal requirements applicable to children's data.

Instead, it can provide practical mechanisms for complying with them.

Security and Articles 24, 25 and 32

Codes can address organisational accountability and privacy-by-design/security requirements.

This may include:

• access controls;

• encryption practices;

• authentication;

• logging;

• incident management;

• security testing;

• risk assessment;

• privacy by design;

• privacy by default.

Example

A healthcare Code could establish baseline security practices for electronic patient information. This would be much more operational than simply stating: "The controller must implement appropriate technical and organisational measures." The Code could explain what "appropriate" means within the sector.

Personal-data breaches

Codes can provide procedures for:

• detecting breaches;

• assessing risk;

• documenting incidents;

• notifying supervisory authorities;

• communicating with affected individuals;

• escalation;

• internal responsibility.

Example

An industry Code could establish a standard breach-response workflow:Detection → internal escalation → risk assessment → documentation → regulatory notification where required → data-subject communication where required → remediation → review This provides practical operational value.

International transfers

International transfers are another important area.

A Code may address:

• transfer mechanisms;

• safeguards;

• contractual commitments;

• processor obligations;

• recipient obligations;

• data-subject rights;

• supplementary measures where relevant.

Article 40 becomes particularly significant here because approved Codes can, in certain circumstances, be used as an appropriate safeguard under Article 46.

This is discussed further below.

Out-of-court dispute resolution

A Code can also establish mechanisms for resolving disputes between controllers and individuals.

For example:

• complaint procedures;

• internal review;

• mediation;

• industry dispute-resolution mechanisms;

• escalation procedures.

However, this does not eliminate statutory rights.

A Code cannot prevent a data subject from exercising rights available under the GDPR.

This is why the dispute-resolution mechanism operates without prejudice to the data subject's rights.

Article 40(3): Codes and organisations outside the GDPR's territorial scope

This is one of the more technically important parts of Article 40.

Normally, a Code is designed for controllers and processors within the GDPR's scope.

Article 40(3), however, creates a special mechanism for certain controllers and processors outside the territorial scope of the GDPR.

The purpose is particularly relevant to international transfers.

Imagine:

EU organisation → personal data → non-EU processor

The non-EU processor may not independently be subject to the GDPR because of Article 3.

Nevertheless, it may undertake to comply with an approved Code that provides appropriate safeguards.

This can form part of the transfer mechanism contemplated by Article 46.

Why Article 40(3) is significant

This creates an interesting situation.

An organisation may not otherwise be subject to the GDPR territorially, but it can voluntarily undertake to apply specific GDPR-based safeguards.

This can help extend GDPR-level protections contractually or through other legally binding instruments.

Example

Suppose an EU company transfers customer data to a service provider located outside the EEA. The foreign processor:

• is not independently subject to GDPR because of Article 3;
• adheres to an approved Code of Conduct;

• makes legally binding commitments to comply with the Code;

• provides the relevant safeguards.

The Code may therefore contribute to satisfying the transfer framework.

Important conditions for Article 40(3)

This is not simply:

"Any foreign company can sign any GDPR Code."

The requirements are considerably more specific.

The Code must:

1. be approved;

2. have general validity within the Union under the relevant mechanism;

3. be capable of functioning as an appropriate safeguard for the relevant transfer;

4. be adhered to by the non-GDPR-subject organisation;

5. involve binding and enforceable commitments;

6. provide appropriate safeguards, including safeguards concerning data-subject rights.

Therefore, Article 40(3) should be read together with Article 46 rather than in isolation.

Binding and enforceable commitments

This is critical.

A non-EU organisation cannot merely say:

"We support this Code."

It must undertake binding and enforceable commitments through:

• a contract; or

• another legally binding instrument.

The purpose is to ensure that the commitments are legally meaningful.

The data subject must also benefit from the relevant protections.

Thus, the mechanism is not merely a voluntary public relations commitment.

Article 40(4): Mandatory monitoring

This is another central feature of Article 40.

A Code must contain mechanisms allowing compliance to be monitored.

This monitoring is carried out by the Monitoring Body under Article 41.

This creates an important distinction:

Code is voluntary to join

but

compliance with the Code is not supposed to be purely self-declared.

Once an organisation undertakes to apply the Code, there must be an independent and credible monitoring framework.

Why monitoring is necessary

Imagine an industry association publishes an excellent privacy Code.

One hundred companies sign it.

But nobody checks whether those companies actually follow it.

The Code would then risk becoming merely symbolic.

Mandatory monitoring addresses this problem.

The Monitoring Body can assess whether participants actually comply with the Code's requirements.

This gives the Code credibility.

Monitoring does not replace the DPA

A Monitoring Body does not become a substitute for the supervisory authority.

Article 40 expressly preserves the powers of the competent supervisory authorities.

Therefore:

Monitoring Body ≠ Supervisory Authority

The Monitoring Body performs Code-specific monitoring.

The DPA retains its statutory regulatory powers.

Example

A company may comply with a Code but still violate another GDPR requirement. The DPA is not prevented from investigating that organisation. Conversely, the Monitoring Body's role is focused on adherence to the Code.

Relationship between Article 40 and Article 41

Article 40 and Article 41 should be studied together.

Article 40 establishes the Code framework.

Article 41 deals with the monitoring body.

The Code therefore needs to explain:

• who monitors compliance;

• how monitoring occurs;

• what standards are used;

• how violations are detected;

• how complaints are handled;

• what corrective measures are available;

• how serious or repeated violations are addressed.

The monitoring structure must be credible before the Code can obtain approval.

Article 40(5): Approval by the supervisory authority

The Code Owner submits the draft Code, amendment or extension to the competent supervisory authority.

The DPA assesses whether it:

1. complies with the GDPR; and

2. provides sufficient appropriate safeguards.

This is a substantive approval mechanism.

An industry association cannot simply self-certify its own Code as an "approved GDPR Code."

Admissibility versus substantive approval

A useful way to understand the approval process is to distinguish between:

Stage 1, Admissibility

Is the submission sufficiently complete and properly prepared to be assessed?

Stage 2, Substantive approval

Does the Code actually satisfy the GDPR requirements and provide sufficient appropriate safeguards?

This distinction is important because a Code may fail before the DPA even reaches the substantive question.

Admissibility requirements

The EDPB guidance identifies several practical requirements.

The Code should have a clear and concise explanatory statement.

This should explain:

• the purpose of the Code;

• its scope;

• the relevant processing activities;

• the category of organisations covered;

• how the Code promotes GDPR compliance.

This is important because the DPA must be able to understand exactly what the Code is attempting to achieve.

Scope must be precise

A Code should clearly identify:

• the sector;

• the processing activities;

• the controllers/processors covered;

• the geographic scope;

• whether it applies in one or several Member States;

• whether it is intended to have wider validity.

Example of an insufficiently precise scope

"This Code applies to organisations handling customer information." That is too broad. A better approach would identify the relevant category of organisations and the processing activities addressed. The clearer the scope, the easier it is to determine:

• who may join;

• which obligations apply;

• which monitoring mechanisms apply;

• whether the Code is national or transnational.

The Code Owner must demonstrate capability

The Code Owner must demonstrate that it understands:

• the sector;

• its members;

• their processing operations;

• their compliance challenges;

• the interests of data subjects.

This requirement prevents the creation of Codes by organisations without meaningful knowledge of the sector.

Monitoring arrangements must exist before approval

The Code should explain:

• who will monitor;

• what the monitoring process will be;

• how often monitoring will occur;

• how non-compliance is identified;

• how complaints are addressed;

• what sanctions or corrective measures are available;

• how monitoring results are documented.

The monitoring mechanism must be practical, not merely theoretical.

Consultation before submission

Stakeholder consultation is another important component.

The Code Owner should consult relevant stakeholders, including data subjects.

The purpose is to identify:

• practical problems;

• consumer concerns;

• implementation difficulties;

• unintended consequences;

• sector-specific risks.

The Code Owner should consider the submissions and views received.

This means consultation should be meaningful rather than merely procedural.

National legislation must also be considered

A Code cannot simply ignore applicable national law.

This is particularly important in sectors heavily regulated by Member State legislation.

Example

Suppose a sector is subject to national rules concerning:

• healthcare;
• employment;
• financial services;

• telecommunications;

• education.

A Code must operate consistently with those rules.

The Code is intended to specify GDPR application; it is not a mechanism for overriding national legal requirements.

Language requirements

The Code should be provided in the language relevant to the competent supervisory authority.

For transnational Codes, an English version is also relevant under the EDPB approval framework.

This may appear administrative, but it is important for cross-border regulatory review.

Conditions for substantive approval

The EDPB guidance identifies several cumulative considerations.

The Code should address a specific data-protection need or issue common to the sector or processing activity.

It should also demonstrate that the Code provides an effective and beneficial solution.

This means the Code needs a genuine regulatory or operational purpose.

"Specific need" requirement

A Code should not exist merely because an industry association wants a GDPR document.

There should be an identifiable reason for it.

For example:

• a sector has unusual data-sharing arrangements;

• a sector processes a particular type of personal data;

• SMEs struggle with a common compliance issue;

• a specific technology creates recurring privacy risks;

• data-subject complaints are common;

• the sector requires standardised operational practices.

The Code should explain the problem and demonstrate how it addresses it.

Effective application of the GDPR

The Code must facilitate the effective application of the GDPR.

This requires practical standards.

The Code should ideally tell participants:

• what they need to do;

• when they need to do it;

• how they should do it;

• what documentation should exist;

• who should be responsible;

• how compliance can be demonstrated.

That is the difference between legal abstraction and operational compliance.

Realistic and attainable standards

A Code should not establish requirements that are impossible for its intended participants to satisfy.

This is particularly important for SMEs.

For example, a Code requiring every small business to maintain a massive privacy department would be unrealistic.

Instead, the Code should establish proportionate measures.

This does not mean lowering the GDPR standard.

It means providing practical mechanisms for achieving the required standard.

Sector-specific terminology

A Code should use language that the sector understands.

For example, a healthcare Code should use terminology familiar to healthcare organisations.

An advertising Code should address the actual terminology used by advertising businesses.

The EDPB approach encourages practical drafting rather than overly legalistic repetition.

The Code should be understandable to the organisations that are expected to implement it.

Good-practice examples

Examples are particularly valuable.

Suppose a Code states: "Transparency must be effective." That is legally meaningful but operationally incomplete. A better Code could give examples of:

• acceptable notice structures;

• unacceptable practices;

• recommended consent flows;

• appropriate access-control models;

• acceptable complaint-handling procedures.

Examples

turn abstract requirements into operational guidance.

Sufficient appropriate safeguards

The Code must provide safeguards appropriate to the risks involved.

This is a central approval criterion.

The safeguards should correspond to:

• the nature of processing;

• volume of data;

• sensitivity;

• number of affected individuals;

• potential consequences;

• technological environment;

• likelihood of harm.

Example

A Code for processing children's sensitive data would require stronger safeguards than one dealing with relatively low-risk business contact information.

Article 40 does not create a safe harbour

This is an important practical nuance.

Adherence to an approved Code does not mean:

"The organisation can never be found to violate the GDPR."

The Code does not immunise an organisation from regulatory enforcement.

The GDPR remains the controlling legal framework.

A Code is evidence of accountability and a practical compliance mechanism, not a blanket exemption.

Can a court disagree with a Code?

Yes, according to the commentary supplied.

An approved Code does not make the Code's interpretation legally binding on courts or supervisory authorities in every circumstance.

A practice accepted within a Code could potentially later be considered unlawful.

Therefore:

Approved Code ≠ authoritative interpretation of the GDPR

This is a crucial distinction.

Evidentiary value of adherence

Although adherence is not a safe harbour, it can still be valuable.

Adherence may demonstrate that an organisation has:

• identified sector-specific risks;

• implemented recognised controls;

• subjected itself to monitoring;

• attempted to follow recognised standards;

• established accountability mechanisms.

This may be relevant when a supervisory authority evaluates the organisation's compliance.

It can therefore function as an important accountability signal.

Article 24 and Codes of Conduct

Article 24 is particularly relevant because adherence to approved Codes may be considered as an element demonstrating compliance.

This means that Code adherence can form part of the organisation's overall accountability evidence.

But it should be understood as one element, not the entire compliance programme.

An organisation cannot say:

"We follow the Code, therefore we do not need to conduct our own compliance assessment."

The organisation remains responsible for its processing.

Impact on DPIAs and risk assessment

Adherence may also be relevant when assessing security or data-protection risks.

For example, if an organisation follows a recognised sector Code that establishes particular safeguards, that may provide evidence regarding the controls implemented.

However, the organisation still needs to conduct the analysis required for its specific processing.

A Code cannot eliminate the need for a DPIA where the GDPR requires one.

Impact on administrative fines

The supplied commentary notes that adherence may be relevant when a supervisory authority considers enforcement measures.

This does not mean that following a Code automatically reduces a fine.

Rather, the organisation's adherence and actual compliance behaviour may be relevant to assessing the circumstances of the infringement.

The key distinction is:

Code adherence can be evidence of accountability; it is not immunity from enforcement.

Article 40(6): Publication of national Codes

Where an approved Code does not relate to processing activities in several Member States, the competent supervisory authority registers and publishes it.

Publication serves several functions.

It allows:

• organisations to identify approved Codes;

• data subjects to understand applicable standards;

• regulators to maintain transparency;

• the industry to access the relevant framework.

Importantly, publication itself is not what creates the Code's validity according to the supplied commentary.

Approval is the critical substantive event.

National versus transnational Codes

One of the major structural distinctions under Article 40 is:

National Code

A Code relating to processing activities within one Member State.

The competent DPA can approve and publish it under the relevant national process.

Transnational Code

A Code relating to processing activities in several Member States.

The approval process involves the EDPB consistency mechanism.

This prevents different Member States from approving conflicting interpretations for the same cross-border sector.

Article 40(7): Transnational Codes

When a Code relates to processing activities in several Member States, the competent DPA must submit it to the EDPB through the Article 63 consistency mechanism before approval.

The purpose is harmonisation.

Suppose an industry operates across:

• Germany;

• France;

• Spain;

• Italy;

• Netherlands.

If each national DPA independently approved a different version of the same sectoral Code, the Code could become fragmented.

The EDPB consistency mechanism helps avoid this.

Role of the EDPB

The EDPB assesses whether the transnational Code:

• complies with the GDPR; or

• in the Article 40(3) context, provides appropriate safeguards.

The EDPB therefore acts as an important coordination mechanism for cross-border Codes.

Cooperation between DPAs

The competent DPA does not operate in isolation.

Other supervisory authorities may need to determine whether they are concerned by the Code.

This is particularly important where:

• processing occurs in several Member States;

• data subjects in multiple countries are affected;

• organisations covered by the Code operate across borders.

The process is therefore cooperative rather than purely national.

Article 40(8): EDPB to Commission

If the EDPB gives a positive opinion concerning a transnational Code, the EDPB submits its opinion to the European Commission.

This creates another institutional layer.

The process can therefore be represented as:

1. Code Owner
2. Competent DPA
3. EDPB consistency mechanism
4. EDPB opinion
5. European Commission

This is substantially more rigorous than approval of a purely national Code.

Article 40(9): General validity

The European Commission may then decide, by implementing act, to give the approved transnational Code general validity within the Union.

This is a significant status.

A Code with general validity is no longer merely a national sectoral instrument.

It can operate across the Union within the scope defined by the Code.

"General validity" does not mean "mandatory for everyone"

This is a common conceptual trap.

General validity does not mean:

Every controller in the EU must comply with the Code.

It means that the Code has Union-wide validity as an approved Code.

Participation can still remain voluntary, subject to the specific legal framework and commitments involved.

Thus:

General validity ≠ universal mandatory application.

General validity and international transfers

General validity becomes particularly important in the Article 40(3) context.

A Code with general validity can potentially be used as an appropriate safeguard for transfers to third-country controllers or processors that are not otherwise subject to the GDPR.

This is one of the most technically significant interactions between:

• Article 40;

• Article 41;

• Article 46; and

• Article 3.

Article 40(10): Publicity by the Commission

Where the Commission gives a Code general validity, it must ensure appropriate publicity.

The purpose is transparency and accessibility.

Stakeholders should be able to identify the approved Code and understand its status.

This operates alongside the EDPB's register.

Article 40(11): EDPB register

The EDPB is required to maintain a register of approved Codes, including:

• Codes;

• amendments; and

• extensions.

This register is intended to be publicly available.

The register is therefore an important practical resource for:

• organisations seeking to identify applicable Codes;

• privacy professionals;

• regulators;

• data subjects;

• researchers;

• compliance teams.

Ambiguity concerning "approved Codes"

The supplied commentary identifies an interesting drafting issue.

Article 40(11) refers to "all approved codes" but does not expressly repeat the phrase "general validity".

This creates some ambiguity concerning the exact scope of the register.

The practical interpretation described in the commentary is that the EDPB register should encompass both:

• national approved Codes; and

• transnational Codes that receive general validity.

This is a useful example of how the structure of Article 40 must sometimes be understood as a whole rather than by reading a single paragraph literally.

The lifecycle of a Code of Conduct

The entire Article 40 process can be understood as a lifecycle.

Step 1, Identify sectoral need

The industry identifies a common privacy problem.

Step 2, Consultation

Relevant stakeholders, including data subjects, are consulted.

Step 3, Drafting

The Code Owner develops the Code.

Step 4, Monitoring framework

A monitoring mechanism and Monitoring Body are identified.

Step 5, Submission

The Code is submitted to the competent DPA.

Step 6, DPA assessment

The DPA considers admissibility and substantive compliance.

Step 7, Approval

The DPA approves an appropriate Code.

Step 8, National/transnational determination

If the Code is national, the relevant publication mechanism applies.

If it is transnational, the EDPB consistency mechanism applies.

Step 9, EDPB opinion

The EDPB assesses the transnational Code.

Step 10, Commission

For a transnational Code, the Commission may grant general validity.

Step 11, Adherence

Controllers and processors voluntarily undertake to apply the Code.

Step 12, Monitoring

The Monitoring Body monitors compliance.

Step 13, Register

The approved Code is made publicly available through the relevant register.

Operational significance for a controller

For a controller, adherence to a Code can provide a practical compliance framework.

Instead of creating every operational standard from scratch, the controller can use the Code as a structured baseline.

For example, its privacy programme can be mapped against:

Code requirement	Internal control	Evidence
Transparency	Privacy notice process	Approved notices
Data-subject rights	Rights-management procedure	Request logs
Security	Security controls	Security records
Breach management	Incident-response process	Incident register
Retention	Retention schedule	Deletion logs
Monitoring	Internal compliance reviews	Audit reports

This is where Article 40 becomes practically useful for privacy governance.

Operational significance for a processor

A processor can use a Code to standardise:

• security practices;

• subcontractor management;

• breach escalation;

• data handling;

• deletion/return processes;

• technical controls;

• documentation.

This can also make negotiations with controllers easier where the Code establishes recognised sectoral expectations.

Operational significance for procurement

Codes can be relevant during vendor due diligence.

For example, an organisation selecting a processor may ask:

• Is the processor a participant in an approved Code?

• What commitments has it made?

• Who monitors compliance?

• What does the Code require?

• Does the processor's actual implementation match the Code?

Again, adherence is not conclusive proof of compliance, but it can be an important due-diligence factor.

Operational significance for audits

A Code can also provide an audit benchmark.

Instead of asking only:

"Does the company have a GDPR policy?"

an auditor can ask:

"Has the organisation implemented the sector-specific controls required by the applicable Code?"

This makes compliance assessment more concrete.

Monitoring versus internal audit

These should not be confused.

An organisation may conduct its own internal privacy audit.

The Monitoring Body independently monitors compliance with the Code.

The supervisory authority separately retains its statutory powers.

Thus, three different levels can exist:

1. Internal compliance
2. Code monitoring
3. Regulatory supervision

Each performs a different function.

What happens if an organisation violates the Code?

The consequences depend on the Code and its monitoring framework.

The organisation may face:

• corrective measures under the Code;

• suspension or removal from the Code;

• reputational consequences;

• potential contractual consequences;

• regulatory scrutiny.

Importantly, Code non-compliance may also attract attention from the supervisory authority, particularly where the underlying conduct also constitutes GDPR non-compliance.

What if the organisation follows the Code but violates GDPR?

The GDPR remains superior.

Therefore:

Following the Code does not legalise unlawful processing.

If a particular processing operation violates the GDPR, the fact that the organisation followed an approved Code does not automatically make the processing lawful.

This is one of the most important limitations of Article 40.

What if the Code itself appears inconsistent with the GDPR?

An approved Code is not a source of immunity.

If a provision is later found to be inconsistent with the GDPR, the GDPR prevails.

The Code may then need:

• amendment;

• extension;

• regulatory review; or

• other corrective action.

This is another reason why Codes should be treated as dynamic compliance instruments, not permanent substitutes for legal analysis.

Narrow versus broad Codes

Article 40 gives Code Owners significant discretion regarding scope.

A Code could be:

Narrow

For example:

Data-breach management in the healthcare sector.

Or:

Broad

For example:

GDPR compliance framework for healthcare providers.

Both models can potentially be useful.

The critical requirement is that the scope must be clearly defined and the Code must genuinely address the relevant sector-specific needs.

Code versus internal privacy policy

A Code of Conduct is different from an internal privacy policy.

Internal privacy policy

Usually applies to one organisation.

Code of Conduct

Applies to a category or sector and is developed through a representative mechanism.

Internal policy

Created by the organisation.

Code

Created by the Code Owner and subject to the Article 40 approval/monitoring framework.

This distinction is particularly important for examinations.

Code versus certification

Codes of Conduct and certification are related but distinct accountability tools.

A Code establishes sector-specific requirements and monitoring.

Certification generally involves demonstrating compliance against specified certification criteria.

Therefore, they should not be treated as interchangeable concepts.

Code versus legislation

A Code is also different from legislation.

Legislation creates legally binding statutory obligations.

A Code generally provides a voluntary accountability framework that operationalises GDPR requirements.

The Code cannot override:

• the GDPR;

• applicable EU law;

• applicable national law.

This hierarchical relationship should always be kept in mind.

Major grey area: voluntary does not mean optional once adopted

This distinction is subtle but important.

At the initial level:

An organisation may generally choose whether to adhere to the Code.

But after undertaking to apply it:

The organisation has voluntarily assumed commitments that it must honour.

Thus, "voluntary" describes the decision to join, not necessarily the ability to ignore the Code after joining.

Major grey area: adherence is evidence, not immunity

Another key distinction:

Adherence can demonstrate accountability.

But:

Adherence cannot guarantee legality of every processing operation.

This distinction should be remembered for practical compliance, regulatory investigations and examinations.

Major grey area: Code does not replace GDPR interpretation

A Code can explain how a GDPR provision operates in a particular sector.

But it cannot create an alternative interpretation that contradicts the GDPR.

For example, a Code cannot validly state:

"Data subjects in this sector have no right to object."

if the GDPR otherwise provides such a right.

The Code must remain within the legal framework.

Major grey area: Code versus national law

A sectoral Code may have to coexist with national rules.

Therefore, the Code Owner should identify applicable national legislation and ensure that the Code does not conflict with it.

This is especially important in highly regulated sectors.

Major grey area: sectoral specificity

A Code must be sufficiently specific to provide operational value.

But it should not become so narrow that it becomes irrelevant to most of the intended sector.

The Code Owner therefore has to strike a balance between:

specificity

and

flexibility/scalability.

Major grey area: technological change

A Code can become outdated.

For example, a Code drafted before widespread use of generative AI may not adequately address:

• AI-based profiling;

• automated decision-making;

• model training;

• synthetic data;

• large-scale data analytics;

• new forms of tracking.

This makes the amendment and extension mechanism particularly important.

Article 40 is therefore not a "draft once and forget" mechanism.

Major grey area: SMEs and proportionality

A Code designed for a sector containing thousands of SMEs must avoid assuming that every organisation has the same resources.

The framework should allow practical compliance while preserving the GDPR standard.

This is one reason Article 40 expressly refers to the specific needs of micro, small and medium-sized enterprises.

Major grey area: monitoring credibility

The credibility of a Code depends significantly on its monitoring mechanism.

If the Monitoring Body:

• lacks independence;

• lacks resources;

• rarely investigates;

• cannot impose meaningful corrective measures;

• does not have appropriate expertise,

the Code may become largely symbolic.

Therefore, Article 40(4) and Article 41 are critical to the practical effectiveness of the entire mechanism.

Practical example

online advertising Code Consider a hypothetical advertising-industry Code. It might establish:Transparency Advertisers must clearly disclose relevant profiling practices. Data collection Only information necessary for the relevant advertising purpose should be collected. Consent Where consent is required, the consent mechanism must satisfy the GDPR. Profiling The Code could establish sector-specific transparency and governance requirements. Data-subject rights Participants must maintain a standardised mechanism for receiving and processing rights requests. Security Minimum security measures may be specified. Breaches Participants may be required to maintain an industry-standard incident-response procedure. Monitoring The Monitoring Body conducts periodic compliance assessments. This demonstrates how Article 40 converts broad GDPR principles into industry-specific operational practices.

Practical example

healthcare Code A healthcare Code could address:

• access to medical information;
• patient authentication;
• internal access controls;
• data sharing;
• emergency access;
• retention;
• breach management;
• patient rights;
• pseudonymisation for research;
• security controls. Again, the GDPR provides the legal foundation, while the Code provides sector-specific operationalisation. Understood. I’ll continue with Article 41 GDPR in that format, commentary only, without reproducing the statutory text, and without a checklist or exam-summary section. The analysis below follows the material you provided, particularly the EDPB-based discussion of monitoring bodies and accreditation.