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. The service is operated by Designnest Technologies Limited, a company registered in Nigeria with registration number RC 8205707, whose registered office is at 12 Zone 6, Oteyi Garden Estate, Abule Ado, Lagos, Nigeria. It trades as Certifications.ng, and it is the data controller where this policy says we are one. 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.4, 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 — Designnest Technologies Limited, trading as Certifications.ng, the operator of the Service. Named because a controller has to be a legal person; a trading name is not one.
• Country — Nigeria.
• Credential — one certificate or badge issued to one Recipient under an Award, together with its 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.4.
• 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.
• Your own phone number, if you give us one. It is stored on your Account, not on the organisation. You set it in Settings, or it is saved when you enter it on the form asking us to set up a new award. We use it only to ring you about your requests, and it is never shown on a credential or to a recipient. To remove it, empty the field in Settings and save.
• Organisation details the Issuer keeps up to date: the support address shown to recipients, and a website.
• Organisation contact details we record ourselves when we set the organisation up, such as a contact email, a phone number and a postal address. The Issuer can ask us to change them.

When an Issuer submits the form asking us to set up a new award, or asking for a correction, what they enter is sent to us by email so that we can reply or call back. Apart from the phone number described above, 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. We also keep a record of the emails we send about it: when the first email and any reminder went, and our email provider’s reference for each. If you ask us to stop emailing you, we record the date you asked.

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 Payment data

When an Issuer buys credits we send them to Paystack, our payment processor, to pay. We hold a record of the purchase — how many credits, the amount, the tax, the reference, and which Account started it — because that is the Issuer’s own billing history and ours.

We never see, receive or store card details. The card number, expiry and security code are entered on Paystack’s own page, not on ours, and they never reach our servers at any point. We cannot charge a card again on our own initiative, because we hold nothing that would let us. What comes back to us is whether the payment succeeded, the amount, and the reference.

Paystack is a data controller in its own right for the payment it processes and applies its own privacy policy to it. Their handling of your card is between you and them; ours is limited to the purchase record described above.

4.4 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 identifies the person who viewed a page: anyone with the link can open it, and the record does not say who did.

It is counted per credential, though, and an Issuer sees part of it that way. Beside each recipient's name, the Issuer's portal shows whether that credential's page has been opened, but not how often or when, and the Issuer can download a list of the names and email addresses of recipients whose page has never been opened, so that they can follow up. Counts of views, shares and downloads are shown to the Issuer only as totals across its credentials. So an Issuer can tell whether your credential page has been opened, though not whether it was you who opened it. A visit by the Issuer’s own staff, or by ours while handling a correction they asked for, is counted in the same way as any other, so a page shown as opened may have been opened only by them or by us.

4.5 Booking a demonstration

The demo buttons on this site open a booking page run by Cal.com. When you book a call, Cal.com collects your name, your email address and your answers to the booking form, and passes them to us so that we can hold the call.

On a live demonstration we offer to issue you a credential under Certifications.ng’s own demonstration award, using the name and email address you confirm on the call. It is issued only if you agree. If you do, it is a real Credential like any other: you become a Recipient, and sections 4.2, 5, 10 and 11 apply to it as they would to a credential from any Issuer.

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, and — if the Issuer asks and the credential’s page has not been opened — send one reminder, never more than one per credential. Both are transactional messages about something awarded to you; neither is marketing. You can stop them, as section 11 explains.
• Show Issuers how their credentials are performing, using the aggregate engagement data described in section 4.4.
• 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.
• Hold demonstrations you book and, if you agree on the call, issue you a demonstration credential, as section 4.5 describes.
• 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. They process data on our instructions and for no purpose of their own, with one exception: Paystack is a data controller in its own right for the payment it takes and applies its own privacy policy to it, as section 4.3 explains.

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, and whether each one's page has been opened, as section 4.4 describes, and whether you have asked us to stop emailing you (section 11). 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

Some of 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. Paystack is a Nigerian company; the qualifier is there because this paragraph read as a blanket statement before payment processing was added, and a blanket statement about five providers is one claim too many.

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.
• Purchase records — kept indefinitely. A record of credits bought and spent is an accounting record and the Issuer’s own statement of what they were charged, so it is written once and never altered or removed. It contains no card details, because we never receive any.
• 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.

Stopping our emails

We email a recipient when a credential is issued to them and, if the Issuer asks and the credential’s page has not been opened, send one reminder. To stop all email from us about your credentials, reply to either email or write to support@certifications.ng. We record the request against your email address and do not email you about any credential again, whichever organisation issued it.

If you ask us to stop, any organisation that has issued you a credential, or issues you one later, can see that you asked us to stop, so that it does not promise you an email that will not arrive. Your credentials are unaffected: they stay valid and viewable at their links.

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 a credential, a recipient or any other record.

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

The Certifications.ng service is operated by Designnest Technologies Limited, a company registered in Nigeria (RC 8205707), whose registered office is given in section 1. Email is the only channel we offer for these requests; the registered office identifies the controller and is not a postal route we monitor, and we would rather say so than imply otherwise.

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