Article 43: Certification bodies

Article 43 governs who can issue or renew GDPR certifications and what conditions must exist for those certification bodies to operate: they must have proven data protection expertise, inform the competent supervisory authority so it can exercise oversight powers, and be accredited under the Member State’s accreditation approach. Your job is to avoid treating certification as self-attestation and to run certification work only through properly accredited bodies.

Key takeaways:

• Certification is administered by accredited certification bodies, not by controllers/processors themselves.
• Certification bodies must inform the supervisory authority to enable oversight actions tied to certification.
• If your organization buys or relies on GDPR certification, you must validate the body’s accreditation and scope, then retain proof.

Article 43 rarely shows up as a “do this control” obligation for most controllers and processors. Instead, it’s the plumbing behind GDPR’s certification scheme: it defines expectations for certification bodies and the supervisory authority’s oversight relationship. Practically, it still matters to you as a CCO or GRC lead because GDPR certification is often used in third-party diligence, procurement, sales security reviews, and processor selection. If you accept a “GDPR certified” claim at face value, you can create audit exposure and commercial risk: you may be relying on a credential that was not issued by an appropriately accredited body or does not cover the processing system or service you think it covers.

Operationalizing Article 43 is therefore about governance and evidence: (1) knowing when your business is relying on a certification (your own or a third party’s), (2) confirming the certification body is legitimate under the relevant Member State scheme, (3) confirming the certificate scope matches the processing reality, and (4) keeping an evidence packet that stands up in customer diligence and regulator inquiries. The underlying requirement is set by GDPR itself. (Regulation (EU) 2016/679, Article 43)

Regulatory text

GDPR Article 43(1) excerpt (provided): Certification bodies with appropriate data protection expertise shall, after informing the supervisory authority so it can exercise its powers (referencing Article 58(2)(h)), issue and renew certification; Member States must ensure those certification bodies are accredited by one or both of the listed accreditation paths. (Regulation (EU) 2016/679, Article 43)

Operator interpretation (what this means for execution):

• Certification is not informal. A “GDPR certification” must be issued/renewed by a certification body operating under the Member State’s accreditation approach described in Article 43. (Regulation (EU) 2016/679, Article 43)
• The supervisory authority has an oversight role. The certification body must inform the supervisory authority to allow the authority to exercise certain powers in connection with certification. (Regulation (EU) 2016/679, Article 43)
• Member States set the accreditation implementation. Your implementation task is not to invent accreditation criteria, but to verify that the certification body you engage is accredited under the relevant scheme for where the certification is issued and relied upon. (Regulation (EU) 2016/679, Article 43)

Plain-English requirement (what you must ensure)

If your organization:

1. seeks a GDPR certification,
2. markets a GDPR certification, or
3. relies on a third party’s GDPR certification for diligence, onboarding, or risk acceptance,

then you must treat certification as a regulated third-party assurance artifact. Confirm the certification body is accredited as required and keep evidence of (a) who certified, (b) under what authority/accreditation, (c) what exactly was certified, and (d) whether it is current.

Who it applies to

Direct applicability (primary)

• Certification bodies that issue and renew GDPR certifications. They must have appropriate expertise, inform the supervisory authority, and be accredited according to the Member State approach. (Regulation (EU) 2016/679, Article 43)

Operational applicability (most CCOs/GRC leads)

• Controllers and processors that pursue certification or rely on certification claims in contracts, procurement decisions, DPIA risk treatment, or customer assurance responses. Your risk is misrepresentation, weak diligence, and incorrect reliance on a credential that does not mean what stakeholders assume it means. (Regulation (EU) 2016/679)

Typical operational contexts

• Third-party onboarding where a supplier claims “GDPR certified.”
• Sales/commercial security reviews where your company presents certification as assurance.
• Processor selection where certification is used to justify lower monitoring intensity.
• Internal control mapping where certification is treated as a substitute for control evidence.

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

Step 1: Establish your “certification reliance” scope

Create a short register entry that answers:

• Are we a controller, processor, or both for the service/system in scope?
• Which products, regions, and processing activities are represented as certified (or reliant on a certified third party)?
• Where is certification referenced: procurement checklist, security questionnaire responses, DPAs, marketing, RFP templates?

Why it matters: Article 43 is easy to misapply if you don’t know where the business is using certification as an assurance mechanism. (Regulation (EU) 2016/679, Article 43)

Step 2: Build an intake gate for any “GDPR certified” claim

Add a mandatory review step for:

• new third-party onboarding,
• contract renewals,
• customer assurance responses, and
• public claims (website, datasheets).

Minimum acceptance criteria for the gate:

• A copy of the certificate (or equivalent evidence package).
• The certification body identity and proof of accreditation under the relevant scheme.
• Certificate scope statement that maps to your actual processing environment (system/service, entities, locations).

Tip for operators: Put this gate under GRC ownership, but require Legal/Privacy sign-off when certification language appears in customer-facing terms.

Step 3: Verify the certification body and accreditation (don’t rely on logos)

Your verification checklist should include:

• Certification body legal name (not a brand name).
• Accreditation reference details that show the body is accredited as required under Article 43’s Member State approach. (Regulation (EU) 2016/679, Article 43)
• Evidence the body informed/engages the supervisory authority as required for oversight (you may not always receive direct proof; document your due diligence steps and what the certification body provided). (Regulation (EU) 2016/679, Article 43)

Practical approach: Treat the certification body as a high-impact third party in your assurance chain. If your procurement team can’t verify accreditation, treat the claim as “unverified” and do not use it to reduce diligence depth.

Step 4: Validate scope alignment (most common failure point)

Certification often fails in practice because stakeholders assume it covers “the company,” while the certificate covers a narrow service or specific processing context.

Scope validation questions to force precision:

• What system, product, or processing activity is explicitly covered?
• Are subprocessors, cloud regions, and support functions included or excluded?
• Does the certificate cover controller processing, processor processing, or both?
• Does your contract or customer promise align with the certificate language?

Record the mapping between certificate scope and your RoPA/system inventory references so you can show traceability.

Step 5: Operationalize renewal and change management

Set triggers that require re-validation:

• certificate renewal/expiry,
• material change to processing (new data categories, new regions, new subprocessors),
• change of certification body,
• change in supervisory authority relationship or accreditation status (if notified).

Output: a standing task in your compliance calendar and a “certification reliance review” in your third-party lifecycle workflow.

Step 6: Evidence retention and packaging for audits and customer diligence

Create a repeatable “evidence packet” per certificate (your own or a third party’s):

• Certificate copy and version history
• Certification body identification and accreditation proof
• Scope statement and your internal scope mapping notes
• Risk acceptance decision if scope is partial or if verification gaps exist
• Renewal tracking and re-validation records
• Communications: emails, attestations, or portal screenshots used to validate authenticity

Daydream fit (earned, not forced): If you already run third-party due diligence in Daydream, track “certification reliance” as a structured artifact type and tie it to the third-party record, the in-scope system, and the contract. That prevents the common failure where a certificate lives in email while Procurement and Legal rely on it in multiple places.

Required evidence and artifacts to retain (audit-ready list)

Use this as your minimum retention standard:

1. Role-and-scope register entry for where certification is used (controller/processor role, systems, data categories).
2. Certification artifact (certificate document and any annexes).
3. Certification body accreditation proof captured at the time of reliance. (Regulation (EU) 2016/679, Article 43)
4. Scope mapping memo: what you think it covers, what it does not cover, and what decisions were made based on it.
5. Approval record showing who authorized reliance (GRC, Privacy, Legal, Procurement).
6. Exception record if you proceeded despite incomplete verification, including compensating controls.
7. Renewal/expiry tracker and re-validation evidence.

Common exam/audit questions and hangups

Expect these questions from internal audit, external assessors, or customers:

• “Show me where you validated the certification body’s accreditation.” (Regulation (EU) 2016/679, Article 43)
• “What exactly is certified, and how does that map to your processing activities?”
• “Where do you represent this certification to customers, and is the claim precise?”
• “What is your process when a certificate expires or the service changes?”
• “Did you reduce monitoring based on certification? Show the decision record.”

Hangup to anticipate: teams often cannot produce a single record tying the certificate to a specific product/system and contract. Fix it with a structured evidence packet and system linkage.

Frequent implementation mistakes (and how to avoid them)

1. Treating “GDPR certified” as a marketing statement.
   Fix: require the intake gate and retain accreditation proof. (Regulation (EU) 2016/679, Article 43)

2. Not defining who owns certification claims.
   Fix: assign an owner for (a) external claims, (b) procurement reliance, and (c) renewal tracking. Put it in a procedure, not a slide.

3. Scope drift after certification.
   Fix: add change triggers tied to subprocessors, regions, and new processing purposes; require re-validation evidence.

4. Assuming certification replaces due diligence.
   Fix: treat certification as one input. Keep baseline security and privacy controls and validate what the certificate actually covers.

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for this requirement, so you should not assume a predictable enforcement pattern from Article 43 alone. Your practical risk is still real: if you misstate certification status or rely on an invalid certification body, you can end up with (a) misleading customer assurances, (b) procurement control failures, and (c) a weak position if a supervisory authority asks how you assessed assurance mechanisms tied to GDPR compliance. (Regulation (EU) 2016/679)

Practical 30/60/90-day execution plan

Use phases (not date promises) to move fast without creating rework.

First 30 days (stabilize and stop bad reliance)

• Inventory all places “GDPR certified” appears: contracts, RFP templates, website, sales decks, supplier profiles.
• Stand up a one-page procedure: intake gate, required evidence packet, approval roles.
• Create a certification register with owner, scope, and renewal status.

Days 31–60 (verify and correct)

• For each certificate in use, collect: certificate, certification body identity, and accreditation proof. (Regulation (EU) 2016/679, Article 43)
• Perform scope mapping for high-impact services and critical third parties.
• Clean up external statements that over-claim scope or imply company-wide coverage without proof.

Days 61–90 (embed into operations)

• Add certification checks into third-party onboarding and renewal workflows.
• Add change triggers into your RoPA/system change management process.
• Implement recurring evidence refresh and exception reporting to the risk committee or privacy steering group.
• If you use Daydream, connect certification artifacts to third-party records, contracts, and in-scope systems so audits don’t become a document hunt.

Frequently Asked Questions

Do controllers and processors have direct obligations under Article 43?

Article 43 is written primarily for certification bodies and Member State accreditation arrangements. Controllers and processors still need operational controls if they pursue or rely on certification, because they must avoid inaccurate reliance or claims tied to GDPR compliance. (Regulation (EU) 2016/679, Article 43)

Can we claim we are “GDPR certified” if a single product is certified?

You can only claim what the certificate scope supports. Keep claims scoped to the certified service/system and retain a mapping memo that shows what is covered and what is excluded.

What evidence should Procurement require when a third party says they are GDPR certified?

Require the certificate plus proof that the certification body is accredited under the relevant Member State approach. Keep the scope statement and your internal assessment of whether it matches the service you are buying. (Regulation (EU) 2016/679, Article 43)

Does certification replace a DPIA or third-party risk assessment?

Treat certification as one assurance input. You still need your own risk assessment steps for the processing context, especially where scope gaps exist or where your use case differs from what was certified.

What should we do if we cannot verify the certification body’s accreditation?

Do not use the certification to reduce diligence or to make customer claims. Document the gap, require alternative evidence, and record a risk decision if the business proceeds. (Regulation (EU) 2016/679, Article 43)

How do we keep certification from becoming stale evidence?

Add renewal/expiry monitoring and change triggers (new subprocessors, new regions, new purposes) that force re-validation. Store the evidence packet with the contract and the in-scope system record so it stays connected to operational reality.