Security

Customer accounts, scan history, scheduled scans, and team memberships all live in a dedicated Supabase project (managed Postgres) hosted on AWS us-east-1. Supabase is SOC 2 Type II audited and HIPAA-capable(we don’t use the HIPAA tier; mentioned for context).

The application layer is hosted on Vercel (also SOC 2 Type II audited). Static assets are served via Vercel’s edge network; serverless functions execute in US regions.

Customer scan output, profile data, and authentication metadata never leaves AWS us-east-1. We do not currently offer EU-region hosting; customers with EU data-residency requirements should contact us before signing up.

In transit:TLS 1.2 minimum on every customer-facing endpoint. We rely on Vercel’s automatic Let’s Encrypt certificates and HSTS headers. Internal service-to-service traffic (app → Supabase, app → Stripe, app → Resend) is also TLS-encrypted.

At rest:AES-256. Postgres data is encrypted by Supabase’s underlying AWS RDS; backups are also encrypted. Vercel encrypts function code, env vars, and build artifacts at rest.

Sensitive env vars (Stripe secret keys, Supabase service role key, Resend API key, CRON_SECRET) live only in Vercel’s encrypted environment variable store. They’re never logged, never written to disk inside functions, and never returned in API responses.

Every customer-owned table in our Postgres schema has Row-Level Security (RLS) enabled. Every SELECT / UPDATE / DELETE goes through a policy that requires auth.uid() = user_id. There is no application-level “tenant id filter” that can be bypassed by a code bug — the database itself enforces the isolation.

Our app code uses two Supabase clients:

• User-scoped client — propagates the authenticated user’s session, hits RLS on every query. Used in all customer-facing routes.
• Admin client — bypasses RLS using the service-role key. Used only in webhook handlers, cron jobs, and admin operations. Limited to specific server routes; never reachable from client code.

Cross-tenant data exposure would require either (a) a misconfigured RLS policy, which our test suite + manual review catches, or (b) leaking the service-role key, which is gated behind Vercel’s env var encryption + would require physical access to a production deploy.

We use Stripe for all billing. Stripe is PCI DSS Level 1 certified — the highest tier. Card details never touch ClearShield servers. Customers enter card information directly into a Stripe-hosted Checkout page, served from checkout.stripe.com.

Our application receives only a customer_id and subscription_id from Stripe via webhook. To manage their subscription, customers are routed to the Stripe-hosted Customer Portal; we never display, transmit, or store PAN data.

Stripe webhook payloads are signature-verified using HMAC-SHA256 before any side effects fire (plan upgrades, customer notifications, etc).

Authentication is handled by Supabase Auth:

• Email + password — minimum 8 characters; passwords stored as bcrypt hashes (Supabase-managed)
• Email verification required — accounts can’t reach the dashboard, admin, or scan endpoints until email_confirmed_at is set
• Magic link (passwordless) — supported but not heavily promoted
• Password reset — flows through a Supabase-managed email + signed recovery URL

MFA via SSO (Okta, Azure AD, Google Workspace) is on the roadmap for Business / Enterprise tier customers. Contact us if you need SSO before we ship it natively.

Two self-serve controls available to every customer today:

• Data export — Settings → Your data produces a single JSON document containing every row we hold against your account. Satisfies GDPR Article 15 (right of access) and Article 20 (data portability), CCPA §1798.100.
• Scan deletion — Scans page includes per-row delete. Account deletion (full purge) available via the Danger Zone in Settings.

Data retention default: scan records are retained indefinitely so customers can demonstrate ongoing compliance posture over time. Customers can delete individual scans or their entire account at any time.

We do not sell, license, or share customer data with third parties for marketing or training. Sub-processors are listed below.

The third-party services that may process customer data on our behalf:

We’ll notify customers in advance (via email + this page) if we add or change sub-processors that touch personal data.

If we confirm a security incident affecting customer data, we commit to:

• Notifying affected customers by email within 72 hours of confirmation
• Publishing a post-mortem on /changelog (or a dedicated incident URL) within 30 days, with timeline + root cause + remediation
• Cooperating with customer DPIA / breach-notification obligations under GDPR Article 33 + applicable state laws

Security issues can be reported privately to security@clearshield.legal. We commit to a first response within 24 hours and to not pursuing legal action against good-faith researchers.

Today.ClearShield is pre-SOC 2. We’ve modeled our controls around the AICPA Trust Services Criteria (Security, Availability, Confidentiality, Privacy) but have not yet engaged an external auditor.

Roadmap.SOC 2 Type I targeted for Q4 2026 once we have 12+ months of operating history. ISO 27001 is on a longer timeline. Customers with hard SOC 2 requirements pre-Q4 should evaluate the engagement carefully — we’re honest that we’re not there yet.

Our underlying hosting providers (Supabase, Vercel, Stripe) all hold current SOC 2 Type II attestations, which covers the bulk of the infrastructure-layer security controls a typical procurement review cares about.

Security questions, vulnerability reports, or due-diligence requests: security@clearshield.legal.

For broader procurement / compliance review (DDQ, custom DPA, sub-processor list with full audit trail): /contactwith the “Sales” reason — we’ll route to the right human.