Security and Compliance

Effective date: May 27, 2026Last updated: May 27, 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.

This page is informational. It is updated as our programme evolves; the most recent material change is reflected in the Last updated date above. Detailed evidence — audit reports, sub-processor list, penetration-test summaries — is available to Subscribers under non-disclosure agreement; please email security@certivant.com.

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, network segmentation and human review reinforce each other.
  3. Verify, then trust — and verify again. We test our controls continuously, through automated scanning, third-party penetration testing, internal red-team exercises and external audits.

2. Compliance frameworks and certifications

Certivant aligns its security and privacy programme to the following frameworks. Where we hold a third-party attestation, it is available to Subscribers under NDA on request.

| Framework | Status | |—|—| | SOC 2 Type II (Security, Availability, Confidentiality) | Annual audit; report available under NDA | | ISO/IEC 27001 | Programme aligned; certification roadmap published to Subscribers under NDA | | GDPR (EU 2016/679) | Compliant as a data processor; DPA on offer to every Subscriber | | UK GDPR and the Data Protection Act 2018 | Compliant; UK Addendum available | | PIPEDA (Canada) | Compliant; supports cross-border safeguards | | Québec Law 25 (Act respecting the protection of personal information in the private sector) | Compliant; supports Québec-specific rights including automated-decision review | | CCPA / CPRA (California) | Compliant as a service provider | | PCI DSS | Card data is processed exclusively by our PCI-DSS Level-1 payment-gateway sub-processors; Certivant systems do not store payment-card data | | NIST Cybersecurity Framework | Used as the structural reference for our internal control catalogue | | OWASP ASVS Level 2 | Used as the baseline for application-security design and review |

We do not claim certifications we have not earned. Where the table above shows "aligned" or "roadmap", we do not yet hold a certification but actively work towards it.

3. Application security

3.1 Secure software development lifecycle

  • Every change to production code goes through peer code review by a second engineer before merge.
  • Every change is built and tested through an automated CI pipeline that runs unit tests, integration tests, type-checks, secret scanning and dependency-vulnerability scanning.
  • We use static-application-security-testing (SAST) tools to surface common vulnerability patterns at pull-request time.
  • We use software-composition-analysis (SCA) tools to detect vulnerable open-source dependencies and trigger patch-and-deploy workflows.
  • We commission third-party penetration tests at least annually; the most recent summary is available to Subscribers under NDA.
  • We run a private 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.
  • All Subscriber accounts may enforce mandatory multi-factor authentication and configurable session-timeout policies through the dashboard.
  • 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 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 at every database query; cross-tenant data access is impossible by construction at the storage layer, and is additionally enforced by row-level security where supported.
  • 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 across all our domains with a long max-age and includeSubDomains.
  • We publish a security.txt file at the root of each public domain.

4.2 Encryption at rest

  • All Subscriber and End-User data is encrypted at rest using AES-256 (or equivalent) at the storage layer.
  • Identity documents and biometric samples are stored as encrypted blobs in private object storage; signed URLs valid for 15 minutes are required to download them.
  • Database backups are encrypted at rest with separate keys.
  • Encryption keys are managed by a dedicated key-management service with rotation and audit logging; key access is restricted to a small number of explicitly authorised production systems.

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 URLs are short-lived and signed; they cannot be guessed or replayed.
  • Documents are tagged with a retention policy at upload time so they are deleted on schedule.
  • Access to documents or biometric samples by Certivant personnel is logged and alerts the security team for human review.

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

5.1 Cloud hosting and segregation

Certivant runs on a major public-cloud provider. Production, staging and development environments are isolated in separate accounts with no network connectivity between them. Production access requires a separate identity, multi-factor authentication, and just-in-time elevation with audit logging.

5.2 Network controls

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

5.3 Endpoint security

  • All employee workstations are managed by mobile-device-management software with full-disk encryption, automatic patching, screen-lock enforcement and remote-wipe capability.
  • Endpoint-detection-and-response software runs on every workstation.
  • Employees authenticate to the corporate environment via SSO with mandatory multi-factor authentication; phishing-resistant factors are required for production access.

5.4 Monitoring and incident response

  • We centralise logs from production hosts, applications and security tools in a dedicated log-management system.
  • A 24/7 alerting pipeline routes high-severity events to the on-call security and platform engineers.
  • We follow a documented incident-response runbook with defined severities and notification timelines, exercised at least annually via tabletop simulations.
  • 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 continuously scan our infrastructure and application code for known vulnerabilities.
  • 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 by the security team and tracked with compensating controls until remediation.

6. Identity and access management within Certivant

  • Employees and contractors are granted access on a least-privilege basis. Access requests are tracked in a ticket system and require manager approval.
  • Production access is gated behind multi-factor authentication, role-based access control and just-in-time elevation. Permanent production access is reserved to a very small set of platform engineers.
  • Quarterly access reviews remove access that is no longer required.
  • Departing employees and contractors lose all access on the day of departure through automated off-boarding tied to our HR system.

7. Business continuity and disaster recovery

  • Production data is backed up on a daily schedule, with backups encrypted at rest and replicated across availability zones.
  • We test our restore procedures quarterly to verify backup integrity.
  • The Service is designed to be regionally resilient — a single-zone failure does not interrupt availability. Multi-region failover is exercised at least annually.
  • We publish a target Recovery Time Objective (RTO) of 4 hours and 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.
  • 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. 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.
  • Background checks consistent with local law are conducted for personnel with access to production systems.
  • Security-awareness training is mandatory at hire and annually thereafter, covering phishing recognition, secure-coding basics, data handling, incident reporting and social-engineering defence.
  • Personnel with access to sensitive data complete additional role-specific training (e.g. on biometric-data handling).

11. Physical security

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

Our office environments (where employees work in person) are access-controlled, with visitor sign-in, locked storage for any physical media, and a clean-desk policy. 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:

Send a detailed report to security@certivant.com. Include the affected URL or endpoint, reproduction steps, and the expected vs. actual behaviour.If you discovered the vulnerability through automated tooling, please verify it manually before reporting. We get a lot of unverified scanner output.Do not access, modify or destroy data that does not belong to you. Use test accounts and synthetic data wherever possible.Give us a reasonable period to remediate before public disclosure. We aim to acknowledge reports within two (2) business days and to remediate critical issues within thirty (30) days.

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.comVulnerability reports: security@certivant.com

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