No Two Certification Bodies Work the Same Way
Every certification body has its own way of doing things. One CB uses a four-page opening meeting form; another uses a two-page version with different fields. One CB has accreditation for ISO 9001, ISO 14001, and ISO 45001 under a single AB; another holds accreditation under two different ABs with different scope requirements. One CB requires three committee members to sign every certification decision; another requires two, with a third only for initial certifications.
These differences are not cosmetic. They are rooted in the CB's accreditation agreements, its quality manual, its operational history, and the expectations of its accreditation body. When a CB adopts new software, the software must respect these differences — not flatten them.
The Problem With One-Size-Fits-All Platforms
Generic certification management tools typically ship with a fixed set of templates and a rigid workflow. The CB is expected to adapt its processes to the software. This creates immediate friction:
- •Template mismatch: The platform's built-in audit report template does not match the CB's accredited FR forms. The CB either uses the wrong template or maintains a parallel set of documents outside the system.
- •Workflow rigidity: The platform enforces a fixed number of phases or a specific approval sequence that does not match how the CB actually operates. Steps get skipped or worked around.
- •Scope model limitations: The platform assumes every standard uses EA codes. When the CB certifies against ISO 22000 with food chain categories or ISO 13485 with device classes, the scope model breaks down.
- •Branding gaps: Certificates, reports, and client-facing documents carry the platform's layout rather than the CB's own branding. This undermines the CB's professional identity.
Consider a CB like Summit Certification Group. They spent two years refining their audit report templates to satisfy their accreditation body's expectations. Every field, every section heading, every required sign-off line exists for a reason. When they tried a generic platform, they discovered they could not replicate their FR.210 stage report template. The platform's report builder lacked the fields they needed and added fields they did not use. Within three months, auditors were back to filling in Word documents and uploading them as attachments — defeating the purpose of the software entirely.
How Certiva Deploys: Isolated and Configured
Certiva does not ship a single application that every CB logs into. Each certification body receives its own isolated deployment, configured from the ground up to match that CB's specific operations.
Document templates are the CB's own documents. Every FR form — the application form, the audit plan, the stage report, the opening/closing meeting form, the nonconformity report, the committee review sheet, the certificate itself — is configured to match the CB's existing templates. Field names, section structure, required signatures, and layout all reflect what the CB already uses. This is not a theme or a skin. The actual form logic is built around the CB's documents.
The workflow matches the CB's quality manual. If the CB's process has 12 phases, Certiva is configured with 12 phases. If the CB requires a technical review before committee submission, that gate exists in the workflow. If the CB uses a different approval chain for surveillance versus initial certification, those distinct paths are modeled. The CB does not bend to fit the software; the software molds to how the CB already works.
Scope systems reflect the CB's accreditation. Certiva supports multiple scope classification systems. For a CB accredited for management system standards, the system uses EA codes. For food safety, it uses food chain categories. For medical devices, it uses device classes and technical areas. The scope model is configured per deployment based on the CB's actual accreditation.
Branding is fully applied. Certificates, reports, and all client-facing documents carry the CB's logo, colors, and layout. The client portal reflects the CB's identity. There is no Certiva branding visible to the CB's clients unless the CB chooses to show it.
What Configuration Looks Like in Practice
When a new CB onboards with Certiva, the configuration process follows a structured pattern:
- 1. Document collection: The CB provides its current FR form templates, quality manual extracts describing the certification process, and accreditation scope details.
- 2. Template mapping: Each FR form is analyzed and mapped into Certiva's form engine. Fields, sections, conditional logic, and signature requirements are all captured.
- 3. Workflow definition: The CB's certification lifecycle is modeled as a phase sequence with defined gates, required actions, and role assignments at each step.
- 4. Scope configuration: The CB's accreditation scope is loaded — standards, EA codes or alternative classification systems, and any scheme-specific requirements.
- 5. User and role setup: The CB's team structure is reflected in roles and permissions — planners, auditors, committee members, and administrative staff each get appropriate access.
- 6. Validation and training: The configured instance is reviewed against the CB's actual documents and processes, adjusted as needed, and the team is trained on their specific setup.
Why Isolation Matters
Each CB's Certiva instance is isolated. This means the CB's data, documents, configuration, and user base are completely separate from any other CB using Certiva. There is no shared database, no cross-CB visibility, and no risk that a configuration change for one CB affects another.
This isolation also means that each CB can evolve its configuration independently. When Apex Registrar updates its audit report template after an accreditation body review, that change is applied to Apex's instance without touching any other deployment. When they add a new standard to their accreditation scope, the scope model is updated for their instance alone.
The Result: Software That Feels Like It Was Built for You
The outcome of this approach is that planners, auditors, and committee members work with documents and processes they already know. There is no translation layer between "how we work" and "how the software works." The opening meeting form in Certiva looks like the opening meeting form the CB has always used. The audit report has the same sections in the same order. The certificate carries the CB's own layout and accreditation marks.
This is what it means for software to serve the CB rather than the other way around. Certiva does not impose a process. It automates the process the CB already has — with all the enforcement, tracking, and efficiency that a purpose-built platform provides.