Security, Privacy & U.S. Data Residency

Customers with a contractual U.S.-only data residency requirement should raise it during contracting so the commitment is recorded in the agreement.

Each customer organization is a distinct tenant. Isolation is enforced by PostgreSQL row-level security (RLS) policies — every read and every write is scoped to the requesting user's organization memberships by the database itself, not by application query code. A defect in an application-layer filter therefore cannot produce cross-tenant data exposure.

• Insert and update policies validate that referenced parent records (plans, goals, initiatives, budget lines) belong to the same organization, which prevents a record from being re-pointed into another tenant.
• Table-level privileges are granted explicitly per role; no blanket schema grants are relied upon.
• Sensitive values — webhook secrets, integration tokens, embed tokens, domain verification tokens, API key hashes — are not readable through the public data API. Only server-side code with elevated privileges can read them.
• Storage objects are namespaced per organization, and update policies prevent moving a file between organization folders.

Roles are stored in a dedicated authorization table and evaluated by a security-definer database function. They are not stored on the user profile — this is the pattern that prevents privilege escalation by profile edit.

In transit: TLS for all client-to-application and application-to-database traffic. HSTS, X-Content-Type-Options: nosniff, Referrer-Policy and X-Frame-Options are set on both the managed origin and the U.S. front door. At rest: provided by the underlying managed database and object storage services.

• Workspace activity is recorded in an audit log (who changed what, and when).
• A nightly automated quality assurance sweep exercises application functionality and reports regressions to an internal dashboard.
• Application and server-function errors are captured centrally.
• Operational logs are retained for a limited period for security and debugging.

Customers retain ownership of the data they enter. Stated retention behavior:

See Subprocessors for who else processes data, and Incident response for notification commitments.

• StrategyHub™ does not use customer data to train any model.
• AI features send only the specific strategy text needed for the request, server-side, using a StrategyHub™ API credential. Customer content is not published to public models.
• Requests route through the Lovable AI Gateway to Google Gemini models. Model-provider retention is governed by that provider's commercial API terms; StrategyHub™ does not assert a zero-retention guarantee.
• AI features are per-request and optional. A customer that prefers no model processing of its strategy content can leave them unused and the rest of the platform functions normally.

Reviewers should treat these as open items rather than assume coverage:

1. No SOC 2 Type II report. Not currently in scope or in progress.
2. No ISO 27001 certification.
3. No third-party penetration test report. Internal security scanning and RLS review are performed continuously; an external test has not yet been commissioned.
4. No published RPO/RTO or disaster recovery test evidence. Backups are managed by the platform provider; recovery objectives are not contractually stated.
5. No FedRAMP, StateRAMP, CJIS or HIPAA authorization. Do not use StrategyHub™ for workloads requiring these.
6. Subprocessor processing regions are not all contractually pinned to the United States, though production data storage and outbound email are.
7. VPAT / accessibility conformance report is not yet published as a standing document; requests are answered individually. A HECVAT-Lite style answer set is published.

StrategyHub™ is not designed for and should not be used to store regulated health information (PHI), payment card data, FERPA-restricted education records, or classified information.