01 / Our commitment
We would rather show the evidence than ask for trust.
Verifycate exists to make recognition checkable. That promise only holds if the platform behind it is trustworthy. Security, privacy, and availability are therefore product requirements, not procurement overhead. They shape what we build, what we collect, how we deploy, and what we refuse to claim.
We design for failure, limit access by default, collect only what a certificate needs, and test the result independently. Where an attestation has not yet been issued, we state that plainly. Where a document exists, we will send it. Where a control is missing, we will tell you rather than let a sales process discover it.
Security by design
Threat modelling, secure coding, and automated scanning are part of the development lifecycle, not a review that happens after release.
Privacy by default
We process the minimum required to issue and verify a credential. We do not sell personal data or run advertising trackers in the application.
Evidence on request
Penetration-test summaries, questionnaires, subprocessor details, and architecture documentation are available to customers and their reviewers.
The Verifycate security and privacy team
Reviewed 26 October 2026
02 / Credential integrity
Trust is built into every certificate.
A certificate is only as trustworthy as the record behind it. Every issued certificate carries an identity, a signature, a verification route, and an access history. Its integrity can be checked without asking the recipient to trust a downloaded file. A forged or altered copy does not resolve to the same record.
The certificate is the visible part.
Underneath it: an identifier, a signature, an audit trail, and a public verification page. Every one of them can be checked.
Record events
A unique credential ID
Every issued certificate has an identifier tied to one record, one recipient, and one issuer. A lookup resolves to the same record every time.
A signed record
Issuer identity and certificate data are signed at issue. A later change to the record no longer matches the signature.
A route to verification
The QR code and public URL lead to the issuer's verification page. The page, not the printed image, is the source of truth.
Tamper-evident by design
An issue is tied to a signed record and an immutable design snapshot. A correction is recorded in the audit trail; an altered copy does not match the record.
Only authorised people can issue
Workspace roles scope who can create, approve, send, and correct a certificate. Sensitive actions are written to an append-only audit trail.
A public record, not a file
Verification is public by design. A recipient needs no account, and a verifier needs no relationship with the issuer.
Specimen certificate shown. ACME University, its registrar, and the recipient are fictional.
Verify a real certificate03 / Blockchain integrity
Proof that can be checked outside our platform.
On Pro, Verifycate anchors a cryptographic fingerprint of each certificate record to public distributed ledgers. The anchor is a proof of integrity, not a copy of the credential. It can be inspected by anyone, without a Verifycate account.
Only a hash is anchored. Never personal data.
Publicly verifiable
The anchor lives on a public ledger. A verifier can inspect it independently, without an account or a relationship with the issuer.
Outlives Verifycate or the issuer
The integrity proof is not held in our database. Open Badge 3.0 and W3C Verifiable Credentials data travel with the credential, so the record is portable beyond this platform.
Private by construction
Names, email addresses, and certificate contents are never written on-chain. Because only a fingerprint is public, correction and erasure remain enforceable off-chain.
Anchoring is available on the Pro plan. Blockchain-backed certificates use Base (an Ethereum L2) and Bitcoin through OpenTimestamps. Blockchain anchoring supplements the signed record; it does not replace it.
04 / Verification and access
A record anyone can check. Access only where it belongs.
Verification process
From issue to independent check
Verification is deliberately simple for the person checking and deliberately strict about what is being checked. The certificate image is never the source of truth; the issuer's record is.
Open the verification page- 01
Scan or open
The verifier scans the QR code or opens the certificate URL.
- 02
Resolve the record
The page resolves the credential ID to the issuer's current record.
- 03
Check signature and status
Recipient, issuer, signature, and validity status are checked against that record.
- 04
Confirm the anchor
For blockchain-anchored certificates, the fingerprint is compared with the public ledger.
Role-based access control
Access is granted, scoped, and recorded.
Workspace roles determine who can issue, approve, correct, export, and administer. Permissions are scoped to one workspace. Nothing follows a user into another organisation's data.
Platform staff access is separate, least-privilege, and recorded in an audited admin surface.
Read the access-control standardWorkspace role
Scope
Admin
Workspace settings, members, billing, and security configuration.
Manager
Certificates, issuance, review queues, and exports.
Issuer
Create, send, and manage certificates.
Support
Recipient requests, corrections, and read-only support.
SSO, SCIM, and audit-log export are available on Pro. See enterprise identity features.
05 / Security practices
Security by design, evidenced in operation.
Security is a development lifecycle, not a release checklist. We take a shift-left approach: threat-model new surfaces, review code for security, scan dependencies and containers in CI, test the deployed application independently, and monitor the result. The controls below are the ones procurement teams ask about most often.
Secure development lifecycle
01
Threat model
New surfaces are reviewed before build.
02
Secure code
Peer review and secure-coding standards.
03
Automated scan
Dependencies, containers, and configuration in CI.
04
Independent test
Third-party penetration testing.
05
Controlled deploy
Immutable images and rollback paths.
06
Monitor & review
Runtime signals and post-incident learning.
Independent penetration testing
Third-party testing against the live application and APIs. Executive summaries and remediation evidence are available under a mutual NDA.
Request the reportContinuous vulnerability scanning
Dependency, container, and configuration scanning runs in CI. Findings are triaged by severity and fixed before release where the risk requires it.
Read our standards99.9% application uptime
A 99.9% monthly availability commitment for the application and public verification pages, with a public status page and incident history.
View statusSecure public cloud infrastructure
DigitalOcean compute and managed data services, protected by Cloudflare's WAF, CDN, and DDoS controls. We do not operate our own data centres.
View subprocessorsData encryption
TLS protects data in transit. AES-256-GCM protects sensitive fields at rest. Signing keys and provider secrets are never exposed through the API.
Read about encryptionPasswordless by design
There is no password to steal. Sign-in uses a one-time email code or Google. Enterprise workspaces can enforce SSO and their existing 2FA or MFA policy.
Read about identityDisaster recovery
Documented recovery procedures cover the application, database, and credential records. Recovery arrangements are reviewed after material change and can be discussed with your procurement team.
Request the overviewIncident response
A severity-based process covers containment, customer notification, remediation, and post-incident review. Security incidents are handled with the same urgency as product incidents.
Request the overviewResponsible disclosure
A published whitehat policy with a direct security contact, clear scope, safe harbour, and coordinated disclosure. Reports are reviewed by the engineering team.
Read the policy06 / Infrastructure reliability
Built to recover, not only to run.
The platform is deployed on specialist public infrastructure with health checks, rolling releases, and independent email routes. Application services are designed to scale with issuance volume, while business-continuity and recovery procedures are documented for the application, database, and credential records. Open Badge 3.0, W3C Verifiable Credentials, and optional blockchain anchoring let the integrity proof outlive this platform.
99.9%
Committed uptime SLA
Monthly availability target for the application and verification pages.
99.99%
Demonstrated uptime
Measured at the public application and verification endpoints since May 2026.
0
Reported security incidents
No reported security incidents to date.
A public cloud foundation
DigitalOcean provides compute and managed data services. Cloudflare provides the WAF, CDN, DDoS protection, and email delivery routes. Both are independently operated and independently audited.
View subprocessorsData residency you choose
India is the default region. EU and US residency are available on request and selected when your workspace is provisioned, so the location is known before you issue.
Request a regionResilience built in
Containerised services with health checks and image-pinned deployments, independent email delivery routes, immutable published designs, and documented recovery procedures.
Read our standardsUptime figures are rounded and measured monthly. Current health and incident history are published on the status page.
status.verifycate.com07 / Privacy and your data
Privacy is a design constraint, not a policy attachment.
We process the minimum required to issue and verify a credential: the recipient fields you choose, your account details, and the operational records needed to run the service.
We do not sell personal data, and we do not run third-party advertising trackers in the application. Our practices are designed to meet the obligations of GDPR, UK GDPR, the India DPDP Act, CCPA/CPRA, and COPPA where they apply, and the privacy standards enterprise procurement and RFP teams expect.
We take that responsibility seriously, and we expect to be held to it.
Your organisation remains the controller. Verifycate acts as a processor for recipient data, under a DPA, and supports the rights your privacy team is responsible for.
DPA on request
A standard Data Processing Agreement is available for your procurement file. Verifycate acts as your processor.
Request a DPAData residency selection
India by default. EU and US residency are available on request for workspaces that need them.
Request a regionData-subject request support
We support access, correction, and deletion requests for recipients, working with the issuer who controls the data.
Contact privacyNo sale. No ad trackers.
We do not sell personal data and do not run third-party advertising trackers in the application. Website analytics are described in the Cookie Policy.
Read the Cookie PolicyFrameworks and regulations
These labels reflect our self-assessment against each framework. They are not third-party certifications, and they do not replace your own legal assessment.
For a specific transfer mechanism, retention question, or data-subject process, write to [email protected].
GDPR & UK GDPR
Lawful processing, a standard DPA, appropriate transfer safeguards, and support for data-subject rights.
Compliant
India DPDP Act
Consent-aware processing, purpose limitation, and support for data-principal rights.
Compliant
CCPA / CPRA
Access, correction, deletion, and non-discrimination for California residents.
Compliant
COPPA
Safeguards for programmes that involve minors, applied with the issuer and its consent obligations.
Supported where applicable
08 / Agreements and privacy documents
Everything procurement needs.
The policies, agreements, and evidence your security review will ask for. If a document is missing, request it and we will send it or tell you that it does not exist.
Privacy Policy
How we collect, use, share, and protect personal information.
Read policyTerms of Service
The agreement that governs access to and use of Verifycate.
Read termsData Processing Agreement
A standard DPA for customers who process personal data through Verifycate.
Request a DPASubprocessors
Every third party that processes data for us, what it does, and why it is used.
View subprocessorsCookie Policy
The cookies and similar technologies used on the website and in the application.
Read policyCompany Details
Legal entity, registration details, and company contact information.
View company detailsSecurity Standards & Policies
Identity, access, encryption, audit logging, and our current attestation status.
Read standardsResponsible Disclosure
Scope, safe harbour, and what to expect when you report a vulnerability.
Read policySecurity Pack
Questionnaire responses, architecture overview, penetration-test summary, and supporting evidence.
Request the packAlso available on request
Architecture overview, data-flow diagram, completed security questionnaire, penetration-test summary, and business-continuity overview.
09 / Questions
Questions your security team will ask.
If the answer you need is not here, ask us directly. We answer questionnaires and security reviews, and we will tell you where a control does not exist.
Ask a security questionAre you SOC 2 or ISO/IEC 27001 certified?
Not today. Our controls, contracts, and operating practices are aligned with the SOC 2 Trust Services Criteria and ISO/IEC 27001. We do not hold either attestation, and we do not display certification marks we have not earned. If your process requires a certificate, tell us early and we will be direct about whether we can meet it.
Can we review your penetration test?
Yes. We share the executive summary and remediation evidence under a mutual NDA. Write to [email protected] with your procurement contact and the scope your review requires.
Where is our data stored?
India by default. EU and US residency are available on request and are selected when your workspace is provisioned. Our current subprocessors and their roles are listed at verifycate.com/subprocessors.
Do you sign a DPA?
Yes. A standard Data Processing Agreement is available on request. Verifycate acts as a processor for recipient data; your organisation remains the controller.
How do you handle data-subject requests?
We support access, correction, and deletion requests for recipients. Because the issuer controls the certificate data, we work with you to verify and action the request. Write to [email protected].
Do you sell data or use advertising trackers?
No. We do not sell personal data and do not run third-party advertising trackers in the application. The analytics used on the website are described in the Cookie Policy.
What happens to certificates if we stop using Verifycate?
Issued verification pages remain available, and you can export recipient data. Certificates carry signed Open Badge 3.0 and W3C Verifiable Credentials data. Blockchain-anchored certificates also have an integrity proof that is independent of our platform.
How is blockchain anchoring privacy-safe?
Only a cryptographic hash is written to the ledger. Names, email addresses, and credential contents stay off-chain, which keeps correction and erasure enforceable. Read the technical note at verifycate.com/glossary/blockchain-certificate.
Who can access our workspace?
Only members you invite, with roles scoped to your workspace. Platform staff access is least-privilege and recorded in a separate audited admin surface. Pro workspaces can enforce SSO and provision members through SCIM.
Can you complete our security questionnaire?
Yes. Send it to [email protected]. We answer directly and will tell you where a control does not exist rather than overstate it.
How do we report a vulnerability?
Email [email protected]. Our responsible disclosure policy sets out the scope, safe harbour, and what to expect. We do not run a paid bug bounty programme.
Procurement
Bring your security review.
Send the questionnaire, the RFP, or the list of documents your process requires. We will respond with the evidence we have and a clear answer where we do not.