Data Protection Basics for Credential Issuers

The personal data inside a credential and the duties that come with it.

This course is part of the ICoBC Credentialing Skills Framework (ICSF), skill SECP "Security, privacy and data protection", level L1 "Contribute", stage K "Knowledge". The VRITE pillar is Trustworthiness. At this level and stage you explain basic data protection duties and privacy risks when issuing or sharing credentials. Knowledge means understanding concepts, rules and the reasons behind them, so that you can explain and recognise them.

Who it is for

• L&D and corporate academy leads
• HR and learning technology owners
• Programme and micro-credential leads
• Quality, registry and admissions staff
• Education IT and credential operations
• Professional bodies and sector associations

No prerequisites. You do not need legal training.

Learning outcomes

1. Identify personal data in credentials, evidence and platform logs.
2. Explain legal bases, data minimisation and retention for issuing and verification.
3. Describe earner rights and how to handle requests, including deletion and revocation.
4. Recognise when a data protection impact assessment is needed.

Workload and format

Self-paced, about 2 hours of notional learning. Five modules, each with explanation, a worked example, a practice activity and a short quiz. Live or workshop elements are described as facilitator notes and are optional.

Assessment and badge

A final knowledge check of 10 scenario-based questions. If you pass, you earn the badge "Data Protection Basics for Credential Issuers (Knowledge, L1)", alignment code ICSF-SECP-L1-K. The badge evidence is the passed knowledge check.

This course gives general educational information. It is not legal advice. Your organisation's data protection officer or legal adviser decides how the rules apply to your situation.

Completing this course shows that you understand the concepts taught here. It does not prove competence in a job role.

Personal data in credentials

What counts as personal data

Personal data is any information that relates to an identified or identifiable person. In the EU, the General Data Protection Regulation (GDPR) uses this definition. You do not need a name for data to be personal. If someone can be recognised by combining the data with other information, it is personal data.

A digital credential contains more personal data than most issuers expect. Think about three layers:

• The credential itself. Earner name, email address or other identifier, the award title, the issue date, the issuer name, a unique credential identifier and sometimes a link to a public page.
• The evidence. Assessment results, grades, portfolios, work samples, recordings, assessor comments, reflective statements and identity documents used for verification.
• The platform logs. Login times, IP addresses, device information, email delivery records, verification requests and downloads.

All three layers can identify a person. A credential identifier that looks like a random number is still personal data if your system can link it to an earner.

Some data needs extra care. The GDPR sets stricter rules for special categories of data, for example health data. Evidence can contain such data without anyone planning it. A reasonable adjustment record for an exam, a medical note in a portfolio or a photograph of a person in a workshop can bring special category data into your records.

Where the data sits

Mapping where data sits is the first practical step in data protection. Credential data tends to spread:

• the learning management system or student record system
• the credential issuing platform
• the earner's wallet or profile
• email systems, spreadsheets and shared drives
• backups and exports
• third-party tools used for proctoring, video or messaging

A data map does not need to be complex. A simple table with the data item, where it is stored, who can see it and how long it is kept is a good start.

Why identification matters first

You cannot protect what you have not found. Every later duty in this course, such as choosing a legal basis, setting retention periods and answering earner requests, starts from knowing what personal data you hold and where.

Worked example: A college and a corporate academy map their data

Context 1: a college. A college offers a short course in digital skills and issues a micro-credential. The programme lead and the registry officer list the data. The credential holds the earner name, email address, award title and issue date. The evidence folder holds a final project, the assessor's feedback and, for two earners, a note about extra exam time because of a learning difficulty. The issuing platform logs every login and every verification request. The team marks the extra-time notes as sensitive, because they may reveal health information, and moves them out of the evidence folder into the access-controlled student support record.

Context 2: a corporate academy. An HR department issues badges for an internal leadership programme. The badge shows the employee name, the programme title and the date. The manager's rating forms and a recorded role-play session are held as evidence. The learning technology owner notes that the role-play recording shows the faces and voices of colleagues who are not earners, so that data concerns more than one person.

Practice activity: Build a three-column data map

Take one credential your organisation issues, or one you can imagine. Create a table with three columns: credential, evidence and platform logs. List at least three personal data items in each column. Mark any item that might be special category data. Then add a fourth note: who outside your team can see each item.

Check your understanding

Legal basis and purpose

Purpose comes first

Under the GDPR, personal data must be collected for specified, explicit and legitimate purposes. You decide the purpose before you collect the data, and you tell people what it is. Later use of the data must fit with that original purpose.

For a credential issuer, typical purposes are:

• assessing whether an earner met the requirements
• issuing and delivering the credential
• allowing others to verify the credential
• keeping a record so that the issuer can confirm an award in the future
• improving the programme through aggregate analysis

Each purpose needs its own thinking. Data collected to issue a credential is not automatically available for marketing.

The legal bases

The GDPR lists six legal bases for processing personal data. In your own words, they are:

1. Consent: the person freely agrees, with a clear and specific choice.
2. Contract: processing is needed to perform a contract with the person, or steps before a contract.
3. Legal obligation: a law requires the processing.
4. Vital interests: processing protects someone's life.
5. Public task: processing is needed for a task in the public interest or an official function.
6. Legitimate interests: processing serves a real interest of the organisation or a third party, and it does not override the person's rights and freedoms after a balancing test.

You need one valid legal basis for each purpose. You choose it before processing starts and record it. Special category data needs an additional condition on top of the legal basis.

Applying the bases to credentials

There is no single right answer for all issuers. Here are common patterns, to be confirmed by your data protection officer:

• Assessing and issuing a credential often rests on contract (the learning agreement or enrolment), or on public task for a public institution.
• Keeping a long-term record of awards may rest on legal obligation, public task or legitimate interests, depending on the sector and country.
• Publishing a credential on a public profile page is a different purpose. The earner usually controls this, so consent is a common basis. Consent should be easy to give and easy to withdraw.
• Sending marketing emails to earners is a separate purpose and needs its own basis.

Consent has a weakness in employment. If an employee depends on an employer, consent may not be freely given. HR departments therefore avoid relying on consent when the employee has little real choice.

Telling people what you do

Whatever basis you choose, people have the right to be informed. A privacy notice should say who the issuer is, which data is collected, for which purposes, on which legal basis, who receives it, how long it is kept and how to use their rights. Write the notice in plain language and give it before or at the time of collection.

Worked example: Public display needs a separate decision

Context 1: a training provider. A training provider issues a certificate of completion to every learner. The legal basis for issuing it is the training contract. The provider's platform has a button "Make my credential public". The programme lead decides that publication is a different purpose. The button is off by default, a short explanation sits next to it, and the learner can switch it off again at any time. The provider records consent only for that purpose.

Context 2: a corporate academy. An HR department wants to publish employee badges on the company careers page to show how many staff are certified. The HR lead sees that employees may not feel free to say no. The department chooses an aggregate count, with no names, instead of individual display. Individual display stays possible only if an employee chooses it for their own profile.

Practice activity: Match purposes and bases

List four purposes for which your organisation, or an imagined issuer, uses credential data. For each, write the legal basis you think fits and one sentence explaining why. Mark the purposes where you are unsure and note who in your organisation would decide.

Check your understanding

Minimise what you publish

Data minimisation

Data minimisation is a core GDPR principle. Personal data must be adequate, relevant and limited to what is necessary for the purpose. Ask for each field: do we need this to achieve the purpose? If not, do not collect it or do not show it.

For credentials, minimisation applies in three places:

• Collection. Ask earners only for the data you need. A date of birth is not needed to issue a participation badge in most cases.
• Display. A public credential page should show what a verifier needs, such as award title, issuer and date. It rarely needs an email address, a full grade report or a home address.
• Evidence. Keep evidence only as long and as detailed as needed to justify the award.

Public, shared and private

It helps to sort every data item into one of three tiers:

• Public: anyone with the link can see it.
• Shared: shown to a specific verifier, employer or institution that the earner chooses.
• Private: stays with the issuer, or with the earner, and is not shown to others.

Verification needs very little. A verifier usually needs to know that the credential is genuine, who issued it, what it says and whether it is still valid. It does not need to see the assessor's comments. Design verification to return the minimum answer. This is also called privacy by design and by default: the safest setting is the default setting.

Retention and deletion

Personal data must not be kept longer than necessary for the purpose. This is the storage limitation principle. The GDPR does not set a single number of years. You decide a retention period for each type of data, write it down and apply it. Laws on records, accreditation or employment may require a minimum period for some data. Check these with your legal adviser.

A useful way to think about this is a data lifecycle: collect, use, store, share, review and delete. Each stage has a question. What do we collect and why? Who can use it? Where is it stored? With whom do we share it? When do we review it? When and how do we delete it?

Keeping a verifiable record

Credential issuers face a real tension. The earner may want to delete data, but the issuer may need to keep a minimal record that an award was made, so that it can confirm the award later. A good design keeps this record small: earner name or identifier, award, date and status. Detailed evidence can follow a shorter retention period.

Share the retention schedule with earners in your privacy notice, so that nobody is surprised.

Worked example: Shortening what is shown and kept

Context 1: a university. A university registry issues digital credentials for a postgraduate certificate. The verification page used to show the earner name, programme, grade band and the email address of the programme office. The quality lead reviews the page against the purpose of verification. The grade band and personal contact details are removed from the public view. The registry keeps a minimal award record for the long term. Assessment scripts follow a shorter retention period set out in the retention schedule, and the schedule is published in the privacy notice. The periods themselves are set by the university with its legal adviser.

Context 2: a corporate academy. An HR department issues badges for compliance training. Evidence consists of quiz results per employee. The department decides that the result per question is not needed once the badge is issued. It keeps pass or fail, date and badge identifier, and deletes the question-level data after a short period defined with legal advice. When an employee leaves, the badge record follows the HR retention rules for personnel files.

Practice activity: Sort fields into three tiers

Take the data items from your Module 1 data map. Sort them into public, shared and private. For each item you place in public or shared, write the purpose it serves. Remove any item for which you cannot name a purpose. Then propose a retention rule for the three most sensitive items, and note who would approve it.

Check your understanding

Earner rights

The rights in plain language

The GDPR gives people rights over their personal data. Earners are data subjects. Their main rights, in plain words, are:

• To be informed about how their data is used.
• Of access: to get a copy of their data and information about how it is processed.
• To rectification: to have wrong data corrected.
• To erasure: to have data deleted in certain situations. Sometimes called the right to be forgotten.
• To restrict processing: to ask you to pause use of their data in certain situations.
• To data portability: to receive data they provided in a structured, commonly used format, and to have it passed on, in certain situations.
• To object: to object to certain processing, including processing based on legitimate interests or public task.
• Related to automated decisions: protections when decisions are made only by automated means with significant effects.

Not every right applies in every case. Which ones apply depends on the legal basis and the situation. The point for an issuer is to recognise a request and send it to the right person quickly.

Handling a request

Requests do not need a special form. An earner may write an email, use a web form or call. Your staff must be able to recognise a request when it arrives, even if the earner does not use legal words.

A simple process has these steps:

1. Recognise and log. Note the date received and who received it.
2. Verify identity. Confirm that the person is who they say they are, without asking for more data than needed.
3. Route. Send the request to the person responsible, often the data protection officer or privacy contact.
4. Search. Check all places on your data map, including platform logs, evidence stores and email.
5. Decide and respond. Answer within the legal deadline, explain what you did or why you cannot do it.
6. Record. Keep a note of the request and the outcome.

The GDPR sets a general deadline of one month to respond, with a possible extension for complex cases.

Deletion and revocation

Two terms are often mixed up, so keep them apart.

• Revocation is a credential status action by the issuer. The credential is marked as no longer valid, for example because it was issued by mistake or the earner no longer meets the requirements. Revocation does not necessarily delete personal data. A revocation record may need to be kept so that verifiers can see the status.
• Deletion (erasure) is the removal of personal data from your systems. It follows from a request or from the end of a retention period.

An earner may ask for their credential to be deleted. The issuer considers whether the right to erasure applies, whether a legal obligation or other exception means data must be kept, and which part of the data can be removed. Often the answer is partial: the public profile and detailed evidence are removed, and a minimal record is kept where the law or a legitimate purpose requires it. The issuer explains the decision to the earner.

If a credential was shared with others, for example a verifier or a wallet provider, the issuer may need to inform those recipients about deletion or rectification, where this is possible.

Worked example: A deletion request after a course

Context 1: a training provider. A former learner emails the provider: "Please remove my certificate and everything you hold about me." The registry officer recognises this as an erasure request, logs it the same day and asks the learner to reply from the registered email address to confirm identity. The privacy contact searches the platform, the evidence store and the email archive. The public profile and the project files are deleted. A minimal award record is kept because the provider has a legal duty to keep records of accredited awards, and the provider explains this to the learner in its reply. The provider notes the request and outcome in its log.

Context 2: a corporate academy. An employee asks HR to delete a badge after changing roles. The HR privacy contact separates two questions. First, should the badge be revoked? The badge remains valid, so no. Second, should data be deleted? The employee's personnel file follows HR retention rules, but the badge on the employee's profile can be removed and the platform's access logs fall under their own retention period. HR explains this and offers the employee the option to hide the badge.

Practice activity: Walk through a request

Imagine this email: "I am a former learner and I want to know what you hold about me and I want my badge gone." Write a short response plan. List which rights are involved, the six process steps with names of roles in your organisation, and which of the two actions, revocation or deletion, you would consider. Note one case in which you might keep some data and explain why.

Check your understanding

Third parties, platforms and transfers

Who else touches the data

Few issuers run everything themselves. Credential data often reaches other organisations:

• a credential issuing platform or wallet provider
• a learning management system provider
• an assessment or proctoring service
• an email delivery service
• cloud hosting and backup providers
• verifiers, such as employers or other institutions
• AI services used for marking, summaries, matching or chat support

The GDPR distinguishes roles. A controller decides why and how personal data is processed. A processor processes data on behalf of the controller. Most issuers are controllers. Platform providers are often processors. When a provider acts as a processor, the issuer needs a written contract, called a data processing agreement, that sets out what the provider may do with the data and which security measures apply. In some cases two organisations decide together and are joint controllers, and they must agree on their respective responsibilities.

Choosing a platform is therefore also a data protection decision. Ask which data it collects, where it is stored, who can access it, which subprocessors it uses and how it supports deletion and export.

Transfers outside the EU or EEA

The GDPR restricts transfers of personal data to countries outside the European Economic Area, unless a safeguard applies. Safeguards include adequacy decisions of the European Commission, standard contractual clauses and some other mechanisms. A transfer can happen without anyone moving files. Remote access to data from another country can count too.

Your task at this level is to recognise when a transfer may occur and to ask the right questions. The legal assessment belongs to your data protection officer or legal adviser.

Sending evidence or earner data to AI services

AI services are now common in education and HR tools. They can summarise evidence, suggest feedback, draft emails or answer earner questions. Sending evidence or earner data to an AI service is a disclosure to a third party and needs the same care as any other disclosure.

Questions to ask before sending data to an AI service:

• Purpose and basis. Does this use fit the purposes in our privacy notice and our legal basis? Is it a new purpose?
• Role of the provider. Is the provider a processor under a written agreement? Does it use our data to train its own models? If so, on what terms?
• Minimisation. Can we remove names and identifiers before sending? Does the task need the full evidence or only a part?
• Location and transfers. Where is the data processed and stored?
• Retention. How long does the provider keep inputs and outputs, and can we have them deleted?
• Sensitive data. Does the evidence contain special category data, data about children or data about third parties?
• Human oversight. If the AI output affects an earner, for example by influencing a grade, is a person involved in the decision? Rules on automated decisions may apply.
• Transparency. Have we told earners that AI services are used?

A simple rule is that staff do not paste earner data into public AI tools that the organisation has not approved. Publish an approved list and a short staff rule.

When a DPIA is needed

A data protection impact assessment (DPIA) is a structured process to describe processing, assess risks to people and plan measures to reduce them. The GDPR requires a DPIA where processing is likely to result in a high risk to the rights and freedoms of people. Supervisory authorities publish lists of processing types that need one.

Signs that you should ask your data protection officer whether a DPIA is needed:

• large-scale processing of special category data
• systematic monitoring of people, for example proctoring by camera
• use of new technologies, including AI, to evaluate or score people
• automated decisions with significant effects on earners, such as pass or fail
• combining datasets in ways earners would not expect
• processing data about children or other vulnerable people
• a new platform that holds credentials for many people in several countries

Do the DPIA before the processing starts. A DPIA does not mean the project must stop. It shows what must change to make the processing acceptable.

Watching for change

Data protection rules are stable at their core, but the legal landscape around them can change. Proposed changes to data rules, known as the Digital Omnibus, are under discussion at EU level. Status as of November 2026; check before publishing. Issuers should follow official announcements and ask their data protection officer to flag changes that affect credential processes.

Worked example: An AI tool for feedback and a proctoring service

Context 1: a university. A programme team wants to use an AI service to draft feedback on written assignments. The team lead lists the data involved: student names, essays and sometimes personal stories. Using the questions in this module, the team sees that essays can contain health or family information and that the provider may store inputs. The team asks the data protection officer, who recommends a DPIA because the tool evaluates students and uses new technology on a large scale. Until the DPIA is complete, staff do not send student work to the tool, and the team trials it on sample texts written by staff.

Context 2: a corporate academy. An HR department plans to use an online proctoring service with camera monitoring for a certification exam taken by employees in several countries. The learning technology owner notes systematic monitoring, special sensitivity for video, and possible transfers outside the EEA. The department opens a DPIA, signs a data processing agreement with the provider and informs candidates in advance about what is recorded and how long it is kept.

Practice activity: Screen a proposed tool

Pick a tool your organisation uses or might use that handles credential data, for example a credential platform, an AI assistant or a proctoring service. Answer the eight AI questions above, adapted to the tool. List the controller and processor roles. Then tick any DPIA signs from the list that apply. Write one paragraph recommending whether to ask the data protection officer about a DPIA, and why.

Check your understanding

Assessment and badge

Knowledge check

The final knowledge check has 10 scenario-based questions. Each question has four options and exactly one correct answer. The questions cover all four learning outcomes. Read each scenario, choose the best answer and read the explanation that follows.

Rubric

Pass rule

Pass mark: 8 correct answers out of 10 (80 per cent). You may retry the knowledge check. Read the explanations and revisit the module that matches the outcome you missed before trying again.

Badge and evidence

On passing, you earn the badge "Data Protection Basics for Credential Issuers (Knowledge, L1)", alignment code ICSF-SECP-L1-K. The evidence submitted for the badge is the passed knowledge check. The badge states that you passed a knowledge check on these topics. It does not state that you are competent to carry out a job role.

Sources and further reading

Status as of November 2026; check before publishing. Confirm the current version of each text and any amendments before use.

• Regulation (EU) 2016/679, the General Data Protection Regulation (GDPR), published in the Official Journal of the European Union and available through EUR-Lex.
• European Data Protection Board (EDPB): guidelines and recommendations on topics such as consent, data subject rights, controllers and processors, data protection by design and by default, and data protection impact assessments. Available from the EDPB website.
• National data protection supervisory authorities: guidance and lists of processing operations that require a DPIA in your country. Find your authority through the EDPB website.
• European Commission: information on the EU data protection rules and on international data transfers, including adequacy decisions.
• ICoBC Credentialing Skills Framework (ICSF), skill SECP "Security, privacy and data protection". Available from ICoBC at info@icobc.net.
• Digital Omnibus: proposals concerning changes to EU digital and data rules. Follow official announcements of the European Commission, and check the current status before relying on any change.