Certification Body Management Software: Why One Lapsed Credential Showing as Active Is Your Worst Day

Why the registry, not the exam, is the asset you are protecting

An employer's compliance officer calls on a Tuesday. She has just hired someone whose credential your public lookup shows as active, and she has heard from a colleague that the person was disciplined. She is right. The revocation was decided by your board five months ago, recorded in the minutes, communicated to the individual by letter, and never propagated to the registry, because the registry is a page generated from an export that somebody refreshes when they remember.

That is the failure that damages a certification body more than a bad exam form or a delayed renewal cycle. Employers, insurers, state agencies and sometimes courts rely on your registry as a statement of fact. When it is wrong in the direction of showing someone as certified who is not, you have a liability problem and a credibility problem in the same phone call. When it is wrong the other way, you have an angry certificant whose job offer just evaporated.

Most bodies we work with are running some combination of an association management system holding members, a learning platform holding courses, a spreadsheet holding the CE audit sample, an exam vendor's portal holding results, and a website with a lookup fed by a periodic export. The person exists five times. Nobody owns the credential as an object with a lifecycle. That is the gap, and it is why a lapse or a revocation can take months to reach the place the public actually looks.

Problem 1: your association management system thinks a credential is a membership flag

Association management systems are built around members, dues and events. Certification bodies frequently run on one because they started as, or sit alongside, a membership organisation. In that model, certification becomes a status field on a member record with an expiry date.

A credential is not a flag. It has an award date, a cycle with a defined end, a status that can be active, lapsed, suspended, revoked, retired or reinstated, a history of every transition with who decided it and on what basis, and a relationship to the specific version of the standard under which it was earned. A person can hold three credentials on three different cycles, let one lapse, reinstate it under a different pathway, and be subject to a disciplinary action affecting only one of them. Represent that as a flag and you will be maintaining the truth in a spreadsheet within a year.

A build makes the credential the central object, with the person record underneath it and membership, training and event history alongside rather than above. The public registry then reads from the credential's current state directly rather than from an export, which means a revocation recorded on Tuesday is visible on Tuesday. That single change is usually the first thing we implement and the reason the project gets approved.

Problem 2: eligibility is verification work, and it changes with every standards revision

Initial eligibility usually combines education, supervised experience, sometimes a licence in a related field, and sometimes attestations from a supervisor. Reviewing an application means reading documents, checking a transcript against a required curriculum, counting hours, and making a judgement that has to be consistent between reviewers and defensible if the applicant appeals.

Then the standard is revised, and applications submitted before the effective date are governed by the old pathway while new ones follow the new one, with a transition period for people partway through. Bodies handle this today with a checklist and institutional memory, which works until the reviewer who held the memory retires.

What a build must include: eligibility rules as versioned configuration with effective dates, so an application is evaluated under the pathway in force when it was submitted and remains explainable years later. Structured capture of experience hours rather than a narrative, so counting is arithmetic rather than judgement. Verifier workflows where a supervisor attests directly rather than emailing a signed PDF that the applicant forwards. And a reviewer interface that shows the requirement next to the evidence, which is the difference between a twenty minute review and a five minute one at the volumes a growing body reaches.

Problem 3: continuing education audits are a sampling process, not a document pile

Recertification is where certification bodies spend most of their operational effort. Certificants accumulate continuing education across categories with different weightings and caps, some activities count only once per cycle, some require documentation and some are self attested, and the body audits a random sample and reviews their evidence properly.

The manual version of this is a spreadsheet with a random number formula, an email requesting documentation, an inbox, and a reviewer opening PDFs. It works and it consumes a staggering share of a small team's year. It also weakens your accreditation evidence, because an auditor will ask how the sample was selected, whether selection was genuinely random, what the review criteria were and how inconsistent outcomes were handled.

A build handles category weightings and caps as configuration per credential and per cycle version, so a rule change next cycle does not require a new spreadsheet. Sampling is executed by the system with the seed and method recorded, which is exactly what an accreditation reviewer wants to see. Selected certificants get a structured evidence request with upload against the specific activity rather than a bundle. Reviewers work a queue with the rule visible beside the evidence. Outcomes, including extensions and deficiency remediation, are recorded on the credential. What was a season of work becomes a queue with a service level.

Problem 4: the exam vendor boundary is where data quietly diverges

Most bodies deliver examinations through a vendor such as Prometric, PSI or Pearson VUE. The interface is conceptually simple: you send an eligibility file, the candidate schedules, results come back. In practice the seams are where problems live. A candidate whose eligibility window expires while a retake is pending. Accommodations approved by your team that must reach the vendor correctly. Name changes between application and testing. Result files that arrive in a format that changed after a vendor system upgrade. Score reporting that must not release before the psychometric review of a new form is complete.

A build treats eligibility as a state your system owns and publishes, with windows, retake rules and attempt limits enforced on your side rather than assumed by the vendor. Results ingest into the credential lifecycle rather than into an inbox, and a failed result triggers the retake pathway automatically with its waiting period. If your body maintains item banks and runs psychometric analysis, keep that in the specialist tools built for it and integrate, because reimplementing psychometrics is not a good use of your budget and your accreditation depends on it being done properly.

Problem 5: impartiality is a structural requirement, not a policy statement

Accreditation under ISO/IEC 17024 or an NCCA standard requires that certification decisions are made independently of any training your organisation provides, that conflicts of interest are managed and documented, and that the process is applied consistently. If your body also sells preparation courses, runs a membership programme and administers the credential, that separation has to be visible in how the systems work, not only in a policy document.

In software terms this means role separation with real enforcement: staff who deliver training cannot see or influence certification decisions, reviewers with a relationship to an applicant are excluded automatically rather than by honour, and every decision carries a record of who made it and on what basis. Disciplinary and revocation processes need their own controlled workflow with evidence, notice, an appeal route and a defined effect on the registry at each stage. When your accreditation review arrives, the evidence should be a report from the system rather than a folder someone assembles over three weeks.

What this costs and how long it takes

A first release covering the person and credential model, the public verification registry reading live state, eligibility applications with versioned pathways and document verification, and recertification cycles runs $60,000 to $130,000 and ships in 12 to 18 weeks. A full platform adding continuing education tracking with category rules and audit sampling, exam vendor eligibility and results exchange, renewals billing, disciplinary and appeals workflow, chapter or state affiliate relationships and accreditation evidence reporting runs $150,000 to $380,000 phased over 6 to 12 months.

What drives cost up: the number of credentials and pathways, since each carries its own rules and each rule set has versions. Migration from an association management system, which is almost always messier than expected because the same person exists several times with different email addresses. Exam vendor integration, which varies in quality. Payment and invoicing, particularly if employers pay for cohorts of certificants rather than individuals. International operation with multiple currencies and languages. And any requirement to publish verification data to third parties through an interface, which is increasingly requested by employer platforms and needs its own access model.

What keeps it down: starting with one credential, keeping renewals billing in your existing finance system for a phase, and treating chapter and affiliate relationships as phase two.

Build versus buy, and when buying is the right call

Buy if you administer a single credential with one recertification pathway and under roughly 15,000 certificants. LearningBuilder is built for credentialing bodies and handles this shape well, and Certemy is a reasonable option particularly where employers are tracking credentials on their side. A build would be capital spent to reach a similar place, and your money is better spent on exam development.

Build when two or more of these are true. You administer several credentials with genuinely different eligibility pathways and CE rules. Your body also runs membership, training and events, and the same person exists in three systems that disagree. Your CE audit sample is selected with a spreadsheet formula and you would struggle to evidence the method to an accreditation reviewer. Your registry is refreshed by an export and you have had, or nearly had, the phone call at the top of this page. Or employers and regulators are asking for verification access that your current setup cannot provide safely.

How to choose a developer for certification management software

Ask them to model a credential before they show you a portal. They should describe status transitions including suspension, revocation, lapse and reinstatement, an audit trail of who decided what, and a link to the version of the standard under which it was earned. If they start with a members table and an expiry date, they have built an association system and your registry will drift.

Ask how the public lookup gets its data. The answer must be live state from the credential record with appropriate caching, never a periodic export. Then ask what the lookup shows for a suspended credential, because that is a policy question your board should answer and a good developer will make you answer it before they build it.

Ask how they version eligibility and continuing education rules. Applications and cycles must be evaluated under the rules in force when they began, and remain explainable afterwards. Editing rules in place is the failure that makes an accreditation review painful.

Ask what they have integrated by name, particularly your exam delivery vendor and your finance system. Ask how they would produce the evidence an ISO/IEC 17024 or NCCA reviewer requests, since a body that has to assemble that manually every cycle has not gained what it paid for.

Ask who owns the code and settle it in writing before kickoff. You should hold the repository, the cloud accounts and the right to hire another firm. At Digital Heroes the client owns everything from the first commit. Your registry is the organisation's core asset, and it should not sit in an environment controlled by anyone else.