Article 40: Codes of conduct

For a CCO or GRC lead, Article 40 is easy to misunderstand because it reads like a “government encouragement” clause rather than an operational requirement. In practice, codes of conduct become real obligations the moment your organization claims alignment, contractually commits to one, or uses a code to satisfy customer diligence. Then you must be able to prove that your processing actually follows the code’s commitments, across teams and systems.

The operational goal is simple: create a repeatable decision and governance process around codes of conduct, and make it evidence-driven. That starts with scope. Your obligations vary depending on whether you act as a controller or processor, what data you process, and which products and systems are in play. If a relevant code exists, adopting it can reduce ambiguity by translating GDPR expectations into sector-specific rules. If no relevant code exists, or adoption is premature, your job is to document that decision and keep it current as your processing changes.

This page gives requirement-level implementation guidance you can assign to owners and audit quickly, anchored in the regulatory text. ¹

Regulatory text

Excerpt (provided): “The Member States, the supervisory authorities, the Board and the Commission shall encourage the drawing up of codes of conduct intended to contribute to the proper application of this Regulation, taking account of the specific features of the various processing sectors and the specific needs of micro, small and medium-sized enterprises.” ¹

What the operator must do with this text

Article 40 establishes that GDPR codes of conduct are meant to translate GDPR into practical, sector-specific rules and that regulators will encourage their creation. Your operational requirement is to manage codes of conduct as a compliance input:

• Identify whether a relevant, approved code of conduct exists for your sector or processing context.
• Decide whether to adopt it (or not) with clear rationale.
• If adopted, implement the code’s commitments as controls, not as marketing language.
• Maintain evidence that your day-to-day processing aligns with what you committed to.

This is a “governance and defensibility” requirement more than a single control. The risk is not that you failed to invent a code, but that you made implicit promises you cannot prove, or you ignored an applicable code that would materially change how you operationalize GDPR duties. ¹

Plain-English interpretation

A code of conduct is a standardized set of GDPR operational expectations for a sector or processing type. Article 40’s practical implication for a compliance program: treat codes of conduct as a structured way to (a) operationalize GDPR consistently, and (b) demonstrate accountability with shared, recognized practices. ¹

If you claim “we follow X code,” regulators, customers, and auditors will expect:

• scoped applicability (which business lines and systems it covers),
• defined owners and procedures,
• control operation evidence,
• exception handling.

Who it applies to

Entities: Any organization processing personal data subject to GDPR, whether acting as a controller or processor, can be in scope for adopting and applying codes of conduct. ¹

Operational contexts where this becomes urgent:

• Third-party due diligence and contracting: Customers and partners ask whether you adhere to recognized privacy codes.
• Processor services: You may need a consistent “privacy posture” across multiple customers’ data.
• Sector-specific processing: Health, adtech, fintech, HR platforms, edtech, and SaaS handling sensitive workflows often face repeatable GDPR interpretation questions.
• Multi-entity groups: Central governance wants one baseline, but local processing differs; codes can standardize where appropriate.

What you actually need to do (step-by-step)

Step 1: Establish ownership and intake

Assign a single accountable owner (usually Privacy/DP Officer function, with Legal and Security as required approvers). Create an intake path so anyone can raise: “Is there a code of conduct we should adopt for this processing?”

Trigger events to route into intake:

• new product or feature that processes personal data,
• new market/region launch,
• major new third party (sub-processor) or data sharing pattern,
• customer contract requiring code adherence,
• material incident or audit finding tied to privacy operations.

Step 2: Build a role-and-scope register (minimum viable)

Create a register entry per relevant processing domain that states:

• controller vs. processor role,
• categories of personal data,
• processing purposes,
• key systems and third parties,
• jurisdictions in which the processing is offered or managed.

This register anchors whether a code of conduct is relevant and prevents teams from applying a code “globally” when it only fits a subset of processing. This control aligns with maintaining a GDPR role-and-scope register for the requirement. ¹

Step 3: Identify candidate codes and perform applicability screening

For each scoped processing domain:

• list candidate codes of conduct that match your sector or processing type,
• document whether the code is approved/recognized in the jurisdictions that matter to you,
• decide if your operations can meet its requirements without creating conflicts with existing policies or contracts.

Output: an “adopt / adopt with conditions / do not adopt” decision record.

Step 4: If you adopt, translate code commitments into a control matrix

Treat code requirements like audit criteria:

• break each commitment into testable controls (policy, procedure, technical config, operational checks),
• map each control to an owner team (Privacy, Engineering, Security, Customer Support, Procurement),
• define frequency/trigger (event-driven vs recurring),
• define evidence output (ticket, report, log extract, contract clause, training record).

Use the same pattern you use for SOC 2 or ISO-style control mapping: a control is only “implemented” if it produces consistent evidence.

Step 5: Create a requirement-specific operating procedure (SOP)

Write an SOP that answers:

• when the code applies and when it does not,
• required approvals for adoption and for exceptions,
• how to handle customer requests that cite the code,
• how to perform periodic self-checks,
• how to remediate gaps (including escalation and risk acceptance).

This aligns to defining a requirement-specific operating procedure with named owners, triggers, and approvals. ¹

Step 6: Stand up evidence packets on a cadence

For each adopted code, maintain an “evidence packet” that can be handed to internal audit, an external auditor, or a customer diligence team. Include:

• the adoption decision record and scope statement,
• the control matrix,
• samples of control operation outputs,
• exception register and remediation tickets,
• management attestation (internal) that the code is followed in scope.

This aligns with retaining auditable evidence packets (decision record, control outputs, exceptions, remediation) on a recurring cadence. ¹

Step 7: Manage exceptions and “partial adoption” honestly

If you cannot comply with a portion of a code:

• document the specific clause/commitment,
• document the gap and compensating controls,
• define a remediation plan or formally record a risk acceptance,
• restrict claims in sales materials and contracts to what you can prove.

A common failure mode is broad external claims with narrow internal implementation.

Required evidence and artifacts to retain

Use this checklist as your audit file structure:

1. Role-and-scope register entry (controller/processor role, data categories, systems, third parties).
2. Code identification log (codes reviewed, dates, sources, approval status, applicability notes).
3. Adoption decision record (approve / reject / conditional; rationale; approvers).
4. Code-to-control mapping matrix (commitment → control → owner → evidence).
5. SOP / runbook for code operation (intake, approvals, exception path).
6. Operating evidence samples (tickets, screenshots, configs, logs, contract templates, training completion).
7. Exceptions register (open/closed exceptions; risk rating; remediation status).
8. Periodic review record (re-validation when processing changes; sign-offs).

Common exam/audit questions and hangups

Expect auditors, customers, or regulators to ask:

• “Which codes of conduct do you claim adherence to, and where is that claim made (contracts, website, RFPs)?”
• “What processing is in scope for the code? Show system boundaries.”
• “Show how each code commitment maps to a control and produces evidence.”
• “How do you ensure third parties (sub-processors) don’t break your commitments?”
• “Show your exception handling and how you prevent ‘temporary exceptions’ from becoming permanent.”

Hangup: teams often produce a policy statement but cannot produce operational evidence tied to specific commitments.

Frequent implementation mistakes and how to avoid them

1. Mistake: Treating code adoption as a legal memo.
   Fix: require a control matrix and evidence outputs as part of approval.

2. Mistake: Over-scoping (“the whole company follows the code”).
   Fix: define scope by product, system, and processing purpose; tie to your role-and-scope register.

3. Mistake: Sales claims outrun operations.
   Fix: add a compliance review gate for marketing language, RFP responses, and contract templates.

4. Mistake: No exception mechanism.
   Fix: create a lightweight exception register with time-bound remediation or risk acceptance.

5. Mistake: No third-party alignment.
   Fix: update due diligence questionnaires and DPAs to reflect code-driven requirements where relevant, and store evidence.

Enforcement context and risk implications

No public enforcement cases were provided in the supplied sources for this requirement, so this page does not cite case outcomes. Operationally, your risk concentrates in two areas that examiners and customers scrutinize:

• Accountability and proof: If you claim adherence, you must show how it operates in reality.
• Consistency across processing and third parties: Codes often standardize expectations; weak governance increases the chance of inconsistent processing practices.

Treat the requirement as a defensibility control: reduce ambiguity, prevent unapproved promises, and maintain traceable evidence. ¹

Practical execution plan (30/60/90)

Numeric timelines require a named source under your rules, so use phased execution instead.

Immediate phase (stabilize and stop accidental claims)

• Inventory external claims (contracts, privacy notices, RFP templates) for code-of-conduct references.
• Stand up an intake and approval workflow owned by Privacy/Compliance.
• Create the first version of the role-and-scope register for the processing areas most exposed to customer diligence.

Near-term phase (implement and evidence)

• Identify candidate codes for your sector and screen applicability by processing domain.
• For any adopted code, publish the code-to-control matrix and the SOP.
• Start collecting evidence packets for one in-scope product or business unit.

Ongoing phase (operate like a control, not a project)

• Add code-of-conduct review to change management (new features, new third parties, new jurisdictions).
• Run periodic control self-checks tied to the code commitments.
• Review exceptions, close remediation items, and refresh adoption decisions when processing changes.

Where Daydream fits (earned mention)

Daydream is useful once you decide to treat Article 40 as an auditable governance workflow: it can track role-and-scope decisions, map code commitments to controls, and package recurring evidence (decision record, control outputs, exceptions, remediation) so audits and customer diligence stop being scramble work.

Frequently Asked Questions

Do we have to adopt a GDPR code of conduct to comply with Article 40?

Article 40 describes encouragement for developing codes of conduct rather than a universal mandate to adopt one. Your operational duty is to manage codes of conduct as a compliance input and avoid unsupported claims of adherence. ¹

What if no relevant code of conduct exists for our industry?

Document the search and the rationale that no applicable code exists for your processing scope. Re-check when your processing changes or when a customer requires alignment to a specific code. ¹

If we adopt a code, what evidence will auditors ask for?

They will look for scope definition, mapping from code commitments to operational controls, and proof those controls run consistently. Keep an evidence packet that includes decisions, control outputs, and exception handling. ¹

Can we adopt a code only for one product line or one region?

Yes, and you usually should scope it to the processing context where it fits. Write scope boundaries in the adoption decision record and align them to your role-and-scope register. ¹

How do third parties affect our code-of-conduct commitments?

If your processing depends on third parties (for example, sub-processors), their controls can determine whether you meet your commitments. Add code-relevant requirements to due diligence and contracts, and keep evidence that third parties meet them.

What should we do if we cannot meet a specific commitment in a code we adopted?

Record a formal exception tied to the specific commitment, define compensating controls, and track remediation or risk acceptance. Restrict any external claims to what you can prove in scope.

Footnotes

1. Regulation (EU) 2016/679, Article 40