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.
| Vendor | Role | Region | Certifications |
|---|---|---|---|
| Vercel | Application hosting + edge network + Blob storage | US (multi-region) | SOC 2 Type II · ISO 27001 |
| Neon | PostgreSQL 17 + PostGIS managed database | AWS us-east-1 | SOC 2 Type II · ISO 27001 |
| GitHub | Source control + CI workflows (GitHub Actions) | US | SOC 2 Type II · ISO 27001 · FedRAMP |
| Mapbox | Address geocoding + map tiles + static images | US | SOC 2 Type II |
| Anthropic | Claude vision API for AI roof inspection (beta) | US | SOC 2 Type II |
| Resend | Transactional email delivery | US | SOC 2 Type II |
| Street View static imagery (premium tier) | US | SOC 2 Type II · ISO 27001 | |
| Stripe | Payment processing (when subscription billing is enabled) | US | PCI-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:
- Containment. Affected credentials are rotated immediately. Compromised endpoints are disabled at the Vercel layer. Database access is restricted as needed.
- Assessment. Logs in Vercel, Neon, GitHub, and Resend are reviewed to determine scope, affected records, and timeline.
- 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.
- 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:
| Framework | Status | Notes |
|---|---|---|
| SOC 2 Type I | In progress | Readiness phase — automated evidence collection in setup |
| SOC 2 Type II | Planned | Audit scheduled after first carrier contract milestone |
| TCPA compliance | Active | Express written consent captured + logged on every lead form |
| CCPA / state privacy | Active | See the privacy policy; request portal available on demand |
| GDPR | Out of scope | HailScore 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:
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.