generated: '2026-08-09' method: probed probe: true url: https://trust.cerby.com/ exists: true contents_readable: false platform: Drata platform_evidence: dns: trust.cerby.com CNAME trust.cname.drata.com detail: >- trust.cerby.com is a genuinely provisioned host, not the *.cerby.com wildcard. Control probe: zzznotreal.cerby.com returns HTTP 200 from an AWS origin identifying itself as "server: banana", while trust.cerby.com returns HTTP 403 from Cloudflare with a challenge ray and CNAMEs to Drata's trust center service. Different origin, different response — the trust center is real. access: http_status: 403 reason: Cloudflare interactive bot challenge ("Just a moment... Enable JavaScript and cookies to continue") browser_ua_retried: true outcome: >- The certification list could not be read. Cerby's own attestations, if any, live behind this challenge. certifications: [] certifications_note: >- DELIBERATELY EMPTY. No certification is attributed to Cerby because none could be verified. This is the trap on this provider and it is worth stating plainly: https://www.cerby.com/security returns 200 and does name SOC 2 Type I, SOC 2 Type II and ISO 27001 — but its section 1 is titled "CLOUD PROVIDER's Audits & Certifications", and section 1.1 reads "Cerby currently relies on its Cloud Provider's third-party reviewed Security Program". Section 1.3 goes further: "To the extent Cerby does not obtain a Third-Party Audit of its own, Cerby will adopt or maintain ... an equivalent, industry-recognized framework" — the document explicitly contemplates Cerby having no audit of its own. Harvesting those certification names would attribute a subprocessor's attestations to Cerby. They are recorded below as what they are. cloud_provider_requirements_published: relied_on_by_cerby: [SOC 2 Type I] required_of_cloud_providers: [SOC 2 Type II, ISO 27001] attributed_to: Cerby's cloud provider, NOT Cerby source: https://www.cerby.com/security security_policy: url: https://www.cerby.com/security title: Security Policy | Cerby type: contractual security addendum http_status: 200 published_commitments: - Customer Data encrypted at rest with AES 256-bit or better. - TLS 1.2 or better for Customer Data in transit over untrusted networks. - Encryption keys logically separated from Customer Data. - Customer Data hosted in the United States production cloud environment, or another mutually agreed region. - Critical and high vulnerabilities addressed within 30 days, medium within 90 days, on commercially reasonable efforts. x-evidence: - url: https://trust.cerby.com/ http_status: 403 fetched: '2026-08-09' - url: https://www.cerby.com/security http_status: 200 fetched: '2026-08-09' - url: https://zzznotreal.cerby.com/ http_status: 200 fetched: '2026-08-09' role: false-positive control