Article 42 — Certification

At a glance

Instrument	Certification, seals and data protection marks (voluntary)
Who certifies	Accredited certification bodies or the competent supervisory authority
Duration	Maximum three years, renewable; withdrawal where criteria are no longer met
Effect	Evidence of compliance; may support transfers under Art. 46(2)(f), never a presumption of lawfulness

Article 42 is the GDPR’s framework for certification as a means of demonstrating data-protection compliance. It is closely connected with the GDPR’s broader accountability principle: instead of merely asserting that an organisation complies with the Regulation, certification creates a structured process through which particular processing activities can be assessed against defined criteria.

The first point to understand, however, is that certification is evidence of compliance, not a substitute for compliance. A controller or processor does not become GDPR-compliant merely because it possesses a certificate. It remains responsible for complying with the GDPR in its entirety.

This distinction is fundamental to understanding almost every other aspect of Article 42.

What exactly is GDPR certification?

The GDPR does not itself provide a detailed definition of the expression "certification mechanism". The EDPB approaches certification in the context of Articles 42 and 43 as a form of third-party attestation relating to processing operations. In practical terms, an independent body assesses whether a defined processing activity satisfies a defined set of approved requirements and, if it does, issues certification.

The important word here is assessment.

Certification is not simply:

"The company says it follows the GDPR."

Nor is it:

"A consultant has reviewed our privacy programme and thinks it is good."

The certification process requires an assessment against predefined certification criteria.

For example, imagine an online retailer that uses customer information to generate personalised product recommendations.

The retailer may submit that particular processing activity for certification.

The assessment might examine:

• what personal data is collected;

• why it is collected;

• the legal basis;

• how consent is obtained, if consent is relied upon;

• how the recommendation system uses the data;

• what technical safeguards exist;

• how long the data is retained;

• how individuals exercise their rights;

• whether privacy by design and by default has been implemented.

If the processing satisfies the approved criteria following the required assessment, certification may be granted.

The important point is that the certification attaches to the defined processing activity or target of evaluation, not magically to the entire organisation.

Certification is generally voluntary

Article 42 does not impose a general obligation on controllers and processors to obtain GDPR certification.

An organisation can be fully compliant with the GDPR without being certified.

This is an important distinction because "certification" can sometimes be misunderstood as another mandatory compliance requirement.

It is not.

For example, a company may operate an extensive GDPR compliance programme involving:

• records of processing;

• DPIAs;

• privacy policies;

• internal controls;

• data-subject request procedures;

• security measures;

• processor management;

• training;

• audits.

It does not automatically have to obtain Article 42 certification.

Certification is instead an additional accountability mechanism through which the organisation can obtain independent evidence supporting its compliance claims.

But "voluntary" does not mean "without legal significance"

This is an important nuance.

Certification is voluntary in the sense that the controller or processor is not generally compelled by Article 42 to seek it.

But once an organisation chooses to enter a certification process, it must participate meaningfully.

For example, it cannot say:

"Certification is voluntary, therefore I will only provide the auditor with information that makes me look compliant."

Article 42(6) requires the applicant to provide the information and access necessary for the certification process.

So:

Choosing certification is voluntary.

But:

Once certification is pursued, cooperation with the assessment is mandatory within the certification framework.

Who is Article 42 actually addressed to?

Article 42(1) principally addresses:

• Member States;

• supervisory authorities;

• the EDPB; and

• the European Commission.

These institutions are required to encourage the establishment of certification mechanisms, seals and marks.

This is different from saying:

"Every controller must become certified."

The obligation on public and regulatory institutions is to encourage the development of certification infrastructure.

The decision to obtain certification remains voluntary for controllers and processors.

Why does the GDPR encourage certification?

The answer lies in accountability and transparency.

GDPR compliance can be difficult for an outside person to assess.

Suppose a cloud provider tells its customers:

"Our processing complies with GDPR."

A customer has to decide how much confidence to place in that statement.

Certification can introduce an independent assessment mechanism.

The customer may then have additional information indicating that a defined processing activity has been assessed against specified criteria.

This is particularly useful in business-to-business relationships.

Example

A European company wants to appoint a foreign cloud provider as a processor. Instead of relying entirely on the provider's contractual representations, security questionnaires and marketing claims, the company may also consider whether the relevant processing has undergone an appropriate certification process. The certification does not eliminate the customer's own due-diligence obligations, but it can become one piece of the evidence used in the assessment. That is why Recital 100 links certification mechanisms to transparency and enabling data subjects to assess the level of data protection associated with products and services.

Certification must take account of SMEs

Article 42 expressly requires the specific needs of micro, small and medium-sized enterprises to be considered.

This is not merely a political statement.

The certification mechanism needs to be capable of being applied proportionately to organisations with different:

• sizes;

• resources;

• processing volumes;

• organisational structures;

• technical complexity.

The EDPB's approach emphasises scalability. A small retailer and a multinational retailer may technically be subject to the same GDPR requirements, but their processing operations may be radically different in scale and complexity.

Example

A local retailer may process:

• customer names;
• email addresses;
• delivery addresses;

• purchase histories.

A multinational marketplace may process:

• millions of customer profiles;

• behavioural data;

• payment information;

• location data;

• profiling information;

• extensive automated recommendation systems.

It would be unreasonable to assume that certification must be operationally identical in both cases.

The legal standard remains the GDPR, but the certification methodology and assessment scope can be appropriately scaled.

Certification does not necessarily cover the whole organisation

This is one of the most important technical aspects of Article 42.

A certificate does not necessarily mean:

"This company is GDPR-certified in every respect."

Instead, the certification has a defined scope ortarget of evaluation.

The EDPB stresses that a meaningful certification requires the object being assessed to be precisely described. This includes identifying the relevant:

• processing operations;

• data;

• processes;

• technical infrastructure;

• interfaces with other processes; and

• elements that fall outside the assessment.

This prevents misleading claims.

Why the scope of certification matters so much

Imagine a company operates ten different processing activities:

1. employee administration;

2. payroll;

3. marketing;

4. customer support;

5. fraud detection;

6. personalised recommendations;

7. website analytics;

8. CCTV;

9. recruitment;

10. cloud-hosted customer accounts.

Suppose only the personalised recommendation system is certified.

The company cannot accurately market itself as:

"Our entire organisation is GDPR-certified."

That would potentially give consumers and business customers a false impression of what was actually assessed.

The proper claim would be much narrower:

"Our personalised recommendation processing has been certified under [the applicable certification mechanism]."

The scope of the certificate determines the scope of the claim.

The three components of the certification target

The EDPB approach identifies three particularly important components when defining what is being certified:

1. the personal data involved;

2. the technical systems used to process that data; and

3. the processes and procedures associated with the processing.

These components prevent certification from becoming too abstract.

For example, saying:

"Our AI system is GDPR-compliant"

is too broad to be meaningful without identifying what the system actually does.

A proper certification assessment would need to identify the relevant processing.

A useful distinction: product certification versus processing certification

This is a particularly interesting grey area.

Article 42 is fundamentally concerned with processing operations by controllers and processors.

That creates a potential limitation when dealing with software manufacturers.

Suppose Company A develops privacy-management software.

Company A sells the software to Company B.

Company A may manufacture or supply the technology but may not itself be the controller or processor for Company B's particular customer-data processing.

Can the software itself be "GDPR-certified" under Article 42?

The source material identifies this as an area of criticism and conceptual difficulty because the GDPR's certification framework focuses on the processing activity and the controller/processor undertaking that processing.

This matters enormously in technology markets.

A software company might legitimately say:

"Our product has been assessed against certain privacy criteria."

But that does not necessarily mean:

"Every organisation using our product is GDPR-compliant."

The customer's actual implementation, configuration, purposes, legal basis and processing context remain relevant.

Why software cannot automatically transfer GDPR compliance

Suppose a vendor sells a consent-management platform.

The platform has undergone a privacy certification concerning certain processing features.

Customer A configures it correctly.

Customer B configures it incorrectly and uses it to collect unnecessary data.

Customer C uses it for a completely different processing purpose.

The certification of the relevant processing mechanism or service cannot automatically establish GDPR compliance for all three customers.

This is because GDPR compliance depends partly on how processing actually occurs in its particular context.

Certification therefore cannot be treated as a universal technological "compliance badge".

Seals and marks: what are they?

A seal or mark is essentially the visible symbol associated with successful certification.

Think of it as the public-facing representation of the certification.

The underlying certificate and assessment provide the substantive basis.

The seal or mark allows a customer, business partner or data subject to identify that a particular object has successfully undergone the relevant certification process.

The EDPB describes seals and marks as symbols indicating that the object of certification has been independently assessed and conforms to specified requirements.

A seal is not merely a marketing logo

This distinction matters.

A company should not create a logo saying:

"GDPR Secure"

and imply that it is an Article 42 certification seal.

A GDPR certification seal or mark is connected to an actual certification mechanism and independent assessment.

The underlying assessment, criteria and certification authority therefore matter.

A self-created privacy logo has no automatic status under Article 42.

Certification must be based on approved criteria

Article 42(5) is central to the entire framework.

Certification cannot be issued simply because an auditor subjectively believes that an organisation has "good privacy practices".

There must be approved certification criteria.

Those criteria are approved through the mechanisms specified in Article 42.

They may be approved by the competent supervisory authority or, in the relevant circumstances, by the EDPB.

This introduces objectivity and consistency into the process.

What makes good certification criteria?

The source material identifies three particularly important qualities:

• verifiability;

• significance; and

• suitability.

These concepts are worth unpacking.

Verifiability

The criterion must be capable of being objectively assessed.

For example:

"The organisation respects privacy."

is too vague.

A more verifiable criterion might require evidence that:

data-subject access requests are recorded, authenticated, processed within defined procedures and subject to documented oversight.

The latter can actually be tested.

Significance

The criterion should meaningfully relate to data protection.

A trivial administrative requirement should not be presented as proof of substantive GDPR compliance.

Suitability

The criterion must be appropriate for the processing operation being assessed.

A certification criterion designed for a simple customer-support platform may not be suitable for large-scale biometric processing.

What can certification criteria examine?

Depending on the scope, criteria may examine matters such as:

• lawfulness of processing;

• GDPR principles;

• data-subject rights;

• breach notification procedures;

• privacy by design and default;

• DPIAs where relevant;

• technical and organisational measures.

But these elements do not necessarily receive identical weight in every certification.

The scope of the certification matters.

Example

For a cybersecurity-focused certification, Article 32-related controls may be particularly important. For a data-subject rights certification, the assessment may focus more heavily on:

• transparency;
• access;

• rectification;

• erasure;

• restriction;

• objection.

For an AI-related processing certification, the criteria may need to examine the specific processing architecture and associated rights and safeguards.

Certification is not a second GDPR

Another subtle point is that certification criteria are not supposed to replace the GDPR.

They operationalise relevant GDPR requirements for a defined processing context.

Suppose the GDPR says that technical and organisational measures must be appropriate to risk.

A certification mechanism can turn that broad legal requirement into more concrete assessment criteria.

For example, it might examine:

• access controls;

• encryption;

• authentication;

• logging;

• incident response;

• backup arrangements;

• testing.

The certification criteria therefore translate broad legal requirements into assessable controls.

Certification can make accountability more demonstrable

This is where Article 42 interacts strongly with Article 5(2).

Accountability requires the controller not only to comply but to be able to demonstrate compliance.

Certification can provide external evidence supporting that demonstration.

Suppose the DPA asks:

"How did you ensure that this processing activity complied with GDPR security requirements?"

The controller can provide:

• internal policies;

• risk assessments;

• DPIAs;

• audit reports;

• technical documentation;

• and, where relevant, certification documentation.

The certificate does not answer the question by itself.

But it can form part of the evidence.

The supplied material expressly identifies certification as potentially relevant to demonstrating compliance under provisions including Articles 5(2), 24, 25, 28 and 32.

But certification does not bind the DPA

This is one of the most important practical limitations.

Suppose a company holds an Article 42 certificate.

Later, the DPA investigates the company and discovers that its actual processing does not comply with the GDPR.

The company cannot simply respond:

"But we are certified, so the DPA cannot take action."

Certification does not eliminate the DPA's statutory powers.

Article 42 expressly preserves those powers.

Certification does not bind a court either

Similarly, a court is not automatically required to accept the conclusion of a certification body as legally conclusive.

The certificate may be relevant evidence.

But it does not amount to a judicial determination that the organisation has complied with every applicable GDPR obligation.

This is another reason why:

Certification ≠ immunity

and:

Certification ≠ legal safe harbour for all GDPR purposes.

Can certification still help when enforcement occurs?

Yes.

The fact that certification is not binding does not mean it is legally irrelevant.

A certification may demonstrate that the organisation had implemented certain measures and had undergone an independent assessment.

That can potentially be relevant when a DPA evaluates the organisation's overall compliance conduct and, where applicable, enforcement consequences.

The source material notes that adherence to approved certification mechanisms is something DPAs should take into account when determining whether to impose a fine and its amount.

But this must not be overstated.

Certification does not mean:

"No fine can ever be imposed."

Nor does it establish that the controller has complied with provisions outside the certification's scope.

The importance of the certification scope in enforcement

Suppose Company X has certification for its customer-support processing.

A DPA later investigates an unrelated marketing operation.

The company cannot necessarily rely on its customer-support certification as evidence that its marketing processing complied with GDPR.

Even within the certified area, the certificate does not prevent enforcement if the organisation subsequently deviates from the certified conditions.

This makes the scope and continuing validity of the certificate extremely important.

Certification as a tool for international transfers

Article 42 has another important function that is sometimes overlooked.

Certification mechanisms can be used as an appropriate safeguard for certain transfers to third countries under Article 46(2)(f).

This is fundamentally different from ordinary certification used simply to demonstrate GDPR compliance.

Here, certification can form part of the legal architecture supporting an international transfer.

This is why Article 42 is relevant not only to internal GDPR compliance teams but also to:

• international data-transfer teams;

• multinational organisations;

• processors located outside the EEA;

• vendor-management teams;

• privacy counsel handling cross-border transfers.

A transfer certification is not automatically enough

This is a crucial nuance.

Suppose a US-based processor that is not itself subject to the GDPR adheres to an approved certification mechanism intended to support transfers.

The certification alone does not magically solve the transfer issue.

The processor must also make binding and enforceable commitments to apply the appropriate safeguards, including safeguards concerning data-subject rights.

So the architecture is roughly:

Approved certification mechanism

binding and enforceable commitments

=

potential Article 46(2)(f) safeguard.

Why are binding commitments necessary?

Imagine a non-EEA processor says:

"Our company has obtained this certification."

But its legal obligations under the certification are not enforceable against it.

If something goes wrong, the data subjects may have no effective mechanism to enforce the promised safeguards.

The GDPR therefore requires an additional layer of legal enforceability.

This is consistent with the broader Article 46 requirement that appropriate safeguards must be accompanied by enforceable rights and effective remedies for individuals.

Certification therefore cannot simply become a decorative international-transfer badge.

Certification versus adequacy

Certification under Article 42 should not be confused with an adequacy decision under Article 45.

An adequacy decision is a determination concerning the legal framework of a country or relevant territory.

Certification under Article 42 is an accountability mechanism concerning particular processing and safeguards.

Thus:

Article 45 adequacy → country/territory-level mechanism.

Article 46(2)(f) certification → safeguard mechanism connected to a particular controller/processor and binding commitments.

These are conceptually very different routes.

Transparency of the certification process

Article 42(3) requires certification to be available through a transparent process.

Transparency here is more than simply publishing:

"We offer GDPR certification."

A prospective applicant should be able to understand what is actually being assessed.

The EDPB approach identifies information such as:

• the target of evaluation;

• the applicable approved criteria;

• the assessment methodology; and

• the validity period.

This is essential because otherwise two certification schemes could both claim:

"GDPR certified"

while conducting radically different assessments.

Comparability matters

Transparency also serves another purpose: comparability.

Suppose Vendor A has a privacy certificate and Vendor B has another privacy certificate.

A customer should ideally be able to determine:

• what was assessed;

• against which criteria;

• using what methodology;

• for how long;

• and within what scope.

Otherwise, the mere existence of a logo tells the customer almost nothing.

The EDPB therefore emphasises that certification information should facilitate comparison of results.

Why supporting documentation is important

A certificate by itself can be very thin evidence.

Suppose an organisation produces a one-page certificate stating:

"Certified for GDPR compliance."

What exactly does that prove?

Without knowing:

• the scope;

• the criteria;

• the assessment methodology;

• deficiencies identified;

• corrective actions;

• reasoning for certification;

the certificate could be misleading.

The EDPB therefore emphasises supporting documentation and written reports explaining how the criteria were met, how deficiencies were corrected and why certification was granted or maintained.

Certification should therefore be evidence-rich

Imagine an assessment discovers that a company initially fails three criteria.

Instead of immediately rejecting the application, the certification mechanism permits remediation.

The company:

• changes its access-control system;

• modifies its privacy notice;

• implements a new deletion process.

The certification documentation should capture those corrective measures and explain why the final position satisfies the criteria.

That makes certification much more meaningful than a simple pass/fail sticker.

Who can issue certification?

Article 42(5) provides two broad routes:

An appropriately recognised certification body under Article 43

or

the competent supervisory authority itself.

Both must operate on the basis of approved certification criteria.

This distinction is important because the GDPR does not insist that every certification must be directly issued by the DPA.

A DPA can allow an accredited certification-body ecosystem to perform the certification function.

Why does Article 43 matter?

Article 42 cannot really be understood in isolation from Article 43.

Article 42 tells us:

certification exists and how it operates.

Article 43 deals substantially with:

the certification bodies that perform the certification function.

For example, Article 43 addresses matters such as accreditation and the requirements certification bodies must satisfy.

This separation is important because the credibility of certification depends heavily on the credibility of the body issuing it.

If anyone could issue an Article 42 certificate, the mechanism would have very little regulatory value.

Different institutional models are possible

The GDPR gives supervisory authorities considerable flexibility in implementing certification mechanisms.

The source identifies several possible models.

A DPA could:

• issue certifications itself;

• issue certifications while using third parties for parts of the assessment;

• establish a certification scheme and allow certification bodies to operate it;

• or encourage the market to develop certification mechanisms.

This means that the certification ecosystem can vary between jurisdictions.

Why separation of roles matters where the DPA certifies

If a DPA itself issues certification, an institutional tension arises.

The same authority could potentially:

1. create or approve the certification mechanism;

2. certify an organisation;

3. later investigate that organisation;

4. determine whether it breached the GDPR.

The EDPB therefore highlights the importance of considering separation of powers and conflicts of interest when a DPA conducts certification itself.

This is a subtle but significant governance issue.

Certification criteria are not universal automatically

Another technical point concerns the geographical and institutional approval of criteria.

The source material notes that certification bodies operate on the basis of criteria approved through the applicable supervisory-authority framework, and the EDPB guidelines discuss the relationship between approval and the Member State in which certification is offered.

Therefore, one should not casually assume:

"A certification scheme exists somewhere in Europe, therefore any certification body can automatically use it everywhere."

The approval and accreditation architecture matters.

European Data Protection Seal

Where certification criteria are approved by the EDPB, Article 42 contemplates the possibility of a common certification known as the European Data Protection Seal.

The idea is to facilitate a certification framework operating at European level rather than remaining confined to a single national framework.

This is particularly useful where processing activities and organisations operate across several Member States.

A common European framework can reduce fragmentation.

What does the European Seal not mean?

It should still not be interpreted as:

"The organisation has received an unlimited European guarantee of GDPR compliance."

The same principles continue to apply:

• there is a defined scope;

• defined criteria;

• an assessment;

• a period of validity;

• continuing requirements;

• potential withdrawal.

The European nature of the seal does not eliminate these limitations.

The applicant must provide information and access

Article 42(6) is operationally important.

The controller or processor seeking certification must provide the certification body, or, where applicable, the DPA, with the information and access necessary to conduct the certification procedure.

This creates an important practical obligation on the applicant.

Certification is not a process where the assessor simply looks at publicly available documents.

The organisation must actively cooperate.

What does "information and access" mean in practice?

Depending on the certification scope, this could involve access to:

• policies;

• records;

• contracts;

• technical documentation;

• system configurations;

• processing records;

• audit evidence;

• security controls;

• relevant personnel;

• operational processes.

For example, if certification concerns a cloud platform's access controls, the assessor may need evidence demonstrating how access is actually managed rather than merely receiving a policy saying:

"Access is restricted."

The assessor needs enough evidence to determine whether the requirement is actually satisfied.

The obligation is proactive

The source material makes an important point: the controller or processor must proactively provide the information needed, and must provide additional information where reasonably required during the certification process.

This matters because certification is fundamentally evidence-based.

If an organisation knows that a particular document or technical record is relevant to the assessment, it should not wait for the assessor to discover that it exists.

What happens if the organisation refuses access?

If an organisation refuses to provide necessary information or access, the certification body may be unable to establish conformity with the criteria.

This can prevent certification from being granted or maintained.

The reason is straightforward:

An assessor cannot certify what it cannot properly assess.

This is also why a certification claim should never be interpreted as an assessment based merely on the organisation's own assurances.

Certification has a maximum three-year duration

Article 42(7) places a maximum validity period of three years on certification.

This is important because privacy compliance is not static.

An organisation's:

• technology;

• processing;

• vendors;

• security architecture;

• legal basis;

• business model;

may change substantially within three years.

The certification therefore cannot operate as a perpetual guarantee.

The actual validity period can be shorter than three years.

Why a three-year maximum makes sense

Imagine a company obtains certification for a customer-data platform in 2026.

In 2028 it introduces:

• AI profiling;

• biometric authentication;

• a new advertising model;

• extensive cross-border transfers.

The processing environment may now be materially different from what was assessed.

A permanent certificate would therefore provide a misleading sense of security.

The three-year maximum forces the organisation to undergo continuing scrutiny.

Renewal is not automatic

After the certification period ends, the organisation may seek renewal.

But renewal depends on the relevant requirements continuing to be met.

The organisation cannot say:

"We passed three years ago, therefore renewal is automatic."

The certification body or DPA must have a basis for concluding that the requirements remain satisfied.

Renewal may be simplified, but not meaningless

The source notes that the review for renewal can be conducted in a simplified manner.

That does not mean:

"No reassessment is required."

Rather, the certification mechanism may adopt an efficient renewal methodology where appropriate.

For example, if the organisation's processing, systems and controls have remained substantially unchanged and the mechanism permits a simplified reassessment, the renewal process may focus on relevant changes and continued conformity.

But if there have been major changes, a more extensive reassessment may be necessary.

Certification can be withdrawn before expiry

This is another essential distinction.

The fact that a certificate says:

"Valid until December 2028"

does not mean the certificate is untouchable until December 2028.

If the requirements are no longer satisfied, certification can be withdrawn.

Example

Suppose a company is certified for a processing system in 2026. In 2027 it fundamentally changes the system and removes several controls that were necessary to satisfy the certification criteria. The organisation cannot simply continue displaying the certificate because its formal expiry date has not arrived. The certification may need to be withdrawn.

Withdrawal can be initiated by the certification body or DPA

Depending on the applicable structure, certification may be withdrawn by:

• the certification body; or

• the competent supervisory authority.

The DPA also has powers under Article 58 to withdraw certification or require the certification body to withdraw it where the relevant requirements are no longer satisfied.

This gives the regulatory system a further layer of oversight.

Certification therefore involves continuing compliance

The entire lifecycle is important:

Application → assessment → certification → monitoring/review → renewal or withdrawal

It is not:

Application → certificate → permanent protection

This is one of the most important operational implications of Article 42.

What happens if the organisation becomes non-compliant after certification?

This is where the accountability principle becomes particularly important.

Suppose a company was correctly certified when the assessment took place.

Six months later:

• a new processing purpose is introduced;

• the retention period changes;

• a major vendor is replaced;

• security controls are weakened.

The certificate does not freeze reality.

If the processing no longer meets the certification criteria, the organisation must address the deficiency, and the certification may ultimately be withdrawn.

Certification therefore cannot be used as a shield against subsequent changes.

The public register

Article 42(8) requires the EDPB to maintain a register of certification mechanisms and data-protection seals and marks and make it publicly available.

This is another transparency mechanism.

Without a public register, organisations and consumers could struggle to distinguish between:

• a genuine GDPR certification mechanism;

• a private marketing programme;

• an unrelated security certification;

• and a self-created "privacy seal".

The register therefore helps establish the legitimacy and visibility of recognised mechanisms.

Why the public register matters commercially

Consider two cloud providers.

Provider A says:

"GDPR certified."

Provider B says:

"Certified under an Article 42 mechanism listed in the EDPB register."

The second statement gives a customer a route to investigate:

• what the certification mechanism is;

• what criteria apply;

• who administers it;

• what the certification covers.

This improves market transparency.

Certification is particularly useful in procurement

One of the most practical applications is vendor selection.

A company choosing between several processors may consider certification alongside:

• security assessments;

• contractual guarantees;

• audit rights;

• technical controls;

• breach history;

• transfer mechanisms.

Certification can reduce some information asymmetry.

A buyer does not have to rely entirely on a vendor's own marketing claims.

But it still must examine the scope of the certification.

Certification does not remove Article 28 due diligence

Suppose a controller appoints a processor that has GDPR certification.

The controller cannot simply say:

"The processor is certified, therefore Article 28 compliance is automatically satisfied."

The controller still has to satisfy its own GDPR obligations concerning processor selection and the contractual framework.

Certification may support the assessment, but it does not transfer the controller's legal responsibility to the certification body.

This is a direct consequence of Article 42(4)'s preservation of controller and processor responsibility.

Certification and accountability: the deeper relationship

Article 42 becomes much clearer when viewed through Article 5(2).

The GDPR asks organisations not merely:

"Are you compliant?"

but also:

"Can you demonstrate that you are compliant?"

Certification is one mechanism through which an organisation can build that evidentiary record.

For example, a controller might maintain:

• DPIAs;

• records of processing;

• internal audit reports;

• security assessments;

• processor assessments;

• training records;

• certification reports.

Certification can therefore become one component of the organisation's broader accountability architecture.

Certification is not an "audit immunity" mechanism

This deserves explicit emphasis.

Suppose a company has been certified and later suffers a serious data breach.

The company cannot argue:

"We were certified, therefore the breach cannot result in regulatory consequences."

The DPA will still examine the actual facts.

Questions may include:

• What security measures existed?

• Were they appropriate to the risk?

• Had the company changed the system after certification?

• Were known vulnerabilities ignored?

• Was the certification scope relevant to the breached system?

• Were corrective measures taken?

• Was the incident properly handled?

Certification may form part of the evidence, but it does not answer these questions automatically.

A particularly important grey area: certification claims

The greatest practical risk may sometimes arise not from obtaining certification but from how certification is represented to customers.

Suppose only one processing activity is certified.

The company advertises:

"We are GDPR certified."

A customer could reasonably understand that to mean the organisation as a whole has been assessed.

That could overstate what the certificate actually establishes.

The EDPB's emphasis on precisely defining the target of evaluation is therefore important not merely for auditors but also for marketing and consumer protection.

The certificate must communicate meaningful information

A meaningful certification claim should allow the reader to understand, at least conceptually:

• what was assessed;

• under which criteria;

• by whom;

• for how long;

• and what the certification actually covers.

This is why transparency of the certification process is so important.

A bare logo without context can create a false impression of comprehensive compliance.

Certification mechanisms need to remain technically relevant

Another operational issue is technological change.

Imagine a certification mechanism designed around conventional databases.

The certified organisation later introduces:

• machine-learning models;

• automated decision-making;

• synthetic data;

• federated learning;

• large-scale behavioural profiling.

The certification mechanism may need to evolve to address these technologies.

Otherwise, the certificate could technically remain valid while becoming increasingly disconnected from the actual risks.

This is why certification mechanisms and criteria need appropriate review and development.

The difference between certification and internal audit

An internal audit is performed by the organisation itself or someone acting within its internal governance structure.

Article 42 certification involves an independent assessment through the relevant certification framework.

This creates an external assurance element.

However, organisations should not choose between the two.

A mature privacy programme can use:

internal audit + external certification + continuous monitoring

rather than treating certification as a replacement for internal governance.

The difference between certification and ISO certification

Another common source of confusion is assuming that any ISO certification automatically constitutes GDPR certification under Article 42.

It does not.

An organisation might have:

• ISO 27001 certification for information security;

• ISO 27701-related privacy management controls;

• an Article 42 GDPR certification.

These are not automatically interchangeable.

An information-security certification may provide useful evidence about security controls, but GDPR certification under Article 42 requires assessment against the applicable approved GDPR certification criteria.

The scope and legal framework of the certification therefore matter.

Article 42 is ultimately about credible assurance

The central problem Article 42 attempts to solve is one of information asymmetry.

The organisation knows far more about its processing than:

• its customers;

• business partners;

• data subjects;

• procurement teams.

Certification introduces an independent assessment mechanism capable of reducing that information gap.

But the GDPR carefully avoids giving certification unlimited legal effect.

The balance is therefore:

Independent assessment → stronger evidence

but not:

Independent assessment → automatic compliance or immunity

The complete architecture of Article 42

The provision can ultimately be understood as a chain.

A certification mechanism is established.

Its criteria are approved.

A controller or processor voluntarily submits a defined processing activity.

The certification body or competent DPA assesses that activity against the approved criteria.

The applicant must provide the necessary information and access.

If the requirements are satisfied, certification may be granted.

A seal or mark may communicate that certification.

The certification remains valid for no more than three years.

The organisation must continue meeting the relevant requirements.

If the requirements cease to be satisfied, certification can be withdrawn.

The EDPB maintains a public register of the mechanisms, seals and marks.

And throughout this process, the controller or processor remains responsible for compliance with the GDPR, while the DPA retains its statutory powers.

The central idea behind Article 42

The most accurate way to understand Article 42 is therefore:

Certification is an independent, structured and transparent mechanism through which a defined processing operation can be assessed against approved GDPR-related criteria, giving the controller or processor credible evidence that can support its demonstration of compliance.

But the certificate does not transform the organisation into a universally "GDPR-compliant entity", does not eliminate its underlying responsibilities, does not prevent regulatory investigation, and does not automatically cover processing outside the defined certification scope.

Its value lies in credible evidence, transparency, accountability and assurance.

That is the conceptual core of Article 42.