Privacy Policy

1. Who we are

Certifications.ng ("we", "us", "the Company") issues, hosts and verifies digital certificates and badges on behalf of organisations that award them. We are based in Nigeria, and this policy covers the Certifications.ng service and nothing else.

Our role differs depending on whose data it is, and the distinction decides who you should approach first:

• For issuer account data — the people who sign in to run an organisation's credentials — we decide why and how the data is processed. We are the data controller.
• For recipient data — the people named on credentials — the issuing organisation decides who receives a credential and what it says. They supply the names and email addresses; we process that data on their instructions in order to produce, sign, host and deliver the credential. They are the controller and we act for them.
• For engagement analytics and the security of the platform we determine the purpose ourselves, and we are the controller for that narrow processing. What it consists of is set out in section 4.3, and it contains no information that identifies a person.

This matters practically. If you are a recipient asking us to change what a certificate says, the answer has to come from the organisation that awarded it — see section 11.

2. Interpretation and definitions

Words with an initial capital have the meanings below, in the singular and the plural alike.

• Account — a sign-in created for a named person at an Issuer so they can administer that organisation's credentials. Accounts are created by us on request. There is no public sign-up.
• Company — Certifications.ng, the operator of the Service.
• Country — Nigeria.
• Credential — one certificate or badge issued to one Recipient under an Award, together with its permanent verification page.
• Device — any device used to reach the Service, such as a computer, phone or tablet.
• Issuer — an organisation that awards credentials through the Service.
• NDPA — the Nigeria Data Protection Act 2023, and NDPC the Nigeria Data Protection Commission established under it.
• Personal Data — any information relating to an identified or identifiable individual.
• Recipient — an individual named on a Credential. A Recipient does not have an Account and does not sign in.
• Service — the Website, the credential pages it hosts, the issuer portal, and the emails sent about a Credential.
• Service Provider — a third party that processes data on our behalf in order to run the Service. Ours are named in section 8.
• Usage Data — data generated automatically by use of the Service, described in section 4.3.
• Website — Certifications.ng, at https://www.certifications.ng.
• You — the individual using the Service, or the organisation on whose behalf they are using it.

3. The two kinds of people this policy covers

Most privacy policies describe a single user who signs up, agrees to terms and manages their own account. That describes only half the people whose data is here, and it is the smaller half.

• Issuers hold an Account, sign in, and choose what to do. They came to us.
• Recipients hold no Account and never agreed to anything with us. Their name and email address reach us because an organisation submitted them in order to award them something. They generally learn that we exist when a certificate arrives.

We think a recipient in that position is owed a policy that says plainly what is held about them and what they can ask for, rather than one written for somebody who clicked "I agree". Sections 4.2, 5 and 11 are addressed to recipients specifically.

4. The data we collect

4.1 Issuer account and organisation data

For a person who signs in to the issuer portal, we hold:

• Email address, which identifies the Account and is the sign-in name.
• A password, stored only as a hash by our authentication provider. We cannot read it, and nobody here ever sees it.
• The organisation the Account belongs to. An Account belongs to exactly one organisation and cannot be attached to a second.
• Organisation contact details that the Issuer enters themselves — such as a contact email, a support address shown to recipients, a phone number, a website and a postal address.

When an Issuer submits the form asking us to set up a new award, or asking for a correction, the name, email address and phone number on that form are sent to us by email so that we can call them back. Those forms create no record in the database.

4.2 Recipient data

For a person named on a Credential we hold their name and their email address, supplied by the Issuer, together with the details of the credential itself: the award, the issuing organisation, the issue date, an optional note the Issuer adds, and the generated PDF and image files.

That is the complete list. We do not collect or ask for a date of birth, a phone number, a postal address, a national identity number, a photograph or any identity document, and there is nowhere in the platform to put one. We hold no special-category data — nothing about health, biometrics, religion, politics or ethnicity.

A recipient's record is shared across issuers rather than duplicated, so if two organisations award the same person a credential, both credentials attach to one record identified by the email address. One issuer cannot see another issuer's credentials, and issuing a credential never overwrites a name recorded by somebody else.

4.3 Usage data

When a credential page is viewed we record how the page was used, so that the Issuer can see whether their recipients are actually receiving and sharing what they were awarded. Each event records:

• what happened — a page view, a download, a share to a named social network, a copied link, or the verification panel being opened;
• a random session identifier, generated in the browser and held in sessionStorage, which is erased when the tab closes and is never linked to a person;
• the browser's user-agent string, and the device type, browser and operating system derived from it;
• the referring page, where the browser supplies one;
• time spent on the page.

We do not record IP addresses, and nothing in this data is joined to a recipient's name or email address. An Issuer sees counts and totals for their own credentials; they cannot see which named individual viewed what, because that information does not exist in the record.

5. Recipient email addresses and the credential page

This section describes something that is easy to miss, and we would rather you learned it here than found it for yourself.

A credential is protected by a digital signature covering seven fields: the credential ID, the recipient's name, the recipient's email address, the award name, the issuing organisation, the issue date and a format version. The signature is what makes an altered certificate detectable. Verification is deliberately performed in the visitor's own browser rather than asserted by our server, because a server that simply says "verified" is asking to be trusted.

Doing the check in the browser means the browser must be given the exact data that was signed — including the email address. So the address is present in the data behind a credential page. It is never displayed on the page, but somebody who has the credential link and looks at the page source can read it.

We keep it that way because removing it would mean the credential could no longer be independently verified, which is the entire purpose of the page. But it has a practical consequence worth stating: a credential link is not a secret, and sharing it publicly — on LinkedIn, in a CV, on a website — shares that address along with it. If that is not acceptable for a particular credential, section 11 sets out what can be done about it.

How the signature works, and what it does and does not prove, is described in full on our security page.

6. Cookies and similar technologies

We set one cookie, and only for people who sign in to the issuer portal. It holds the signed session that keeps an Issuer logged in. It is marked httpOnly so that scripts cannot read it, SameSite=Lax so that it is withheld from cross-site form submissions, and Secure so that it is only ever sent over HTTPS. It expires after fourteen days, and signing out destroys it.

Viewing a credential page, or any other page on this website, sets no cookie at all. The session identifier used for engagement analytics is not a cookie: it is held in sessionStorage, which is confined to that one browser tab and is erased when the tab is closed. It is not sent automatically with requests the way a cookie is.

We do not use, and this site does not contain:

• advertising or retargeting cookies of any kind;
• third-party analytics scripts, tag managers, or social media tracking pixels;
• web beacons, clear GIFs or tracking pixels in our emails;
• web fonts or other assets loaded from a third party into your browser.

There is no cookie consent banner on this site because there is nothing to consent to. The single cookie we set is strictly necessary to keep a signed-in issuer signed in, and no cookie is set for anyone else.

7. How we use personal data

We use personal data only in order to:

• Produce and sign credentials — generate the certificate or badge, sign the record with the issuing organisation's key, and store the resulting files.
• Host verification pages, so that a credential can be checked by anyone the recipient shows it to.
• Notify recipients that a credential has been issued, at the time the Issuer chooses. This is a transactional message about something awarded to you; it is not marketing.
• Show Issuers how their credentials are performing, using the aggregate engagement data described in section 4.3.
• Operate and secure the Service — authenticate sign-ins, prevent unauthorised access, diagnose faults, and maintain backups.
• Respond to you when you contact us, including requests to set up an award or correct a credential.
• Meet legal obligations, and establish, exercise or defend legal claims.

We do not sell personal data. We do not share it with advertisers, data brokers or business partners for their own purposes, we do not use recipient email addresses to market anything to them, and we do not build advertising profiles.

Our lawful bases under the NDPA are: performance of our contract with the Issuer; the legitimate interests of the Issuer and of recipients in credentials that can be verified and are known to have arrived; and, where it applies, compliance with a legal obligation. Where an Issuer relies on consent to award and publish a credential, obtaining that consent from the recipient is the Issuer's responsibility, since the relationship is theirs.

8. Who we share personal data with

We use a small number of service providers to run the platform. Each processes data on our instructions and for no purpose of their own:

We may also disclose personal data:

• To the issuing organisation. An Issuer can see the credentials it has issued, including the names and email addresses on them. It cannot see any other organisation's.
• To anyone holding a credential link. A verification page is public by design — that is what allows an employer to check a credential without contacting you. What such a visitor sees is covered in section 5.
• Where the law requires it, including in response to a valid request from a court or public authority, or where disclosure is necessary to comply with a legal obligation, to protect our rights or property, to investigate wrongdoing connected with the Service, or to protect the safety of users or the public.
• In a business transfer. If the Company is involved in a merger, acquisition or sale of assets, personal data may be transferred. We will give notice before your data becomes subject to a different privacy policy.

9. Transfers outside Nigeria

The service providers named in section 8 operate infrastructure outside Nigeria, so personal data held on the platform is stored and processed outside the country, in jurisdictions whose data protection laws may differ from Nigeria's.

Where the NDPA requires it, we rely on the contractual protections in our agreements with those providers, which oblige them to process data only on our instructions and to maintain appropriate security. We will not transfer personal data to a provider that cannot offer those protections. You can ask us for the current list of providers and the locations they process in using the contact details in section 16.

10. How long we keep it

• Credential records — for as long as the credential exists. A credential is a permanent record that must stay verifiable years after it was issued; deleting the record is what makes a genuine certificate stop verifying, so we do not delete one unless asked to. See section 11.
• Engagement analytics — five years. We should be plain that this policy is not yet automated: no scheduled deletion job runs today, and the first records to fall due under it were created in December 2025, so none are yet eligible. We will delete them on request in the meantime.
• Analytics tied to a deleted credential — removed automatically with it, at the same moment.
• Issuer accounts — for as long as the organisation uses the Service, and then until the account is closed.
• The sign-in cookie — fourteen days, or until sign-out.
• Correspondence, including award requests and correction requests, for as long as needed to deal with the matter and to keep a record of what was agreed.

11. Your rights, and what we can and cannot do

Under the NDPA you have the right to be informed about how your data is used, to access it, to have inaccurate data corrected, to have data erased, to restrict or object to processing, to receive your data in a portable form, and to withdraw consent where processing relies on it. You also have the right to complain to the Nigeria Data Protection Commission.

To exercise any of these, write to us using the details in section 16. We will respond within the period the NDPA allows, and we may need to confirm your identity first — for a recipient, that normally means writing from the address the credential was issued to.

What follows is how those rights work in practice here, including where they run into a limit.

Correcting a credential

A misspelled name or a wrong date is fixed by regenerating and re-signing the credential, not by editing it in place — otherwise the file already downloaded would no longer match the record and the signature would match neither. The verification link never changes, so anything already shared keeps working. Names are stored once, so a corrected spelling applies to every credential that person holds.

Requests to change what a credential says — the award, the date, whether it should have been issued — are decisions for the issuing organisation, and we will refer you to them.

Keeping a credential out of search results

We can mark a credential page so that search engines do not index it. This can be applied to a single credential, to every credential under an award, or to an entire organisation, and a suppression at any level wins.

Be clear about what this does and does not achieve: the page remains fully viewable to anyone who has the link. It stops the page being found by searching for your name; it does not withdraw the credential or restrict who can open it.

Deleting a credential

On request we will delete the credential record, the generated files, and the engagement events attached to it, after checking with the issuing organisation — they hold their own record of having made the award, and deleting ours does not erase theirs. Once deleted, the verification link stops working permanently, which cannot be undone.

What we cannot do

We cannot currently revoke a credential. There is no mechanism to mark an issued credential as withdrawn, expired or invalid while keeping the page available to explain that. The options are the two above: remove it from search results, or delete it outright. We are stating this because a policy that quietly omitted it would leave an issuer or a recipient discovering it at the worst possible moment.

12. Security

Credentials are signed with a key belonging to the issuing organisation, held encrypted in a vault, never sent to a browser and never included in any downloaded file. Access to issuer data is restricted at the database level to members of that organisation and checked again on every request. Accounts are created by us; there is no public sign-up. The portal cannot delete anything.

No method of transmitting or storing data is completely secure, and we do not claim otherwise. What we can say is what the protection consists of and where it stops, which is set out on our security page — including the things a signature does not prove.

13. Children

The Service is not directed at children, and we do not knowingly collect personal data from a child under 13 through the Website or the issuer portal.

An Issuer may award a credential to someone under 13 — a school or a youth programme reasonably might. Where that happens, the organisation submitting the name is responsible for having the parental or guardian consent its own obligations require, since the relationship with the child is theirs and not ours. If you are a parent or guardian and believe a credential has been issued to your child without that consent, contact us and we will act on it.

14. Links to other websites

This site links to websites we do not operate, including those of issuing organisations and the social networks a credential can be shared to. We do not control them and are not responsible for their content or their privacy practices. Their policies govern what they do once you arrive; we would encourage you to read them.

15. Changes to this policy

We may update this policy. When we do, we will post the new version on this page and change the "Last updated" date at the top. Where a change materially affects how personal data is used, we will give notice by email or through a prominent notice on the Service before it takes effect. Changes are effective when posted.

16. Contact us

For any question about this policy, or to exercise any of the rights in section 11:

• By email: charles@certifications.ng

If you are not satisfied with how we have handled your request, you may complain to the Nigeria Data Protection Commission.