Trust Center / Subprocessors
Subprocessors
A subprocessor is any third party that processes customer data on CMDash’s behalf. This list is authoritative as of . On-premise customers who run CMDash in their own infrastructure do not share data with the cloud-only subprocessors (AWS, PostHog); the list below applies in full to the CMDash Cloud offering. The exposure lookup services (Shodan InternetDB, GreyNoise, AbuseIPDB and the DNS blocklist operators) are customer-directed: they receive only the public IP addresses or domain names of assets a customer has registered for exposure monitoring, never tenant content.
Subprocessor list
| Vendor | Purpose | Data categories | Region | Legal basis |
|---|---|---|---|---|
| Amazon Web Services, Inc. | Cloud infrastructure (Lightsail compute, load balancer and managed PostgreSQL database; S3 object storage). For customers who subscribe through AWS Marketplace, AWS also resolves the subscribing AWS account, reports entitlements, and receives hourly usage quantities (AWS Marketplace Metering Service). | All customer data in cloud deployments. For AWS Marketplace subscribers: the AWS customer and account identifiers and metered usage quantities per dimension; no tenant content. | United States (us-east-1) | SCCs + AWS DPA |
| GitHub, Inc. (Microsoft) | Container registry (GHCR) and source-code hosting | Application source code; container images; no customer tenant data | United States | SCCs + Microsoft DPA |
| Stripe, Inc. | Subscription billing and payment processing | Billing contact, payment method token, invoice metadata | United States (EU processing for EEA customers) | SCCs + Stripe DPA |
| Resend, Inc. | Transactional email delivery (password reset, magic link, notifications) | Recipient email address, email body, delivery metadata | United States | SCCs + Resend DPA |
| PostHog, Inc. | Product analytics for the tenant dashboard (SaaS only — never deployed on-prem) | Opaque user and tenant identifiers, subscription tier, role, in-app feature-usage events. No names, email addresses, organization names, session recordings, or compliance/evidence content. | United States (PostHog Cloud US) | SCCs + PostHog DPA |
| HubSpot, Inc. | CRM sync for marketing leads (contact-form submissions, white-paper requests, quote-builder requests). Disabled by default (`CRM_SYNC_ENABLED=false`); this entry is disclosed regardless of the flag’s current value because the capability is shipped and this list must not lag a config change (see #554). | Name, work email, company, and message provided on the contact form, white-paper gate, or quote builder. No customer tenant/product/compliance data. | United States | SCCs + HubSpot DPA |
| Google LLC (Google Analytics 4) | Web analytics on the public marketing site (cmdash.com): page views and marketing-funnel events such as pricing and CTA clicks. In the browser, Google Analytics loads only after the visitor accepts the cookie banner (Consent Mode v2; all storage denied by default, no browser requests to Google before consent). On the app sign-up and email-verification pages it can also load to continue a visit that began on the marketing site. Separately, when the operator has configured it, CMDash servers send two conversion events (a marketing form submitted, a free account created) to the Google Analytics Measurement Protocol; those server-side events are not conditioned on the cookie banner and carry a synthetic identifier when the visitor has no Google cookie. Not loaded in the authenticated product screens or in any on-premise deployment. | Marketing-site usage data: pseudonymous client-ID cookie (after consent), page URLs, referrer, approximate location derived from IP, device and browser metadata. Server-side events: event name, campaign (UTM) parameters, region, plan tier and quote value; no names or email addresses. No customer tenant data. | United States (global collection endpoints) | Consent (cookie banner) for browser analytics + SCCs + Google Ads Data Processing Terms |
| Google LLC (Sign in with Google) | Optional OAuth 2.0 sign-in and sign-up for users who choose "Continue with Google", where the deployment has Google sign-in configured. Not used unless the user clicks it. | The Google account identifier, email address and display name returned to CMDash at sign-in; Google receives the fact that the user is signing in to CMDash. | United States (global) | User-initiated sign-in (contract) + Google API Services terms |
| Microsoft Corporation (Sign in with Microsoft) | Optional OpenID Connect sign-in and sign-up for users who choose "Continue with Microsoft", where the deployment has Microsoft sign-in configured. Not used unless the user clicks it. | The Microsoft account identifier, email address and display name returned to CMDash at sign-in; Microsoft receives the fact that the user is signing in to CMDash. | United States (global) | User-initiated sign-in (contract) + Microsoft privacy statement |
| Cloudflare, Inc. | Two narrow uses. (1) Turnstile: the bot check on app account sign-up (loaded from challenges.cloudflare.com on the registration page, and verified server-side before an account is created). (2) The 1.1.1.1 DNS-over-HTTPS resolver, used for customer-directed external-exposure DNS lookups (see the exposure-intelligence rows below). Cloudflare is not a CDN, DNS host or proxy for any CMDash site or for application traffic. | Turnstile: the challenge token, the visitor IP address and browser metadata at sign-up. DNS-over-HTTPS: the public domain names, and the reversed IP addresses for blocklist lookups, of assets a customer has registered for exposure monitoring. | Global edge | Legitimate interest (abuse prevention) for Turnstile + SCCs + Cloudflare DPA |
| Google LLC (Google Public DNS) | Fallback DNS-over-HTTPS resolver (dns.google) used for customer-directed external-exposure DNS lookups when the primary resolver fails. | Public domain names, and reversed IP addresses for blocklist lookups, of assets a customer has registered for exposure monitoring. No tenant content. | United States (global) | Public DNS query; no customer data beyond the queried name + Google Public DNS terms |
| crt.sh (Certificate Transparency log search) | Customer-directed lookup of the publicly logged TLS certificates for domains a customer registers for exposure monitoring (certificate-transparency monitoring). A failed or malformed answer is recorded as unknown, never as "no new certificates". | The registered domain name, sent as a wildcard search. No tenant content. | Not specified by the operator | Public lookup service; no DPA (query contains only a public domain name) |
| Shodan InternetDB | Customer-directed lookup of the public IP addresses behind domains a customer registers for exposure monitoring (open ports and known vulnerabilities seen by the internet scanner). Runs in the daily IP-reputation sweep for organizations whose plan includes IP reputation; needs no API key. | The public IP address being checked. No tenant content, no personal data about the customer's users. | Not specified by the operator | Public lookup service; no DPA (query contains only a public IP address) |
| GreyNoise (Community API) | Customer-directed lookup of whether a public IP address of a registered asset is seen scanning or attacking the internet. Runs in the daily IP-reputation sweep for organizations whose plan includes IP reputation; the Community endpoint needs no API key. | The public IP address being checked. No tenant content. | Not specified by the operator | Public lookup service; no DPA (query contains only a public IP address) |
| AbuseIPDB | Customer-directed lookup of the abuse-report history of a public IP address of a registered asset. Used only when an AbuseIPDB API key is configured (a key the customer supplies, or one the operator holds). | The public IP address being checked, and the API key used. No tenant content. | Not specified by the operator | Customer-directed lookup under the AbuseIPDB terms; no DPA |
| DNS blocklist operators (SpamCop, UCEPROTECT, Mailspike, PSBL, GBUDB, blocklist.de and, with a customer-supplied key, Spamhaus ZEN) | Customer-directed check of whether a public mail-sending IP address of a registered asset is listed on a DNS blocklist. These are DNS queries sent through the DNS-over-HTTPS resolvers above; the blocklist operator sees a query for the reversed IP address under its zone. | The public IP address being checked, carried in a DNS query name. No tenant content. | Not specified by the operators | Public DNS lookup; no DPA (query contains only a public IP address) |
| Anthropic, PBC | Hosted AI model (Claude) for AI-assisted policy drafting, policy-control link autosuggestion, vendor-questionnaire auto-answer, the daily AI risk narrative, AI executive-summary generation, and AI risk-remediation suggestions | Organization name (sent on every AI request); depending on feature: risk titles/descriptions (AI remediation suggestions), policy topic/scope/category and content excerpts (policy drafting and policy-control linking), evidence descriptions and vendor questionnaire text/answers (TPRM AI answer suggestions), and posture, framework, and integration-provider names (AI narrative and executive summary). No employee names, email addresses, credentials, payment data, or raw file uploads are included. | United States (data stored in the US); customer API traffic may by default be routed for processing to the US, Europe, Asia, or Australia per the Anthropic DPA | SCCs (Module 2/3) + UK/Swiss Addenda + Anthropic DPA |
Transfer mechanism
For subprocessors that process personal data outside the customer’s jurisdiction, CMDash relies on the European Commission’s 2021 Standard Contractual Clauses (Modules 2 and 3, as applicable) together with the UK Addendum where the UK GDPR applies. Swiss data flows use the same SCCs, adapted per the FDPIC recommendation. Each vendor’s own DPA is executed alongside the CMDash SCCs.
Cookies and analytics
Marketing site (cmdash.com). The site uses Google Analytics 4 with Consent Mode v2: all analytics storage defaults to denied and no browser request is sent to Google until the visitor accepts the first-party cookie banner. Accepting sets a consent cookie (cmdash_consent, 180 days) and the standard Google Analytics cookies; declining sets only the consent cookie recording the refusal. The site also sets a first-party attribution cookie (cmdash_attribution, 90 days) holding the UTM/click-ID parameters of the visitor’s first landing URL and the referrer. It is written unless the visitor has declined, it is read only by CMDash, and it is never shared with a third party. The load balancer in front of the site sets session-affinity cookies (AWSALB and AWSALBCORS, 7 days). Separately from the browser, when the operator has configured it, CMDash’s servers send two conversion events (a marketing form submitted, a free account created) to Google Analytics; those server-side events do not depend on the cookie banner.
Product application (app.cmdash.net). The authenticated product uses strictly necessary session cookies for sign-in. It also runs PostHog product analytics, which is on by default for CMDash Cloud and is not behind a cookie banner: the legal basis is CMDash’s legitimate interest in understanding how the product is used, under the customer contract. PostHog receives opaque user and tenant identifiers, plan tier, role and in-app feature-usage events (clicks on links and buttons, and which screens are used), never names, email addresses, organization names or compliance content, and session recording is off. PostHog stores an identifier in the browser’s local storage and a first-party cookie. An organization owner or admin can switch product analytics off for the whole organization in Settings, Privacy; there is no per-user switch today. On the sign-up and email-verification pages, Google Analytics loads only when the visitor arrived from the marketing site after accepting its cookie banner (the link carries Google’s cross-domain parameter); on a direct visit it loads nothing. The sign-up page also loads Cloudflare Turnstile as a bot check. On-premise deployments run none of the analytics above.
Notification of changes
Customers on the CMDash DPA can subscribe to subprocessor change notifications. New subprocessors are announced at least 30 days before they begin processing customer data, giving customers time to raise a reasoned objection under the mechanism in the DPA. To subscribe, email security@cmdash.com.
Last reviewed: . This page is the canonical subprocessor list; if you received a different list as a static document, it may be superseded.