Home / Security

A verification platform is only as good as what it protects.

Stamp asks your customers to put their identity behind your claims. That is a serious request, and this page describes, plainly, how we honor it: what we store, who can see it, what our infrastructure inherits, and what we will not do.

LAST REVIEWED: JUNE 2026 · QUESTIONS: VERIFY@STAMPCERTIFIED.COM

The model

Three things worth attacking. Three things we defend.

01 · Identity

Your customer's identity

The person who confirmed the claims. Their identity is the most sensitive thing on the platform, especially when the certificate is anonymous.

02 · Integrity

The certificate record

What was confirmed, by whom, and when. If a certificate could be quietly altered, nothing else here would matter.

03 · Consent

The right to change your mind

Consent that cannot be withdrawn is not consent. Retraction is a guaranteed mechanism, not a support ticket.

Identity and personal data

What we hold, and how it is protected.

Especially for anonymous certificates, the gap between "Jane Doe, Head of Procurement at a named company" and "Jane D., enterprise SaaS" is the entire promise. Here is how that gap is enforced.

What we actually keepPer verified reference customer we store: their name, work email address, employer name, LinkedIn profile URL, the job title and profile photo URL that LinkedIn returned, and a record of which consent option they chose. That is the entire set. We do not hold ID documents, passport scans, payment details, biometrics, or anything else uploaded by the customer. Everything in the verified-customer record comes from the LinkedIn OAuth handshake the customer initiated themselves.
Separated record, reviewer-only readsThe verified-customer record is held in a separated table with row-level security. Reads are restricted to authenticated Stamp reviewers; anonymous clients receive an empty result. Public pages, embeds, and the API only ever see the display fields the customer consented to publish.
Local redaction (prescreen flow)When a vendor submits a customer asset for prescreening (a PDF, a URL, a document), the extracted text is redacted locally on our infrastructure before any AI call. The model that reads it works from anonymised text. Customer-authored capture responses are written by the customer themselves, with consent, and pass to the AI as they typed them.
Anonymous displayWhen a customer chooses anonymity, the public certificate exposes only a coarse display identity (initials, industry, company size band). For anonymous asset types the name, role, and company columns are scrubbed to NULL at the data layer, not just hidden in the UI. The mapping back to the verified person is held only inside the reviewer-only record above.
EncryptionData is encrypted in transit (TLS) and at rest (AES-256) on our database infrastructure. No plaintext path to the verified-customer record exists.
AccessProduction access is restricted to named individuals and gated through our infrastructure providers' authentication controls. Reviewers see what review requires, nothing more.
Subprocessors

Who sees what.

Every third party in the verification path sees the minimum required for its role. No subprocessor receives the full picture.

ServiceRoleWhat it processes
SupabaseDatabase, authentication, storageApplication data, encrypted at rest. EU region (Frankfurt)
VercelHosting and deliveryApplication traffic over HTTPS; no persistent customer data store.
AnthropicAI drafting and prescreeningPrescreen text after local redaction; capture responses as the customer typed them.
DigiCertRFC 3161 timestampingA cryptographic hash of the certificate. Never the content itself.
ResendTransactional emailRecipient address and the message being sent.
KvK (NL business registry)Business verificationA KvK number lookup. Public registry call, no disclosure.
VIES (EU VAT)Business verificationA VAT number lookup. Public registry call, no disclosure.
LinkedInIdentity sign-in (OAuth)OAuth sign-in only; we receive the profile identity, LinkedIn receives no certificate data.
Infrastructure

What we inherit, and where their certification ends.

Stamp runs on independently audited infrastructure. Those audits belong to the providers and cover their platforms; we state them here as inherited controls, not as our own.

Supabase

Database, authentication, storage
  • SOC 2 Type 2 attested, audited annually
  • ISO 27001 certified
  • AES-256 encryption at rest, TLS in transit
  • Stamp's project is hosted in the EU region (Frankfurt)
security.supabase.com →

Vercel

Application hosting and delivery
  • SOC 2 Type 2 attested (security, availability, confidentiality)
  • ISO 27001:2022 certified
  • HTTPS enforced on every deployment
  • DDoS mitigation and platform firewall
security.vercel.com →

The honest boundary:our providers' SOC 2 and ISO 27001 attestations cover their platforms, not the application we build on top of them. Stamp itself does not currently hold a SOC 2 attestation. The controls that are ours, the identity vault, redaction, access policies, and audit logging described on this page, are our responsibility, and we describe them here so you can judge them directly.

Certificate integrity

Why a certificate cannot be quietly rewritten.

Content hash

The asset carries a fingerprint

Each verified asset records a cryptographic hash of its canonical text on the certificate row. Tampering with the asset content invalidates the recorded hash; the verify page exposes the hash so third parties can re-derive it.

RFC 3161 timestamp

An independent clock

The hash is timestamped by DigiCert's timestamping authority. This proves the certificate existed, unchanged, as of a date; it is an integrity anchor, not a truth oracle.

Decision log

Reviewer decisions are recorded

Every reviewer approve / flag / reject decision is recorded with the reviewer's identity and a timestamp. Certificate status transitions (issuance, withdrawal, expiry) are timestamped on the certificate record. How verification works →

Consent, retraction, retention

The customer's rights are mechanisms, not policies.

Informed consentBefore the customer's draft moves to publication, a consent screen names every field that publishes in each option (named: name, title, company; anonymised: seniority, function, and company type only). The customer picks the consent level there.
RetractionOne click from any past email, no account needed. The public record updates and embeds on vendor sites step down to a neutral state. The vendor is notified immediately.
RetentionVerified-customer records carry a retention timestamp, defaulted to three years from creation, supporting verifiability for as long as the certificate is live. Withdrawn and expired records retain only what the audit trail requires.
GDPRStamp is operated from the Netherlands with data hosted in the EU. Access, rectification, and erasure requests go to verify@stampcertified.com and are handled within statutory timelines.
A current limitation, stated plainly

The retention timestamp is populated on every record, but no automated purge runs on it yet. Deletion and data-export workflows are handled by hand today, by a named operator, within the statutory window. Automating the purge into the daily expiry cron is on the engineering roadmap. We would rather tell you this here than have you discover it in a request.

Commitments

What we will not do.

Sell or share reference-customer identity data. Not to vendors, not to data brokers, not in aggregate. The identity vault is not an asset; it is a liability we guard.
Accept payment for a verification outcome. Reviewers do not see billing status. You pay for capacity, never for the verdict.
Let a vendor edit a confirmed claim.After the customer confirms, the quote and metrics are immutable. The customer's words publish verbatim or not at all.
Expose an anonymous reference customer.Not to the vendor's competitors, not to the vendor, not under commercial pressure. De-anonymisation would end the platform, and we treat it that way.
Train AI models on identity data.Drafting uses the customer's own answers and (for prescreen) redacted text; identity data is never used for model training, ours or anyone's.
Responsible disclosure

Found something? Tell us.

We welcome good-faith security research. Report vulnerabilities directly and we will respond, credit you if you want it, and never take legal action against good-faith research.

verify@stampcertified.com