CertLink Privacy Notice

1. Who we are and how to reach us

CertLink in Malaysia is operated by BADGE TECH SDN. BHD., a private company limited by shares incorporated in Malaysia on 24 June 2025 under the Companies Act 2016, Registration No. 202501028600 (1630012-A) ("we", "us").

Registered address: UG16, Tower A, PJ Midtown, Jalan Kemajuan, Seksyen 13, 46200 Petaling Jaya, Selangor, Malaysia General enquiries: info@badgetech.ai Data protection enquiries: Lee Ai Mun (info@badgetech.ai, +60-12-3300576)

The CertLink platform is built and operated by World Vertex Co., Ltd. (Republic of Korea), a separate company that processes personal data on our behalf and on our instructions. Section 9 explains what that means for where your data is.

2. Our roles: data controller and data processor

The PDPA now uses the term data controller (called data user before 1 April 2025) for the party that decides why and how personal data is processed, and data processor for a party that processes it on the controller's behalf. Our role depends on whose data it is.

Where the issuing institution is the data controller, it decides what is issued, to whom, and what the credential says. It is responsible for giving you its own notice under section 7 of the PDPA and for the lawful basis of the issuance. We process only on its documented instructions and do not use recipient data for our own purposes. Requests about a credential's content go to the institution named on it; we help the institution answer them.

3. Whose personal data we process, and what

Account holders. Name, work email address, organisation and role, password (stored as a one-way hash), multi-factor authentication settings, preferred language, sign-in and security events (time, IP address, device marker), and the actions you take in the console (an audit trail that records who did what to a credential).

Recipients. Whatever the issuing institution provides for the credential: at minimum a name and an email address, and usually the name of the award, its date, and identifiers such as a student or serial number. Some institutions add fields of their own (a grade, a programme code). The institution decides which fields exist; we do not add any. If you create a wallet account to keep your credentials, the account data above also applies.

Verifiers and visitors. The verification page does not ask who you are and keeps no record of it (section 7). Ordinary web server logs — IP address, time, requested path, browser type — are kept for a limited period for security and capacity purposes. The marketing site keeps one browser preference: whether you accepted or declined analytics (section 14).

Enquiry senders. Name, organisation, email address, optional telephone number, the message you write, the consents you gave and the version of the consent text you saw, and a receipt identifier. The IP address of the submission is stored only as a one-way hash used to limit abuse; the address itself is not kept.

We do not collect sensitive personal data as defined in the PDPA (health, political opinions, religious or similar beliefs, criminal matters, or biometric data) for any of these categories. If an issuing institution places such data in a credential field, it does so as the data controller and against our guidance.

Obligatory or voluntary. For an account, the name, email address and password are obligatory — without them an account cannot be created or secured. For an enquiry, the name, email address and message are obligatory — without them we cannot reply; the telephone number and marketing consent are voluntary. For a recipient, the issuing institution decides what is obligatory for its award; the consequence of not supplying it is a matter between you and the institution.

4. Where the personal data comes from

• From you, when you create an account, fill in the contact form, or accept a credential into a wallet.
• From the issuing institution, which uploads or types the recipient data it holds about you.
• From your browser, automatically, in the form of the server logs and cookies described in sections 3 and 14.

We do not buy personal data or enrich it from third-party sources.

5. Purposes and lawful basis

We do not use personal data for automated decision-making that produces legal or similarly significant effects, and we do not profile recipients.

6. What is — and is not — inside a signed credential

A CertLink credential is a digitally signed record that conforms to the Open Badges 3.0 standard. Once signed it cannot be edited: any change would break the signature. That property is what makes it verifiable, and it also means that anything personal placed inside it is permanent.

For that reason the signed record does not contain the recipient's email address. It carries a salted identity hash — a one-way value derived from the address and a random salt — which lets the recipient prove the credential is theirs without the address being readable to anyone who holds the file. The name and the award appear in the credential because they are what the credential attests.

Personal data that is not part of the attestation — the delivery address, notification history, the institution's internal notes — is kept outside the signed record, where it can be corrected and deleted in the ordinary way.

7. The public verification page

Every credential has a verification page reached by a link or a QR code. By default the page masks the recipient's name; the full name is shown only where the issuing institution has chosen full disclosure for that award, or to the recipient when signed in to their own wallet. Images generated for social-media previews are always masked, because they are fetched by services that cannot authenticate.

The verification page does not record who verified whom. It requires no sign-in, sets no tracking identifier, and keeps no lookup log linking a visitor to a credential. The only trace is the ordinary server log described in section 3.

8. Disclosure to third parties and sub-processors

We disclose personal data only to the classes of recipient below, and only to the extent needed for the purpose in section 5.

Sub-processors

We do not sell personal data, and we do not share it with advertising networks.

9. Cross-border transfer

Personal data processed by CertLink is transferred outside Malaysia to the Republic of Korea, where World Vertex develops and maintains the platform on behalf of BADGE TECH SDN. BHD., and is stored in [HOSTING REGION — pending].

Section 129 of the PDPA, as amended on 1 April 2025, allows a data controller to transfer personal data to a place that has a law substantially similar to the PDPA or that otherwise ensures a level of protection at least equivalent to it, and in the further cases listed in section 129(3). Korea's Personal Information Protection Act is a comprehensive data protection law of the same family; before this notice takes effect we will complete and keep a transfer impact assessment recording that conclusion, and the transfer will in addition be covered by contractual clauses between us and World Vertex. Where we act as a processor for an issuing institution, the institution's agreement with us authorises the transfer.

10. Retention

We keep personal data no longer than is necessary for the purpose it was collected for, and destroy or permanently delete it after that, as the Retention Principle requires. Because the categories differ, so do the periods.

11. Security

Since 1 April 2025 the Security Principle binds data processors directly, so our obligations under section 9 apply both where we are the controller and where we process for an institution.

Practical steps we take include: encryption in transit; signing keys held under envelope encryption and never exported; passwords stored as salted one-way hashes; multi-factor authentication for every console account, with a step-up window for sensitive actions; role-based permissions scoped to a single institution, enforced on every query; an append-only audit trail of console actions; separation of the public-facing service, the back-office and the processing worker into different system accounts; and a watchdog that raises an alert when issuance or mail delivery stalls. No measure makes a system invulnerable; section 16 says what happens if one fails.

12. Your rights under the PDPA

You may, in respect of personal data for which we are the data controller:

• Access — ask for a copy of your personal data (section 30). We may ask you to prove your identity. We do not currently charge a fee.
• Correction — ask us to correct data that is inaccurate, incomplete, misleading or out of date (section 34). See section 13 for data inside a signed credential.
• Withdraw consent — withdraw any consent you gave, at any time, by written notice (section 38). Withdrawing marketing consent does not affect a reply to your enquiry; withdrawing the consent on which an account depends means the account is closed.
• Limit processing — ask us to stop, or not begin, processing for a particular purpose (section 42), including processing that is likely to cause damage or distress (section 43).
• Data portability — since 1 June 2025, ask us to transmit personal data you provided to another data controller, to the extent technically feasible and compatible in format (section 43A). Credentials themselves are already portable by design: an Open Badges 3.0 file can be downloaded and imported into any conforming wallet.
• Complain — to us first, at the contact in section 17, and at any time to the Personal Data Protection Commissioner (Jabatan Perlindungan Data Peribadi, www.pdp.gov.my).

Where the issuing institution is the data controller, address your request to it; we will assist it and will act on its instruction. If you write to us instead, we will pass the request on and tell you we have done so.

We answer requests within the period the PDPA sets, currently 21 days, and tell you if we need longer and why.

13. Correction and erasure in an append-only ledger

Credential records are append-only. Nothing already issued is edited, because the signed file and the printed certificate are already in circulation and cannot be recalled. This changes how two rights work, and we would rather say so here than discover it during a request.

• Correction of something inside a credential (a misspelt name, a wrong date) is carried out by the issuing institution revoking the credential and issuing a replacement. The revoked credential remains on record, marked revoked, so that any copy still circulating verifies as revoked rather than disappearing without explanation.
• Erasure works in two parts. Personal data held outside the signed record — delivery address, notification history, account data — is deleted. The signed record itself is revoked and its personal fields are no longer displayed on the verification page; it is retained in revoked form for the period in section 10 because a verifier who holds a copy must be able to learn that it is no longer valid.

Both actions are decided by the issuing institution as data controller. We carry them out on its instruction.

14. Cookies and analytics

The application (app.certlink.io) sets only cookies the service needs to work: a session cookie, a short-lived cookie used during sign-in, a trusted-device marker that widens the multi-factor step-up window on a browser you have chosen to trust, and a language preference. None is used for advertising or tracking across sites.

The marketing site (certlink.io) asks one question, once: whether you accept analytics measurement. Until you accept, no analytics runs. Your answer is stored in your browser, not sent to us. We do not use advertising pixels, session replay or A/B testing tools. When an analytics provider is enabled it will be named here, and the version of this notice will change.

15. Children

CertLink is designed for institutions and their learners; it is not directed at children. Where an issuing institution issues credentials to recipients under 18, it is responsible as data controller for obtaining the consent of a parent or guardian where the PDPA requires it. We do not knowingly create accounts for children under 18 without such consent, and we delete an account we learn was created in breach of this.

16. Personal data breaches

Since 1 June 2025 the PDPA requires a data controller to notify the Commissioner of a personal data breach as soon as practicable and within 72 hours, and, where the breach causes or is likely to cause significant harm, to notify the affected individuals within seven days of notifying the Commissioner. We keep a register of breaches for at least two years.

Where we are the processor, we notify the issuing institution without undue delay so that it can meet its own deadline, and we support its notification. Where the breach concerns data for which we are the controller, we notify the Commissioner and you directly.

17. Data Protection Officer

We have appointed a Data Protection Officer, who is accountable for our compliance with the PDPA and is your point of contact for anything in this notice:

Lee Ai Mun (info@badgetech.ai, +60-12-3300576) Postal address: UG16, Tower A, PJ Midtown, Jalan Kemajuan, Seksyen 13, 46200 Petaling Jaya, Selangor, Malaysia

The appointment will be notified to the Commissioner as the Appointment of Data Protection Officer Guideline requires, and the contact details above are the same ones published in the footer of every page.

18. Language

Section 7(3) of the PDPA requires this notice to be given in the national language and in English. It is published in Bahasa Melayu and English, and each version links to the other. The two versions are intended to be identical in meaning. This draft was written in English; the Bahasa Melayu version has not yet been reviewed by a Malaysian lawyer, and the question of which version prevails in case of inconsistency will be settled in that review.

19. Changes to this notice and version history

We change this notice when the facts change — a new sub-processor, a new hosting region, an analytics provider being enabled. Each change gets a new version number and date, past versions are kept permanently, and a change that affects your rights is announced in the console and by email to account holders before it takes effect.

This notice cannot take effect until the Bahasa Melayu version has been reviewed and the hosting region and sub-processor list are filled in.