Security and Compliance

Effective date: May 27, 2026 Last updated: October 5, 2026

Certivant operates in one of the most sensitive corners of the software industry: handling government-issued identity documents, biometrics and risk-decision data for our Subscribers. We design the platform around the assumption that any control could fail, and that our worst day will be the day someone tries to exploit one. This page summarises the security and compliance posture we operate to.

Current status. Certivant is preparing for general availability. This page distinguishes the controls that operate today from those we are putting in place for our production environment and independent audits. We do not describe a control as operating until it does, and we update this page as each one is completed.

This page is informational; the most recent material change is reflected in the Last updated date above. Security documentation and our sub-processor list are available to Subscribers on request at security@certivant.com. Audit reports and penetration-test summaries will be shared under non-disclosure agreement once they are issued.

1. Our security philosophy

We follow three operating principles:

1. Least privilege. Every human, every service and every record gets the minimum access required. We default to deny.
2. Defence in depth. No single control is trusted on its own. Encryption, access control, audit logging, monitoring and human review reinforce each other.
3. Verify, then trust — and verify again. We test our controls through automated checks on every change today, and we are commissioning independent penetration testing and external audits ahead of general availability.

2. Compliance frameworks and certifications

Certivant aligns its security and privacy programme to the following frameworks.

We do not claim certifications we have not earned. Where the table above shows "aligned", "in preparation" or "planned", we do not yet hold that certification but are actively working towards it.

3. Application security

3.1 Secure software development lifecycle

• Every change is checked by an automated pipeline before release: type-checks, linting, unit tests, static application-security testing (CodeQL) and dependency-vulnerability scanning (automated dependency updates and package audits).
• Secret scanning in the pipeline is being added.
• Mandatory review of every change by a second engineer will apply as our engineering team grows.
• We will commission an independent penetration test before general availability and at least annually afterwards; summaries will be available to Subscribers under NDA.
• We run a vulnerability-disclosure programme — see Section 12.

3.2 Authentication and authorisation

• Subscriber accounts authenticate via email + password with bcrypt hashing, with optional WebAuthn (passkeys) and TOTP multi-factor authentication available to every user.
• Organisation-wide enforcement of multi-factor authentication is being added to the dashboard.
• Sessions expire after a period of inactivity, and sensitive actions require a recent sign-in; repeated failed sign-in attempts lock the account temporarily.
• We support single sign-on (SSO) via SAML 2.0 and OpenID Connect on eligible plans, with optional just-in-time provisioning and SCIM 2.0 user lifecycle management.
• API access uses long-lived API keys with scoped permissions (kyc:read, kyc:write, kyc:submit, kyc:manage); keys may be revoked instantly and rotated without downtime.
• The internal authorisation model is role-based at the organisation level (Owner / Admin / Member) and team-scoped for per-team isolation when configured.

3.3 Input validation, output encoding and tenant isolation

• Every API endpoint validates its inputs against a strict schema before any business logic runs.
• Output is context-aware-encoded to prevent injection across HTML, attribute, URL and JavaScript contexts.
• Each Subscriber's data is partitioned by organisation ID, and the application enforces that partition on every database query.
• API responses include security headers (Content-Security-Policy, Strict-Transport-Security, X-Content-Type-Options, Referrer-Policy, Permissions-Policy) by default.

4. Data security

4.1 Encryption in transit

• All traffic between Subscribers, End Users and Certivant uses TLS 1.2 or higher with modern cipher suites; we disable known-weak ciphers and protocols.
• HTTP Strict Transport Security (HSTS) is enabled with a long max-age.
• A security.txt file will be published at the root of each public domain.

4.2 Encryption at rest

• Provider credentials and other application secrets are encrypted by the application before they are stored.
• Identity documents and selfies are kept in private storage and served only through the authenticated application or short-lived signed links.
• Our production environment, being commissioned for general availability, encrypts databases, file storage and backups at rest with AES-256 (or equivalent).
• Per-Subscriber encryption keys held in a key-management service, with rotation and audit logging, are being rolled out to personal-data fields.

4.3 Biometric and identity-document handling

Biometric samples and identity documents are the most sensitive personal information we handle. We apply additional controls to them:

• Documents and biometric samples are never indexed or made queryable except by the authorised verification pipeline.
• Document and selfie links are short-lived and signed; they cannot be guessed or replayed.
• Every verification event is recorded in an append-only, tamper-evident audit log.
• Retention periods are configurable per Subscriber; automated deletion on schedule is being enabled.

4.4 Data retention and deletion

We retain personal information only as long as necessary for the purpose for which it was collected. Default retention periods are set out in our Privacy Policy. Subscribers may instruct shorter retention through the dashboard. We support hard deletion of an End User's data on Subscriber request, subject to overriding legal obligations.

5. Infrastructure and operations security

Status: the controls in this section describe the production environment we are commissioning for general availability. They will be covered by the independent audits and penetration tests described above.

5.1 Cloud hosting and segregation

Certivant will run on a major public-cloud provider in Canadian regions. Production, staging and development environments will be isolated from one another. Production access will require a separate identity, multi-factor authentication, and just-in-time elevation with audit logging.

5.2 Network controls

• Public ingress will be restricted to a small number of known endpoints fronted by a managed web-application firewall and DDoS-mitigation service.
• Internal services will communicate within a private network, with outbound egress restricted to an explicit allow-list of destinations.
• Administrative access to production hosts will go through a bastion service with session recording.

5.3 Endpoint security

• Workstations used to access production systems will be managed with full-disk encryption, automatic patching, screen-lock enforcement and remote-wipe capability.
• Access to the corporate environment and to production will require multi-factor authentication, with phishing-resistant factors for production access.

5.4 Monitoring and incident response

• Logs from production hosts, applications and security tools will be centralised in a dedicated log-management system, with alerting that routes high-severity events to on-call engineers.
• We follow a documented incident-response runbook with defined severities and notification timelines.
• We commit to notifying Subscribers without undue delay — and within 72 hours at the latest — of any confirmed personal-data breach affecting their data, as required by the GDPR, Québec Law 25, and our DPA. Notification includes the nature of the breach, the categories and approximate number of records and individuals affected, the likely consequences, and the mitigation measures taken or proposed.

5.5 Vulnerability management

• We scan our application code and dependencies for known vulnerabilities on every change.
• Critical and high-severity vulnerabilities are remediated within defined service-level objectives:
  • Critical — within 24 hours
  • High — within 7 days
  • Medium — within 30 days
  • Low — within 90 days
• Exceptions are reviewed and tracked with compensating controls until remediation.

6. Identity and access management within Certivant

• Personnel are granted access on a least-privilege basis.
• Production access will be gated behind multi-factor authentication, role-based access control and just-in-time elevation, and reserved to a very small set of engineers.
• As the team grows, access requests will be tracked and approved, access will be reviewed quarterly, and departing personnel will lose all access on their day of departure.

7. Business continuity and disaster recovery

The following targets apply to the production environment being commissioned:

• Production data will be backed up daily, with backups encrypted at rest and replicated across availability zones.
• Restore procedures will be tested regularly to verify backup integrity.
• The Service will be designed so that a single-zone failure does not interrupt availability.
• Our target is a Recovery Time Objective (RTO) of 4 hours and a Recovery Point Objective (RPO) of 1 hour for catastrophic events. Detailed RTO / RPO for specific service tiers is set out in the applicable Order.

8. Privacy by design

• We minimise the data we collect: by default we collect only the fields the Subscriber's selected verification flow requires.
• We pseudonymise wherever processing does not need to identify the End User by name.
• We provide Subscribers with the controls they need to respond to End-User rights requests (access, correction, deletion, portability, restriction, objection).
• We support automated-decision review under Québec Law 25 — Subscribers can configure their flows to route borderline or escalated decisions for human review through the dashboard.
• Before a live identity verification call, the End User is asked for explicit consent to share personal information, to photo capture and to video recording; consent to recording cannot be skipped, and a refusal cancels the call.
• We provide a Data Processing Addendum (DPA) to every Subscriber, incorporating the European Commission's Standard Contractual Clauses (2021) and the UK International Data Transfer Addendum where applicable.

9. Sub-processors

We use a limited number of carefully vetted third-party service providers to operate parts of the Service. Each sub-processor is bound by a written contract that imposes confidentiality, security and data-protection obligations at least as strict as ours.

The current categories of sub-processors are summarised in Section 5.2 of our Privacy Policy. A current named list with their location and the data they process is available to Subscribers on request and is updated when changes occur. Some optional verification features (such as document reading, vendor liveness and AI-assisted checks) may process data outside Canada; the list identifies where each provider processes data. Material additions or replacements of sub-processors are notified to Subscribers in advance, with an opportunity to object.

10. Human resources security

• Every Certivant employee and contractor signs a confidentiality agreement before being granted access to any Subscriber or End-User data.
• As the team grows, personnel with access to production systems will undergo background checks consistent with local law, and security-awareness training will be required at hire and annually thereafter.

11. Physical security

Certivant does not operate physical data centres of its own. The cloud-provider data centres that will host our production environment maintain physical security certifications appropriate to their tier, including SOC 2, ISO 27001 and, where applicable, sovereign-cloud equivalents.

Sensitive Subscriber or End-User data is not printed.

12. Reporting a vulnerability

We welcome security research conducted in good faith. To report a vulnerability:

We do not currently operate a paid bug-bounty programme, but we recognise legitimate researchers in our security acknowledgements, and we will not pursue legal action against researchers acting in good faith and in accordance with this policy.

13. Customer responsibilities

Security is a shared responsibility. Certivant operates the Service securely; Subscribers must use it securely. To uphold their side of the shared model, Subscribers should:

• Configure roles and permissions carefully — grant production access only to users who need it
• Enable multi-factor authentication for every Authorized User
• Use SSO when available
• Rotate API keys regularly, and never commit them to source control or share them across environments
• Verify webhook signatures on every payload before acting on it (see our signature-verification guide)
• Treat verification results as one input to your risk decision — combine them with your own controls (transaction monitoring, behavioural analytics, manual review where appropriate)
• Provide End Users with the privacy disclosures and consents required by applicable law before initiating a verification
• Report any suspected security incident affecting your account or End-User data to security@certivant.com without undue delay

14. Contact

Management-Ware Solutions Inc. Security Office — Certivant Montréal, Québec, Canada Email: security@certivant.com Vulnerability reports: security@certivant.com

For privacy questions, see our Privacy Policy. For contract-related questions, see our Terms of Service.