Security & Compliance

Single page for IT and security teams. If you're reviewing Buildability™ for installation on your city or organization site, this page consolidates everything your security team typically asks: data flow, encryption, hosting, subprocessors, accessibility, attestation status. Sections below are factual and reviewable. Reach team@buildability.us for a deeper review.

1. At-a-glance

The fastest way to clear Buildability™ for installation. Each row links to the relevant section below.

Last reviewed: October 2, 2026. We re-attest this page quarterly. For anything this page does not answer, email team@buildability.us.

2. Data flow

What the widget collects

The Buildability™ embeddable widget runs in the browser and queries our /api/report endpoint with the address the resident types, plus two optional choices: the project they picked (an ADU, a fence…) and the language.

• Address — passed to the geocoder and authoritative data partners, and stored with the resulting report facts when the lookup succeeds (see below).
• No name, no email, no IP-keyed identifier from the resident. Widget lookups are rate-limited against the partner's account, not the resident's IP address.
• No third-party trackers loaded by the widget.

What the widget does NOT collect

• No PII (Social Security number, driver license, financial data — not requested, not stored).
• No biometrics, no location services, no accelerometer or device sensor data.
• No advertising identifiers, no fingerprinting.

What the city sees

A city's console shows what residents asked about, as daily counts of project × answer × zoning district — for example, "12 ADU questions in R-1-8, 9 answered from the code." No address, parcel, or visitor identifier is stored with these counts. The console also lists the websites the widget has loaded on (the site's origin only, such as https://www.yourcity.gov), so staff can see where it is installed and whether it is blocked.

Payments

If a resident buys the full report, Stripe processes the payment. Card details go to Stripe directly and never reach our servers. The city's share is recorded with the purchase; the resident's card details are not.

What we store server-side

When a lookup succeeds, the address, coordinates, APN, and the resulting public-record report facts are persisted in a shared parcel-facts cache for up to 7 days of cache freshness, so repeat lookups of the same parcel are served instantly without re-querying paid data partners. This cache is keyed to the parcel, not to the visitor: no name, email, session identifier, or IP address is stored with it. Failed lookups are not persisted.

What we log

For service operations only: HTTP method, status code, response time, and anonymized request counts per partner ID, in our hosting provider's operational logs. We use these for incident response and aggregated service-health metrics.

3. Encryption and infrastructure

In transit

• TLS 1.2 minimum, TLS 1.3 preferred, on all connections (HTTPS only; HTTP requests are 301-redirected).
• HSTS header set with includeSubDomains.
• No mixed content; widget script is served from buildability.us over HTTPS only.

At rest

• AES-256 encryption on all data at rest (Supabase managed Postgres + storage).
• Database backups are encrypted and region-locked to the United States (Supabase managed backups).
• Secrets managed via environment variables (Netlify + Supabase) — never committed to source.

Hosting

• Frontend + API: Next.js on Netlify (global CDN, US-region origin; API routes run as Netlify serverless functions).
• Database + auth: Supabase (US East region).
• Federal data sources are queried directly from their public APIs — no third-party intermediary.

Request isolation

Each /api/report request runs in a Next.js API route on Netlify's serverless functions. No long-lived process state is shared between requests beyond the database-backed cache described above.

4. Privacy and resident data handling

CCPA

ReadyPermit.AI, Inc. is a Delaware corporation based in Utah, doing business as Buildability. We do not sell or share resident data. CCPA Right to Know, Right to Delete, and Right to Opt-Out are honored — see our Privacy Policy for the resident-facing process.

GDPR posture

The product is US-focused. We do not knowingly market to or collect data from EU residents via the widget. Hosted partners on cities running our widget retain primary controller status for any data their site collects independently.

City-as-controller (when widget is deployed)

When a city embeds the Buildability™ widget on a .gov page, the city remains the data controller for its visitors. ReadyPermit operates as a processor for the address-lookup service. A signed Data Processing Agreement (DPA) is available on request — email team@buildability.us.

5. Accessibility (Section 508 / WCAG 2.2 AA target)

Federal civic deployments require Section 508 compliance. We are working toward WCAG 2.2 AA across the embeddable widget surface and the hosted city page at /in/[city]. We do not claim full conformance yet. The widget's text and controls passed a WCAG AA contrast check in October 2026, and a city's own brand colour is adjusted automatically until it passes too. Focus management elsewhere on the site is still being finished.

• Keyboard navigation across interactive elements (search, expand/collapse, modal triggers); modal focus management is being completed.
• Screen-reader semantics on data fields (ARIA labels, role attributes, live regions for status updates).
• Color contrast: targeting AA (4.5:1 body text, 3:1 large text and graphical components); known low-contrast microcopy is being remediated.
• Reduced-motion preference honored — animations disable when users opt out at the OS level.
• No flashing content above the WCAG 2.3.1 threshold.
• Periodic accessibility audits (most recent: July 2026). For the current status summary, email team@buildability.us.

Detailed accessibility statement: buildability.us/accessibility.

6. Subprocessors

The vendors below process data on our behalf to deliver the service. We do not authorize new subprocessors without 30 days' notice to enterprise customers.

7. Vulnerability disclosure

Found a security issue? Please report it before any public disclosure. We commit to acknowledging in-scope reports within one business day and providing a fix or mitigation timeline within five business days.

• Email: team@buildability.us
• In-scope: buildability.us, *.buildability.us, the widget JS, and the Next.js API routes.
• Out-of-scope: third-party government data sources we proxy (report those upstream to the agency).
• Safe-harbor: good-faith research that doesn't access real user data and doesn't degrade service is welcome.

8. Compliance pack

For procurement and IT review, we maintain a packet of documents available on request:

• Security overview PDF (this page, formatted for offline review)
• Sample Data Processing Agreement (DPA) template
• Pre-filled vendor security questionnaire (CAIQ-Lite + custom city items)
• Accessibility status statement (working toward WCAG 2.2 AA — current gap list)
• Subprocessor list with current contracts

Request the pack. Email team@buildability.us with your city/organization name and IT reviewer contact. We respond within one business day.

Email me the pack

9. Contact for security teams

The fastest way to reach a human on our security side:

• team@buildability.us — security questions and vulnerability reports
• team@buildability.us — DPA, MSA, vendor onboarding, compliance pack
• Response SLA: one business day for initial acknowledgement; five business days for substantive technical responses.

For non-security questions, start with a free property score or email the team.