# Choosing a Credential Platform Without Lock-in Vendor-neutral requirements, scoring and contracts. ## About this course **Course ID:** ICB-P09 **Framework alignment:** ICoBC Credentialing Skills Framework (ICSF), skill PLAT "Platforms and integration" (VRITE pillar: Trustworthiness), level L3 "Enable", stage A "Ability". At this level you select platforms against requirements, integrate them with learning, HR and student systems, and plan exit and data portability. This course lets you practise that capability on realistic cases in a controlled setting. ### Who this course is for - L&D and corporate academy leads - HR and learning technology owners - Programme and micro-credential leads - Education IT and credential operations staff **Prerequisite:** ICB-F01 Digital Badges and Credentials Essentials. You should know what a digital badge, an issuer, an earner and a verifier are. ### Learning outcomes After this course you can: 1. Translate programme needs into platform requirements. 2. Evaluate platforms with a weighted, vendor-neutral scorecard. 3. Specify data portability, exit and standards conformance in contracts. 4. Estimate total cost of ownership. ### Workload This is a workshop course with 6 hours of notional learning. This file covers the self-paced part. Live or workshop elements appear as facilitator notes inside each module. ### How you are assessed You produce a requirements set, a scorecard and a recommendation memo for a real or case organisation. A person assesses them with the rubric in "Assessment and badge". The final knowledge check in this file is for your own feedback and is graded automatically. It does not replace the assessed task. ### Badge Successful completion leads to the badge "Choosing a Credential Platform Without Lock-in (Ability, L3)", alignment code ICSF-PLAT-L3-A. The badge records that you completed an assessed practice task. It does not prove competency in any job. ### Where each outcome is taught and assessed | Outcome | Module | How it is assessed | |---|---|---| | 1. Translate programme needs into platform requirements | Requirements first | Requirements set in the final task; knowledge check questions | | 2. Evaluate platforms with a weighted, vendor-neutral scorecard | The scorecard | Scorecard in the final task; knowledge check questions | | 2. Evaluate platforms with a weighted, vendor-neutral scorecard | Standards and portability tests | Test evidence feeding the scorecard; knowledge check questions | | 3. Specify data portability, exit and standards conformance in contracts | Contracts and exit | Contract clause list in the memo; knowledge check questions | | 3. Specify data portability, exit and standards conformance in contracts | Standards and portability tests | Conformance and portability criteria in the requirements set | | 4. Estimate total cost of ownership | Costing | Cost comparison in the memo; knowledge check questions | ### The path through the course {{1}} From requirements to scorecard to decision A flow in five steps: requirements, scorecard, standards and portability tests, contract and exit terms, costing. The steps lead to a recommendation memo. A feedback arrow returns from the tests to the scorecard. From requirements to decision 1 Requirements first 2 Scorecard 3 Standards and portability 4 Contracts and exit 5 Costing Test results update the scores Decision memo --{{1}}-- The course follows the order in which a real selection runs: needs first, then scoring, then proof, then contract, then cost.
Facilitator notes Open the workshop by asking participants to name one platform decision they have lived through, without naming a vendor. Collect the pain points on a board. Return to this list at the end of Module 4 and ask which pain points a contract clause could have prevented. Ask participants to choose their case organisation now: a real one they know, or one of the two cases supplied in the modules (a corporate academy and a university). They use the same organisation in all five modules, so that the final task builds up step by step.
## Requirements first ### Why needs come before products Many platform selections start with a demonstration. A seller shows a polished interface, the team likes it, and the requirements are written afterwards to fit what was seen. The result is a list that favours one product and hides the needs the programme actually has. Start from the programme. A credential platform exists to support decisions: who may earn a badge, who checks the evidence, who sees the result and what the holder can do with it. Every requirement should trace back to one of these needs, or to a duty such as data protection or accessibility. Write requirements in three steps: 1. **Describe the programme.** Who earns credentials, how many, how often, from which learning activities, and who relies on them (employers, managers, admissions staff, other providers). 2. **Name the jobs the platform must do.** Typical jobs are: define credentials, collect and review evidence, issue, share, verify, revoke and reissue, report, and connect to other systems. 3. **State each need as a testable requirement.** A requirement must be something a person can check with a demonstration, a document or a test. ### Good and weak requirements A weak requirement says "The platform is easy to use." Nobody can fail it. A better requirement says "A programme administrator with no training can issue a badge to a cohort of 200 earners from a spreadsheet in under 30 minutes, using the written guide." You can run that test. Each requirement needs: - **An identifier**, such as R-12, so that the scorecard can refer to it. - **A statement**, in one sentence, in plain language. - **A source**, such as the programme lead, the data protection officer or the earners. - **A priority**: *must* (the platform fails without it), *should* (important, with a workaround) or *could* (a bonus). - **A test**: how you will check it. ### Requirement families Group requirements into families so that nothing is missed: - **Credential model:** badge types, stacking, expiry, evidence, endorsement. - **Issuing and verification:** bulk issue, revocation, public verification page, status checks. - **Integration:** learning platform, HR system, student records, single sign-on, programming interfaces. - **Standards and portability:** the specifications supported, export of all data, wallet and backpack sharing. - **Trust and governance:** security, privacy, accessibility, audit logs, roles, AI features. - **Operations:** support, uptime commitments, languages, reporting. - **Commercial:** pricing model, term, exit. ### Stakeholder interviews and the integration map Requirements come from people. Talk to programme leads, administrators, earners, IT, data protection staff and the people who will verify credentials. Ask about the last time something went wrong, because failures reveal needs that nobody lists in a workshop. Also draw an integration map: the systems around the platform, the data that moves between them and the direction of each flow. A badge platform that cannot receive course completions from the learning system, or send verified skills to the HR system, creates manual work for years. Integration map around a credential platform A navy circle in the centre labelled credential platform. Four boxes connect to it: learning system, HR system, student records system and earner wallet or profile. Arrows show data flowing in from learning and student records and out to HR and the earner. Credential platform Learning system completions, grades Student records enrolment, identity HR system skills, careers Earner wallet or profile in in out out **Worked example: A corporate academy writes its requirements** *All numbers are illustrative.* A corporate academy at a mid-sized manufacturer wants to issue badges for internal safety and leadership programmes. The academy lead, Mira, interviews the safety manager, two team leaders, the HR learning technology owner and the data protection officer. The safety manager says an expired forklift licence badge must disappear from the manager's dashboard on the expiry date. Mira writes: - **R-04 (must):** The platform supports an expiry date per badge and shows expired badges as expired on the public verification page. *Test:* issue a test badge with an expiry date set to tomorrow and check the page the day after. - **R-11 (must):** The platform receives course completions from the learning system without manual upload. *Test:* complete a test course and check that the badge is issued within one hour. - **R-17 (should):** The platform sends earned badges to the HR system as skill records. *Test:* demonstration with test data. - **R-23 (must):** The data protection officer can export and delete one person's data on request within the time set by the company policy. *Test:* run both actions on a test record. Mira marks each requirement with its source and keeps a short rationale. When a manager later asks "why must we have R-23?", the answer is written down. **Worked example: A university lists its requirements for micro-credentials** *All numbers are illustrative.* A university continuing education unit offers short courses to about 3,000 learners a year. The programme lead, Tomás, works with student records, the registrar, the accessibility officer and two academics. The registrar needs a badge to be linked to the learner's student number without exposing it publicly. Tomás writes: - **R-02 (must):** Earners sign in with the university single sign-on and the platform stores a pseudonymous identifier, not the student number, on the public badge. *Test:* issue to a test account and inspect the public page. - **R-09 (must):** Credentials describe the level, workload and assessment method in a structured field. *Test:* inspect an issued test credential. - **R-14 (must):** All earner-facing pages meet the accessibility standard named in university policy. *Test:* evidence from the supplier plus a check by the accessibility officer. - **R-20 (should):** Credentials can be shared to external wallets and professional networks. *Test:* share a test badge to two external services. **Practice activity: Write ten testable requirements** Choose your case organisation: the corporate academy above, the university above, or a real organisation you know well. 1. Write a three-sentence programme description: who earns, how many, who relies on the credentials. 2. Draw a simple integration map with at least three connected systems. 3. Write ten requirements in the format identifier, statement, source, priority and test. Cover at least five of the seven requirement families. 4. Mark at least three as *must* and at least two as *should*. 5. Swap with a partner. Each partner picks two requirements and tries to find a way a platform could "pass" without meeting the real need. Rewrite those requirements until they close the loophole. Keep your requirements: they form part of your final assessed task.
Facilitator notes Time: 60 minutes of live activity. Run the loophole exercise as a pair game: one person plays a sales representative who tries to claim compliance with the weakest reading. Ask participants to note which requirement wordings invite this. Collect three of the weakest original requirements anonymously and rewrite them together on screen. Remind participants that the requirements set is part of the badge evidence, so they should save it in an editable format.
### Check your understanding **Question 1.** Which statement is a testable requirement? [( )] The platform should be modern and user friendly. [(X)] An administrator can revoke a badge and the public verification page shows the revoked status within one hour. [( )] The platform should have good support. [( )] The platform must be popular with other organisations. [[?]] Look for a requirement that a person could check with a demonstration or a document. **** The correct option names an action, an actor and a measurable result, so a team can test it. The other options are opinions or vague wishes that nobody can fail. **** **Question 2.** Why do you record a source for each requirement? [( )] To make the list longer. [( )] Because suppliers ask for it. [(X)] So you can explain why the requirement exists and settle disputes about its priority. [( )] So that you can copy the list to another organisation without changes. [[?]] Think about the question "why must we have this?" six months later. **** A recorded source links each requirement to a need or duty. It makes priorities defensible and shows who to ask when something changes. **** **Question 3.** A requirement is marked *must*. What does that mean? [( )] The requirement is more interesting than the others. [( )] The requirement will receive the highest weight in cost calculations. [(X)] The platform fails the selection if it cannot meet the requirement. [( )] The requirement should be tested last. [[?]] Consider what happens when a platform does not meet it. **** A *must* is a gate: if a platform cannot meet it, the platform is out, whatever its score elsewhere. *Should* and *could* requirements influence the score but do not exclude a platform on their own. **** **Question 4.** What is the main purpose of an integration map? [( )] To show the platform's colour scheme. [(X)] To show which systems exchange which data, in which direction, so that integration needs become requirements. [( )] To decide the badge design. [( )] To list the people who will attend the training. [[?]] It is about systems and data flows. **** An integration map exposes data flows that otherwise stay hidden until after purchase. Each flow becomes one or more testable requirements. **** ## The scorecard ### Why a weighted scorecard A scorecard turns many opinions into one comparable result. It forces the team to say what matters most before they see prices or demonstrations. A weighted, vendor-neutral scorecard also leaves a record: you can show a board, an auditor or a bidder how the decision was reached. A scorecard has four parts: 1. **Gate criteria.** The *must* requirements. A platform that fails a gate is not scored further. 2. **Weighted criteria.** The *should* and *could* requirements, grouped into families, each with a weight. 3. **A scoring scale** with written definitions for each level. 4. **Evidence for each score**, so that two people reading the same evidence give the same score. ### Weights Weights show relative importance. A simple method: give 100 points to share across the families, then split each family's points among its criteria. The team agrees the weights **before** any demonstration or price is seen. Changing weights after seeing the results is a common way of producing the answer someone already wanted. Typical families for a credential platform are credential model, issuing and verification, integration, standards and portability, trust and governance, operations and cost. The weights depend on the organisation. A university with strict accessibility duties may weight governance higher. An academy with a complex HR landscape may weight integration higher. ### The scoring scale Use a short scale with written anchors, for example: | Score | Meaning | |---|---| | 0 | Not met, or no evidence | | 1 | Partly met, with a significant workaround | | 2 | Met, shown in a demonstration or document | | 3 | Met and tested by you with your own data | The anchors make the difference between "the seller said so" and "we saw it work". Never award a 3 on a seller's statement alone. ### Weighted total and sensitivity The weighted score for a family is the score divided by the maximum, multiplied by the family weight. Add the families to get a total out of 100. Then run a **sensitivity check**: change the weights a little, or change two uncertain scores, and see whether the ranking changes. If the first and second platform swap places after a small change, the scorecard cannot separate them, and the decision should rest on risk, exit terms and cost instead. A scorecard that shows a clear gap under several weightings gives a stronger recommendation. ### Keeping the scorecard vendor-neutral Vendor-neutral means that the criteria describe needs, not features of one product. "Supports bulk issue from a file with at least 500 rows" is neutral. "Has the issuing wizard" is not. Check each criterion with the question: could two quite different products both meet this need in different ways? If not, the criterion probably copies one product. Also use the same questions, the same data and the same scorers for every candidate. Record who scored what, and ask scorers to declare any contact with a supplier that could create bias. Scorecard structure A funnel in three stages. Gate criteria remove platforms that fail a must requirement. Weighted criteria produce a score out of 100. A sensitivity check tests whether the ranking holds. The output is a ranked shortlist. Three stages of a scorecard Stage 1: gate criteria (must requirements) Fail one gate and the platform is out Stage 2: weighted criteria Scores 0 to 3 with evidence, total out of 100 Stage 3: sensitivity check Does the ranking hold? Output: ranked shortlist with evidence **Worked example: A corporate academy builds and runs its scorecard** *All numbers are illustrative.* Mira's academy shares 100 points: credential model 15, issuing and verification 15, integration 25, standards and portability 20, trust and governance 15, operations 10. Cost is handled separately in Module 5. Three candidate platforms, A, B and C, are tested. All pass the gates. In the integration family, which has four criteria worth 6 points each (rounded for the example), platform A scores 3, 2, 2 and 3. Its integration result is (3+2+2+3) / 12 × 25 = 20.8 points. Platform B scores 2, 2, 1 and 1, giving 12.5 points. Across all families the totals are A 78, B 71, C 74. The sensitivity check raises integration to 30 points and lowers operations to 5. The totals become A 81, B 69, C 73. A stays first, so Mira can say the lead is stable under that change. She also notes that C is only 4 points behind and that C's score for portability rests on seller statements, not tests. She marks it for further testing. **Worked example: A university scores with a panel** *All numbers are illustrative.* Tomás forms a panel of four: the programme lead, a student records analyst, the accessibility officer and an academic. They agree weights in a first meeting, before any demonstration. Governance receives 25 points because of accessibility and privacy duties. Each panellist scores alone, in writing, then the panel meets. Where two scores differ by 2 or more points, the panel asks for the evidence. In one case, one scorer gave an accessibility criterion 3 because of a supplier statement, and another gave 1 because of a failed check. The panel records the failed check as the evidence and sets the score to 1. The panel keeps the minutes with the scorecard. **Practice activity: Build and test a scorecard** Use your requirements from Module 1. 1. Mark your gate criteria (*must* requirements). 2. Group the remaining requirements into families and distribute 100 points. Write one sentence per family explaining its weight. 3. Define your 0 to 3 scale with your own anchors for two of your criteria. 4. Score two imaginary platforms using the figures your facilitator provides, or invent plausible illustrative scores. Compute weighted totals. 5. Run a sensitivity check: move at least 10 points of weight from one family to another. Does the ranking change? Write two sentences on what this tells you. 6. Review each criterion with the question "could two different products meet this need?" Rewrite any criterion that describes one product's feature.
Facilitator notes Time: 75 minutes. Provide a pre-built spreadsheet template with formulas hidden if time is short, but ask participants to compute one total by hand so that they understand the arithmetic. Divide the room into two bidding teams and one evaluation team for a short role play: the bidding teams describe an imaginary platform, and the evaluators must award only the score the evidence supports. Discuss how it felt to refuse a 3 without a test.
### Check your understanding **Question 1.** When should the team agree the weights? [( )] After the demonstrations, so they reflect what was seen. [( )] After the prices arrive. [(X)] Before any demonstration or price is seen. [( )] Only if two platforms tie. [[?]] Think about how to prevent the weights being bent towards a favourite. **** Agreeing weights early protects the decision from bias towards a platform that has already made a good impression. Changing weights afterwards is a common way to reach a decision that was already preferred. **** **Question 2.** A supplier says its platform supports an integration but you have not seen it. Using the 0 to 3 scale in this course, what is the highest score you can give? [( )] 3, because the supplier is responsible for the statement. [( )] 2, because a statement counts as a demonstration. [(X)] 1 or lower, until the capability is shown in a demonstration, a document or a test. [( )] 3, if the supplier signs the statement. [[?]] Look at the anchors: a 2 needs a demonstration or document. **** A score of 2 requires a demonstration or a document, and a 3 requires your own test. A statement without evidence supports at most a low score. **** **Question 3.** What does a sensitivity check show? [( )] How fast the platform runs. [( )] How many users the platform supports. [(X)] Whether the ranking of platforms stays the same when weights or uncertain scores change a little. [( )] Which supplier has the largest market share. [[?]] It tests the stability of the result. **** A sensitivity check tells you how much confidence to place in the ranking. If a small change reverses the order, other factors such as risk, exit terms and cost should decide. **** **Question 4.** Which criterion is vendor-neutral? [( )] The platform has the "bulk wizard" feature. [( )] The platform uses the supplier's own badge format. [(X)] An administrator can issue badges to at least 500 earners from a file in one operation. [( )] The platform comes with the supplier's recommended workflow. [[?]] A neutral criterion describes a need that different products could meet in different ways. **** The correct option states a capability and a threshold, not a product feature name. Different products could meet it in different ways, and a test can check it. **** ## Standards and portability tests ### Why standards matter for lock-in Lock-in means that leaving a platform costs so much, in money, time or lost data, that you stay even when the platform no longer fits. Standards reduce lock-in because they define how credentials and their data are structured, so another system can read them. They do not remove the risk. A platform may claim support for a standard while storing key data in a private format. Two current specification families matter for this course. **Open Badges 3.0 and CLR 2.0** *[Established]*. These are current specifications for describing badges and richer learner records. Platform support is still uneven. Check conformance certification of tools instead of relying on a statement that a platform is "compatible". **W3C Verifiable Credentials Data Model 2.0** *[Established]*. This is a W3C Recommendation since 2025. Related specifications for status lists and securing mechanisms continue to evolve, so ask suppliers which versions and mechanisms they implement and what their update plans are. Status: November 2026. ### Claims, certification and your own tests A supplier statement about standards has three possible levels of proof: 1. **A claim.** "We support the standard." Weakest. 2. **A certification or conformance result** from the standards body or a recognised test suite, for a named product and version. Stronger. Check the scope: a certification may cover issuing but not importing, or one version but not the current one. 3. **Your own test.** You issue a credential from the platform, validate it with an independent verifier, and import a credential made elsewhere. Strongest. ### The portability tests Run these tests during the selection, using a trial or sandbox account and test data. Do not use real earner data in a trial unless the contract and a data processing agreement permit it. 1. **Export test.** Export all credentials, earner records, evidence and issuing history in a bulk export. Check that the export is complete, readable without the supplier's software, and uses open formats. 2. **Independent verification test.** Take an issued credential and check it with a verifier you do not control, such as a public validator. Does it pass? Does a revoked credential show as revoked? 3. **Import test.** Import credentials issued by another system. Do they keep their identifiers, issuer information and dates? 4. **Identifier test.** Look at the credential identifiers and the issuer identity. Are they under your control, for example on your domain, or controlled by the supplier? Identifiers that depend on the supplier's domain can break when you leave. 5. **Sharing test.** Share a credential to an external wallet or profile. Does the recipient see the same information? 6. **Interface test.** Use the documented interface to read and write credentials. Is it documented, versioned and available at no extra licence cost? Lock-in risk map A grid with two axes. The horizontal axis shows how hard it is to move away, from easy to hard. The vertical axis shows how much data and credential identity is controlled by the supplier, from low to high. Four zones are labelled: low risk, check identifiers, check exports and high risk. Lock-in risk map Check identifiers Easy to move, supplier-held IDs High risk Hard to move, supplier-held data Low risk Easy to move, you hold the data Check exports Hard to move, you hold the data Easy to move away Hard to move away Supplier controls You control ### Reading the AI features Many platforms now offer AI features, such as suggested skill tags, generated badge descriptions, automated evidence checking or matching earners to jobs. Assess each AI feature against your own AI rules. Ask the supplier: - Which parts of the process does the feature touch: description, evidence review, decisions about earners? - Can you switch it off, per feature and per programme? - Is a person responsible for any decision that affects an earner, and can they see and override the AI output? - Are earner data or evidence used to train models, by the supplier or by third parties? Can you refuse this? - Is AI-generated content marked as such? - Where is data processed and which sub-processors are involved? Write your own AI rules before the selection, even if they are short. A feature that conflicts with your rules is a gate failure, however attractive it looks. **Worked example: A corporate academy tests portability and an AI feature** *All numbers are illustrative.* Mira's HR learning technology owner, Daniel, requests a sandbox from the two leading platforms. He issues 20 test credentials from each, runs a bulk export and checks it. Platform A exports credentials in an open format with evidence files and the issuance log. Daniel validates three of the exported credentials with an independent validator, and all three pass. Platform B exports a spreadsheet with credential names and dates but without the structured credential data. B receives a 1 on the export criterion and a note that a full export "can be requested from support, charged by the hour". Daniel then checks AI features. Platform A proposes AI-written badge descriptions. The academy's AI rule says that any AI-generated text must be reviewed by a person before publication and that earner evidence must not be used for model training. Platform A allows switching the feature off and a review step, and its terms exclude earner data from training. Platform B's terms are silent on training use. Daniel marks this as an open question and a possible gate failure. **Worked example: A university checks conformance and identifiers** *All numbers are illustrative.* Tomás's panel asks each supplier for conformance evidence. One supplier supplies a certification entry naming the product version. Another supplies a general statement. The panel scores the first 2 and the second 1. The student records analyst, Amara, examines the identifiers in the test credentials. In one platform, the issuer identity and credential identifiers sit on the supplier's domain. If the university leaves, old credentials would point to a domain it does not control. In another platform, the university can use its own domain. Amara records this as a high-weight portability criterion and gives the first platform a 0 on it. **Practice activity: Design a portability test plan** For your case organisation: 1. List the six portability tests from this module and write, for each, the exact steps you would run in a sandbox and the evidence you would keep (screenshot, file, log). 2. Add two tests specific to your organisation, for example an integration with your learning system or a language requirement. 3. Write five questions about AI features that match the AI rules you would apply. Write a one-sentence AI rule for each question. 4. Define pass and fail for each test, so that two testers would reach the same result. 5. Decide which tests are gates and which feed the weighted score.
Facilitator notes Time: 60 minutes. If a sandbox or public validator is available, run a live demonstration: issue a test credential, open it in an independent validator, then revoke it and check again. If no sandbox is available, use screenshots or sample files provided by the facilitator. Ask participants to share one test they think suppliers will find uncomfortable. Discuss how to ask for it politely and in writing, and what it means if a supplier refuses a sandbox test.
### Check your understanding **Question 1.** Which level of proof of standards support is the strongest? [( )] A statement in a sales presentation. [( )] A logo on the supplier's website. [(X)] Your own test, using an independent verifier and data you created. [( )] A reference from another customer without details. [[?]] Consider who controls the test. **** Your own test, with an independent verifier, shows what the platform actually does. Claims and logos are weaker evidence, and certifications are stronger than claims but have limited scope. **** **Question 2.** Why does it matter who controls credential identifiers and the issuer identity? [( )] It affects the colour of the badge. [( )] It decides how many earners you can have. [(X)] If the supplier controls them, previously issued credentials may stop resolving or verifying when you leave. [( )] It determines the price of the licence. [[?]] Think about what happens to old credentials after exit. **** Identifiers that depend on a supplier's domain can break when the contract ends. Controlling the identifier space is a key part of avoiding lock-in. **** **Question 3.** A platform supports an AI feature that reviews evidence and recommends pass or fail. What is the best first step under a sensible AI rule? [( )] Switch it on for all programmes to save time. [( )] Ignore it, because AI is not part of platform selection. [(X)] Check against your AI rules whether it can be switched off, whether a person decides, and whether earner evidence is used for model training. [( )] Ask the supplier to describe it more attractively. [[?]] Start with your rules, not with the feature. **** AI features need an explicit assessment against your own rules: human responsibility, control over activation, training use of earner data and transparency. A feature that conflicts with your rules can be a gate failure. **** **Question 4.** What should an export test check? [( )] That the export arrives within one second. [( )] That the export file has a nice layout. [(X)] That all credentials, earner records, evidence and history leave in an open, readable format that works without the supplier's software. [( )] That the export contains only the names of earners. [[?]] An export is only useful if you can really use it elsewhere. **** A portability test is complete when the export holds the full data set in open formats and a person or another system can read it without the supplier. A partial or proprietary export leaves you dependent on the supplier. **** ## Contracts and exit ### Contracts are part of the product A platform can score well and still lock you in through its contract. Portability promises made in a demonstration have no force unless they are in the agreement. Exit terms are written while you still have negotiating power, before signature, because after signature the supplier knows that switching is costly. Involve procurement, legal staff and the data protection officer early. This course does not give legal advice and it does not replace review by qualified legal staff. Clause wording must fit your jurisdiction and your policies. ### Clause areas to specify **1. Data ownership and use.** The contract states that the customer owns its credential data, earner data and evidence. It limits supplier use of the data to providing the service. It excludes use for model training or marketing unless the customer agrees in writing. **2. Data portability.** The contract lists what can be exported (credentials, earner records, evidence files, issuing history, revocation lists, configuration), in which open formats, how often, at what cost and within what time. Self-service export at no extra charge during the term is a sensible requirement. **3. Standards conformance.** The contract names the specifications and versions the platform must support, requires the supplier to maintain conformance as versions change and states remedies if it falls out of conformance. Reference the certification or test results shown in the selection. **4. Identifiers and domains.** The contract states who controls the issuer identity and credential identifiers, and requires continued resolution or a migration path after the term ends. **5. Exit and transition.** The contract defines an exit period, the help the supplier must provide, a full export at the end, a defined point at which the supplier deletes data and a certificate of deletion. It states what happens to the public verification service for previously issued credentials. **6. Service levels and change.** The contract defines availability, support response, notice of changes to features, interfaces or pricing and the right to leave without penalty after a major unwelcome change. **7. Security, privacy and sub-processors.** The contract names security measures, breach notification times, data locations and sub-processors, and requires notice of changes. **8. AI features.** The contract lists AI features in scope, states that they can be switched off, ensures that people remain responsible for decisions about earners and states rules on training use of customer data. **9. Price protection.** The contract fixes prices or caps increases for the term and states what happens to charges for volumes above and below the plan. ### The exit plan An exit plan is a short document, written at the start, not at the end. It answers: - Which data and files must be exported, and who runs the export? - Which formats and where are they stored? - How do earners keep access to their credentials? - Which verifications must keep working, and for how long? - How do integrations switch to the new platform? - What is the timeline and who decides? Exit timeline A horizontal timeline in five steps: decide to leave, notice period, full export and checks, parallel run with the new platform, deletion and certificate. The contract clause areas that support each step are labelled below. Exit timeline 1 Decide 2 Give notice 3 Export and check 4 Parallel run 5 Delete Notice period clause Portability clause Standards clause Identifier clause Transition help Deletion clause Write the exit plan at the start of the contract, test the export once a year **Worked example: A corporate academy turns tests into clauses** *All numbers are illustrative.* Daniel's sandbox tests showed that platform B exports only a spreadsheet. The academy wants platform B's integration strengths, so it negotiates instead of rejecting it. Mira and procurement draft these requests: - The supplier provides a self-service bulk export of credentials, evidence and issuing history in open formats at no extra charge during the term. - The academy owns all credential and earner data. The supplier may not use it to train models. - For 12 months after the contract ends, the supplier keeps the public verification pages for issued credentials online, or migrates them to a location named by the academy. - On notice, the supplier completes a final export within 30 days and certifies deletion within 60 days. Procurement and legal staff review the wording. If the supplier refuses the export and verification clauses, Mira records this on the scorecard as a major risk and informs the board. **Worked example: A university writes an exit plan** *All numbers are illustrative.* Tomás and the registrar write a one-page exit plan before signing. It states that the credential identifiers are on a university domain, that a full export is tested every year in a test run with 100 sample credentials and that the university will keep a copy of the public keys or equivalent verification material needed to check old credentials. The plan names who runs the export (the credential operations analyst, Amara), where the export is stored (a university archive) and how earners are informed (a message and a help page). It adds a rule: earners can download their own credentials at any time during the term, so they never depend only on the platform. **Practice activity: Draft clauses and an exit plan** For your case organisation: 1. Choose five of the nine clause areas. For each, write a one or two sentence clause request in plain language. Link each to a test or a requirement ID. 2. Write a one-page exit plan using the six questions in this module. 3. Identify two clauses where you expect resistance. Write a fallback position for each (for example, an export fee cap instead of a free export) and the minimum you would accept. 4. Mark which clauses are non-negotiable and what you would do if the supplier refuses. 5. Exchange with a partner. The partner acts as the supplier's account manager and objects to two clauses. Practise a calm reply that explains the risk the clause addresses.
Facilitator notes Time: 60 minutes. Invite a procurement or legal colleague as a guest if possible. State clearly that participants are drafting requests for review by qualified staff, not final legal text. In the role play, ask observers to note whether the reply stays focused on the risk instead of the supplier's behaviour. Close by returning to the pain points collected in the first module and mapping each to a clause.
### Check your understanding **Question 1.** Why must portability promises be written into the contract? [( )] Because contracts must be long. [( )] Because suppliers prefer longer contracts. [(X)] Because statements made in a demonstration have no force unless the agreement contains them. [( )] Because earners ask to read the contract. [[?]] Think about what you can rely on when something goes wrong. **** Only what is in the agreement can be enforced. Demonstration statements and sales materials can change or be disowned, so key portability and exit terms need to be written down. **** **Question 2.** When is the best time to negotiate exit terms? [( )] After the first renewal. [( )] When you decide to leave. [(X)] Before signing, while you can still choose another supplier. [( )] After the first export fails. [[?]] Consider when your bargaining position is strongest. **** Before signature you can still walk away, which gives you leverage. After signature, switching is costly and the supplier knows it. **** **Question 3.** Which clause best protects earners who hold credentials issued before you leave the platform? [( )] A clause on the colour of the badge. [( )] A clause about training for administrators. [(X)] A clause that keeps public verification working for a defined period or migrates it, and gives the customer control of identifiers. [( )] A clause about the supplier's marketing. [[?]] The earners care that their credentials still verify. **** Verification and identifier clauses keep credentials working after exit. Without them, earners could find that their credentials no longer resolve or verify. **** **Question 4.** What is the purpose of an annual test export? [( )] To collect more data for the supplier. [(X)] To check that the export still works and is usable, before you need it in an emergency. [( )] To replace the contract. [( )] To reduce the licence price automatically. [[?]] Plans decay if nobody tests them. **** Export formats, interfaces and your own staff knowledge change over time. A regular test shows that the exit route still works before it is needed. **** ## Costing ### Total cost of ownership The licence price is only one part of cost. Total cost of ownership (TCO) is the full cost of running the platform over a chosen period, usually three to five years, including exit. Comparing licence prices alone favours platforms with low entry fees and high extras. ### Cost categories **One-off costs** - Selection effort: staff time for requirements, scoring and tests. - Implementation: configuration, design of credential templates, data migration. - Integration: building and testing connections to learning, HR and student systems. - Training: administrators, issuers and support staff. - Legal and procurement review. **Recurring costs** - Licence or subscription, including volume tiers and extra modules. - Support and hosting options. - Interface usage or per-call charges. - Staff time for operations: issuing, support requests, reporting, updates. - Maintenance of integrations when connected systems change. - Compliance work: privacy reviews, accessibility checks, audits. **Exit and risk costs** - Final export, data cleaning and migration to the next platform. - Parallel running during the transition. - Re-issuing credentials where identifiers cannot be kept. - Reputation or trust costs if credentials stop verifying. Write down which costs are known, which are estimated and which are guesses. Show ranges, not single figures, for uncertain items. ### Building the estimate 1. Choose a period, for example five years. 2. Project volumes: earners, credentials issued and administrator numbers per year, with a low, expected and high case. 3. Ask each supplier for a full price sheet, including tiers, extras and increase caps, using the same volume scenarios. 4. Estimate internal staff time using realistic hourly cost, including overheads, set by your finance department. 5. Add exit costs. Platforms with poor portability have higher exit costs, which is the point. 6. Compute the cumulative cost per year and the average cost per credential issued. 7. Test sensitivity: what if volumes double, or prices rise at the contract cap? Cost can enter the decision in two ways. Either treat it as a gate (a budget ceiling) and a separate comparison, or give it a weight in the scorecard. Whichever you choose, state the rule before you see the prices. Total cost of ownership layers A stacked bar for one platform over five years with four labelled layers: licence, integration and implementation, staff operations, and exit costs. A note says the sizes are illustrative and only the order of the layers matters. Layers of total cost of ownership Exit and migration costs Staff time for operations and support Implementation and integration Licence and subscription Layer sizes are illustrative **Worked example: A corporate academy compares five-year cost** *All numbers are illustrative.* Mira compares platforms A and B over five years with an expected volume of 4,000 credentials a year. Amounts are in euros. | Item (five years) | Platform A | Platform B | |---|---|---| | Licence and subscription | 90,000 | 60,000 | | Implementation and integration | 25,000 | 45,000 | | Staff time for operations | 40,000 | 55,000 | | Training | 5,000 | 8,000 | | Exit and migration (estimate) | 10,000 | 35,000 | | **Total** | **170,000** | **203,000** | Platform B's licence is lower, but its integration, staff time and exit costs are higher. Mira shows the exit estimate as a range: platform B 20,000 to 50,000, because the export is partial and re-issuing might be needed. She adds a sensitivity case where volumes double. Platform A's licence rises by a tier, B's does not, and A's total becomes 190,000 against B's 207,000. The ordering holds, so she includes both cases in her memo. **Worked example: A university costs a pilot and a scale-up** *All numbers are illustrative.* Tomás plans a pilot of 800 credentials in year one and growth to 3,000 in year three. He asks suppliers to price both scenarios and the price protection cap. One supplier has a low entry price but a steep tier at 2,000 credentials. At year three, its cost per credential is higher than that of a supplier with a flat tier. Tomás also includes the accessibility officer's time for reviewing earner pages (a recurring cost) and Amara's time for the annual export test. He presents the results as cost per credential issued per year, so the board can compare the pilot and scale-up stages on the same basis. He notes that his estimate for staff time is uncertain and shows it as a range. **Practice activity: Build a five-year TCO comparison** For your case organisation: 1. Choose a period (three or five years) and write low, expected and high volume projections. 2. Create a cost table with at least the categories in this module. Use illustrative figures for two imaginary platforms, and label them as illustrative. 3. Mark each figure as known, estimated or guess. Give ranges for at least three uncertain figures. 4. Calculate the total and the cost per credential issued for the expected case. 5. Run two sensitivity cases: volumes double, and price rises at the contract cap. 6. Write three sentences for the memo: which platform is cheaper over the period, how stable the result is, and which cost item carries the most uncertainty.
Facilitator notes Time: 60 minutes. Provide a blank cost template, and let participants use illustrative figures if they have no real prices. Encourage them to include their own staff hours, because these are often forgotten. Run a short discussion: which cost line would a purchasing committee most likely ignore, and how would you make it visible? Link the answer to the exit costs of platforms with poor portability.
### Check your understanding **Question 1.** Which description best fits total cost of ownership? [( )] The licence price in the first year. [( )] The price on the supplier's website. [(X)] The full cost of running the platform over a chosen period, including implementation, integration, staff time and exit. [( )] The cost of training only. [[?]] It covers more than money paid to the supplier. **** TCO includes one-off, recurring and exit costs, including internal staff time. Looking only at the licence misses the larger part of cost for many platforms. **** **Question 2.** Why do exit costs belong in the estimate from the start? [( )] Because most organisations leave after one year. [( )] Because suppliers ask for them. [(X)] Because platforms with poor portability have higher exit costs, which affects the real comparison and shows lock-in risk in money terms. [( )] Because exit costs are always zero. [[?]] They connect Module 3 and Module 4 to the cost. **** Including exit costs makes the price of lock-in visible. A platform with a cheaper licence but a costly or partial exit may cost more overall. **** **Question 3.** What should you do with uncertain cost items? [( )] Leave them out. [( )] Round them down. [(X)] Show them as ranges and label them as estimates or guesses. [( )] Ask the supplier to choose a figure. [[?]] Honesty about uncertainty makes the decision stronger. **** Ranges and labels let decision makers see how firm the estimate is. Hiding uncertainty can lead to a decision that fails when real costs appear. **** **Question 4.** What is the purpose of a volume sensitivity case? [( )] To confirm the supplier's price list. [(X)] To see whether the ranking of platforms changes if the number of credentials is higher or lower than expected. [( )] To reduce the number of requirements. [( )] To select the badge design. [[?]] Pricing tiers often change the picture at higher volume. **** Tiers and per-credential charges mean the cheaper platform at one volume can become more expensive at another. A sensitivity case shows how robust the cost comparison is. **** ## Assessment and badge ### The assessed task You produce three documents for a real or case organisation. A person assesses them with the rubric below. This file does not grade them. **Choose your organisation.** Use a real organisation you know, or one of the two cases from the modules (the corporate academy or the university). If you use a real organisation, remove or change confidential details and do not include personal data. **Deliverables** 1. **Requirements set.** At least 20 requirements with identifier, statement, source, priority and test. Include an integration map and at least one requirement each on standards conformance, portability, AI features and exit. 2. **Scorecard.** Gate criteria, weighted criteria with weights that sum to 100 and a stated reason for each family weight, a scoring scale with anchors, scores for at least three candidate platforms (real or illustrative, described without vendor names), evidence notes, a weighted total and a sensitivity check. Include your portability test plan and the results, real or illustrative. 3. **Recommendation memo.** Maximum two pages. It states the decision, the reasons, the main risks, the contract clauses you will require (at least five, including data export, standards conformance, identifiers and exit), the exit plan summary and a five-year TCO comparison with ranges and a sensitivity case. **Rules** - Platforms are described by their capabilities and labelled, for example Platform A, B and C, in line with vendor-neutral practice. - Mark invented figures as illustrative. - Do not include personal data of earners or staff. - Do not claim legal accuracy for clauses. Mark the clause list for review by qualified staff. ### Rubric The assessor rates each criterion as Not yet, Meets or Strong. | Criterion | Not yet | Meets | Strong | |---|---|---|---| | 1. Requirements (Outcome 1) | Few or vague requirements, no tests, no link to programme needs | At least 20 testable requirements with source, priority and test; integration map included | Requirements are traceable to stakeholder needs and duties, loopholes are closed, and the set is balanced across families | | 2. Scorecard design (Outcome 2) | Weights missing or set after scoring, criteria copy a product, no evidence | Gates, weights summing to 100 with reasons, scale with anchors, evidence notes, weighted totals correct | Criteria are neutral and tested, scoring evidence is traceable, and a sensitivity check is analysed with clear conclusions | | 3. Standards and portability testing (Outcomes 2 and 3) | No tests or only claims accepted as evidence | Six portability tests planned with pass and fail, results recorded, AI features checked against stated AI rules | Tests are specific to the organisation, identifier control is examined, and findings drive scores and contract demands | | 4. Contracts and exit (Outcome 3) | Clauses missing or generic, no exit plan | At least five clear clauses covering export, conformance, identifiers and exit, plus an exit plan summary, marked for legal review | Clauses link to tests and risks, fallback positions are stated, and the exit plan names roles, timeline and verification continuity | | 5. Costing (Outcome 4) | Licence price only | Five-year TCO with one-off, recurring and exit costs, ranges for uncertain items and one sensitivity case | Cost items are labelled known, estimated or guess, two or more sensitivity cases are analysed, and exit cost is linked to portability findings | | 6. Recommendation memo | No clear decision or reasons, or longer than two pages | Clear recommendation with reasons, risks, clauses and cost in two pages | Persuasive, balanced and honest about uncertainty, with next steps and an explicit statement of what would change the recommendation | | 7. Vendor neutrality and integrity | Names or favours a commercial product, invents unmarked figures or includes personal data | Neutral language, invented figures labelled as illustrative, no personal data | Consistently neutral, declares assumptions and any conflicts of interest, and states limits of the evidence | ### Pass rule To earn the badge, the assessor must rate **Meets or Strong on all seven criteria**, and **Strong on at least two**. A criterion rated Not yet can be revised once and resubmitted within the period set by the programme. The assessor gives written feedback on each criterion. ### Badge evidence Submit for the badge: 1. The requirements set. 2. The scorecard, including the portability test plan and results. 3. The recommendation memo, including the clause list, exit plan summary and TCO comparison. The badge "Choosing a Credential Platform Without Lock-in (Ability, L3)", alignment code ICSF-PLAT-L3-A, records that the earner completed an assessed practice task against the rubric. It does not prove competency in any job.
Facilitator notes Assessment: assign two assessors for a sample of submissions to check consistency. Share the rubric with participants at the start of the workshop and ask them to self-assess one criterion in a short peer review session before submission. Allow time at the end of the live workshop for a 10-minute "red team" review: each participant presents one weak point of their own recommendation and the group suggests how to test or reduce it.
### Final knowledge check This check gives you feedback on the knowledge behind the task. It is not the assessed task and does not decide the badge. **Question 1.** A team writes the requirement "The platform integrates well with our systems." What is the best improvement? [( )] Add the word "seamlessly". [( )] Move it to the end of the list. [(X)] Name the systems, the data that moves, the direction and a test, for example "Course completions from the learning system issue a badge within one hour, tested with a sample course." [( )] Delete it, because integration is hard to specify. [[?]] Make it something a person could pass or fail. **** A good requirement is specific and testable. Naming the systems, data, direction and a test turns a wish into a criterion (Outcome 1). **** **Question 2.** Which method best translates programme needs into requirements? [( )] Copying the feature list of the most popular platform. [(X)] Describing the programme, interviewing stakeholders, mapping integrations and writing testable requirements with source and priority. [( )] Asking suppliers to write the requirements for you. [( )] Using the requirements from another organisation without changes. [[?]] Start from needs and duties, not from products. **** Requirements should come from the programme, the people involved and legal duties, and each should be testable (Outcome 1). Copying or outsourcing the list builds in someone else's needs. **** **Question 3.** When should scorecard weights be set, and why? [( )] After the demonstrations, to reflect what was learned. [(X)] Before any demonstration or price is seen, so the weights cannot be bent towards a favourite. [( )] After the final price negotiation. [( )] By the supplier, who knows the product best. [[?]] Think about bias. **** Agreeing weights early protects the evaluation from preference for a platform that impressed the team (Outcome 2). **** **Question 4.** Two platforms swap rank when a weight changes by 5 points. What does this tell you? [( )] The scorecard is perfect. [(X)] The scorecard does not separate them clearly, so risk, exit terms and cost should carry more weight in the decision. [( )] The first platform must be chosen. [( )] The second platform must be chosen. [[?]] The result is unstable. **** A ranking that changes under small adjustments is weak. The decision should rest on other factors such as exit terms, risk and cost, and the memo should say so (Outcome 2). **** **Question 5.** What is the strongest evidence that a platform supports a credential standard? [( )] A statement in a brochure. [( )] A friendly reference. [(X)] Your own test with an independent verifier, supported by a conformance result for the named product and version. [( )] A logo on the supplier's home page. [[?]] Consider who controls the test. **** Own tests with independent verification are strongest, and conformance results for the specific product and version add confidence. Claims and logos are weakest (Outcomes 2 and 3). **** **Question 6.** Which pair of tests best reveals lock-in risk? [( )] Colour test and font test. [( )] Speed test and size test. [(X)] A full export test and a check of who controls credential identifiers and the issuer identity. [( )] A training attendance count and a satisfaction survey. [[?]] Look for data and identity control. **** Lock-in appears when data cannot leave in open formats or when identifiers depend on the supplier. These two checks expose both risks (Outcomes 2 and 3). **** **Question 7.** Which contract term best supports portability? [( )] The supplier may export data on request at hourly rates, in its own format. [(X)] The customer can export all credentials, earner records, evidence and issuing history in open formats at no extra charge during the term and at exit. [( )] The supplier will consider export requests at its discretion. [( )] The customer may export a list of earner names. [[?]] It should be complete, open, self-service and priced in advance. **** A portability clause should list what is exported, in which open formats, at what cost and when, so that the right can be used in practice (Outcome 3). **** **Question 8.** What should an exit plan include? [( )] Only the date of termination. [( )] Only the supplier's contact details. [(X)] Which data to export, formats, storage, continued verification of issued credentials, integration switch-over, timeline and responsible roles. [( )] Only a description of the new platform. [[?]] Think about earners, systems and data. **** An exit plan covers data, earners, verification, integrations, timeline and roles, so that leaving does not damage the credentials already issued (Outcome 3). **** **Question 9.** Which approach to AI features fits a sensible AI rule for platform selection? [( )] Accept all AI features because they save time. [( )] Reject any platform that mentions AI. [(X)] Assess each AI feature against your own rules: control over activation, human responsibility for decisions about earners, training use of earner data and transparency. [( )] Let the supplier decide which AI features are active. [[?]] Your rules come first. **** AI features should be checked against explicit rules about control, human decisions, data use and transparency. Features that conflict with the rules can be gate failures (Outcome 2 and Outcome 3). **** **Question 10.** Which estimate follows the costing approach of this course? [( )] Licence price multiplied by five years. [( )] The supplier's quoted price for year one. [(X)] A five-year total including implementation, integration, staff time, recurring charges and exit, with ranges for uncertain items and a sensitivity case. [( )] The cheapest price found online. [[?]] Include more than the licence. **** TCO includes one-off, recurring and exit costs, with ranges and sensitivity cases for uncertainty (Outcome 4). **** ## Sources and further reading Status: November 2026. The sources below are official texts, standards bodies and framework owners. Check the current versions and addresses before you use them, because specifications and programmes change. - **1EdTech Consortium**, the standards body that publishes the Open Badges and Comprehensive Learner Record (CLR) specifications. Look for Open Badges 3.0, CLR 2.0 and the information on conformance certification of products. - **World Wide Web Consortium (W3C)**, publisher of the Verifiable Credentials Data Model 2.0 Recommendation and related specifications on securing mechanisms and status lists. - **International Council on Badges and Credentials (ICoBC)**, publisher of the ICoBC Credentialing Skills Framework (ICSF) and the VRITE quality model, on which this course is aligned. Time-sensitive facts in this course: the current versions of Open Badges and CLR, the state of conformance certification, the Recommendation status of Verifiable Credentials Data Model 2.0 and the maturity of related specifications. Status: November 2026.