Trust & Compliance

Security at HailScore

How we host, encrypt, and access the data behind every HailScore. Where we are on the SOC 2 readiness path. Who our subprocessors are and what they're certified for. Companion document to the methodology white paper.

Last updated: May 15, 2026. This page is reviewed and updated whenever subprocessors change or compliance milestones land.

1. Data we collect & how we use it

HailScore collects three classes of data:

  • Public meteorological data. NOAA, NWS, SPC, and CoCoRaHS observations are public-domain weather records. We ingest, index, and serve them. Detailed list in the methodology paper, §3.
  • Property lookup data. When a homeowner enters an address, we store the geocoded coordinates, the score result, roof inputs, IP address, and user-agent in the scores table. This is the proprietary dataset that compounds with each lookup.
  • Lead capture data. When a homeowner unlocks the premium report, they consent (TCPA-compliant) to share name, email, and optionally phone number with HailScore and a matched contractor. Stored in leads and lead_outcomes.

We do not collect Social Security numbers, financial account information, government identifiers, or biometric data. We do not buy, sell, or rent personal data to third-party data brokers. Photos uploaded to the AI roof inspection feature are stored in Vercel Blob and are linked to the lead record; they are accessible only via signed URLs.

2. Hosting & infrastructure

The HailScore application is hosted on Vercel with deployment from a private GitHub repository. The application runs on Vercel's global edge network with primary compute in US regions. The database is Neon PostgreSQL 17 with the PostGIS 3.5 spatial extension, hosted in AWS us-east-1.

Production secrets (database connection strings, third-party API keys, cron-trigger tokens) are stored exclusively in Vercel's encrypted environment variable store and in GitHub Actions Secrets. They are not present in source control, in container images, or in any client-side bundle.

Periodic data-ingestion workloads (NOAA MRMS radar pulls, NWS alert polling, contractor digest emails) run on GitHub-hosted Linux runners via GitHub Actions, and as a redundant secondary on a hardened operator workstation. Both paths write through the same Neon connection with identical authentication.

3. Encryption

All traffic to myhailscore.com and all API endpoints is served over TLS 1.2+ with HTTPS enforced (HSTS preloaded). Insecure HTTP connections redirect to HTTPS.

The Neon PostgreSQL database encrypts all data at rest using AES-256 (managed by AWS KMS as part of Neon's storage layer). Database connections use TLS with channel binding.

Sensitive credentials are stored as cryptographic hashes only:

  • User passwords: bcrypt with default cost factor
  • API keys: SHA-256 (raw token shown to the user once at generation)
  • Magic-link tokens: SHA-256 with a TTL-bounded expiry window
  • Storm-alert subscriber tokens: per-row random tokens, stored in plaintext only because they convey opt-out authority, not authentication

4. Authentication & access control

Application authentication is implemented with NextAuth v5. Two providers are wired:

  • Credentials — email + bcrypt-hashed password for contractor and admin accounts.
  • Magic-link — single-token authentication used in lead-notification and digest emails. Tokens hash with SHA-256, expire on a TTL (48 hours for lead notifications, 7 days for digests), and are scoped to the contractor account that received the email.

Session tokens are JWT with secure-only and HTTP-only cookie attributes. Cross-origin requests to the API surface require either a valid session cookie or an API key bearer token.

Production database access is limited to:

  • The Vercel-deployed application via the Neon connection string
  • The two ingestion environments (GitHub Actions, operator workstation) using the same connection string
  • The HailScore founder (Alex Chicilo) for operational queries, audit, and migrations

All third-party platform accounts (Vercel, Neon, GitHub, Resend, Mapbox, Anthropic, domain registrar) have multi-factor authentication enforced. Account passwords are stored in a managed password vault. Access is reviewed when team composition changes.

5. Subprocessors

The following subprocessors handle data on behalf of HailScore. Each is independently certified as noted; HailScore relies on these certifications under SOC 2's "complementary subservice organization controls" model. Material changes to this list (additions, removals, or category changes) are reflected here within seven days.

VendorRoleRegionCertifications
VercelApplication hosting + edge network + Blob storageUS (multi-region)SOC 2 Type II · ISO 27001
NeonPostgreSQL 17 + PostGIS managed databaseAWS us-east-1SOC 2 Type II · ISO 27001
GitHubSource control + CI workflows (GitHub Actions)USSOC 2 Type II · ISO 27001 · FedRAMP
MapboxAddress geocoding + map tiles + static imagesUSSOC 2 Type II
AnthropicClaude vision API for AI roof inspection (beta)USSOC 2 Type II
ResendTransactional email deliveryUSSOC 2 Type II
GoogleStreet View static imagery (premium tier)USSOC 2 Type II · ISO 27001
StripePayment processing (when subscription billing is enabled)USPCI-DSS Level 1 · SOC 2 Type II

The HailScore scoring algorithm itself is implemented in our own application code; no third-party scoring or modeling service is in the data path between a lookup request and the score returned to the user.

6. Backups & disaster recovery

The Neon database uses point-in-time recovery with a 7-day window on the production branch. We can restore the database to any second within that window. Backups are stored encrypted at rest within Neon's managed infrastructure (AWS).

Source code and CI workflows are versioned in GitHub with full revision history. Production deployments are immutable Vercel deployments; any deployment can be rolled back instantly from the Vercel dashboard or via git revert.

Critical data assets (ingested weather records, score history, lead outcomes) are append-only or soft-delete in design. Hard-delete operations on the scores, leads, and lead_outcomes tables require explicit operator confirmation per internal policy.

7. Vulnerability management

  • Application dependencies are scanned via npm audit on every install and reviewed on a regular cadence.
  • GitHub Dependabot is enabled for the source repository; security advisories surface as pull requests for review before merge.
  • Application code uses TypeScript with strict mode and ESLint enforcement; no any escapes without explicit annotation.
  • Production endpoints serving user content carry per-route abuse defenses: rate limiting (per IP, per session, per API key), input validation, and content-type enforcement. The AI roof inspection endpoint additionally caps daily spend, lifetime usage per lead, and IP rate.
  • Schema changes are gated by review and applied only with explicit operator sign-off. Migrations against the scores table — the proprietary dataset — require a documented plan and reviewed SQL.

8. Incident response

In the event of a confirmed security incident:

  1. Containment. Affected credentials are rotated immediately. Compromised endpoints are disabled at the Vercel layer. Database access is restricted as needed.
  2. Assessment. Logs in Vercel, Neon, GitHub, and Resend are reviewed to determine scope, affected records, and timeline.
  3. Notification. Affected users are notified by email within 72 hours of confirmation, per applicable state breach-notification statutes. Carrier and contractor partners are notified by individual email and via subprocessor agreements.
  4. Remediation. Root cause is identified, fixed, and documented. A post-incident review is published internally with action items tracked to completion.

Security telemetry is reviewed by the HailScore operator daily during active development periods and after any operational anomaly (failed cron run, elevated error rate, unexpected database load).

9. Compliance roadmap

HailScore is honest about where it stands. As of May 15, 2026:

FrameworkStatusNotes
SOC 2 Type IIn progressReadiness phase — automated evidence collection in setup
SOC 2 Type IIPlannedAudit scheduled after first carrier contract milestone
TCPA complianceActiveExpress written consent captured + logged on every lead form
CCPA / state privacyActiveSee the privacy policy; request portal available on demand
GDPROut of scopeHailScore serves US addresses only; non-US users are blocked at geocode

HailScore will pursue SOC 2 Type I when a partner or customer engagement requires it, and will move to Type II within the audit window following the first carrier contract. Until certificates are issued, we will provide our security questionnaire response (covering CAIQ-Lite and SIG-Lite categories) on request under NDA.

10. Report a security issue

If you believe you have found a security vulnerability affecting HailScore or its users, please report it directly to:

Security contact
myhailscore@gmail.com
Subject line: [SECURITY] <short description>

We commit to:

  • Acknowledging receipt within one business day
  • Triaging the report and confirming validity within five business days
  • Providing a remediation timeline appropriate to severity
  • Crediting reporters by name (if desired) in a public acknowledgments section once an issue is fixed

We ask that you do not publicly disclose the vulnerability until we have had a reasonable opportunity to remediate. We do not currently offer a paid bug bounty but are happy to discuss compensation for material findings.


Questions about HailScore's security posture not answered here can be sent to myhailscore@gmail.com. Carrier and adjuster security teams may request a security questionnaire response or a copy of our DPA under NDA.