Information Security Policy

Civiq — operated by Woodley Labs LLC — provides a relationship and operations platform for civic organizations and nonprofits. Because we handle organizational data — including contacts, communications, and (where an organization chooses to connect it) financial transaction data — we maintain and operate the security practices described in this policy to identify, mitigate, and monitor information security risks relevant to our business.

1 Scope

This policy covers all data Civiq stores or processes on behalf of its customer organizations, the systems that store and process that data, and the people who operate them. It applies to all Woodley Labs personnel and to any third-party services Civiq relies on.

2 Data we handle and how we classify it

• Organizational data — an organization's contacts, members, events, communications, and activity records.
• Financial data (opt-in) — where an organization chooses to connect a bank account (via Plaid), the transaction data we import to provide spending analysis. This is our most sensitive class and is treated accordingly.
• Account data — user login/identity for people who use Civiq.

Financial and account data are classified as sensitive and receive the strongest controls.

3 Access control and tenant isolation

• Per-organization isolation (multi-tenant). Every customer organization's data is logically isolated. Data access is enforced at the database layer using row-level security (RLS) policies on our tables, so a user can only read or write rows belonging to their own organization/account. This is enforced by the database, not only by application code.
• Least privilege. Privileged operations are performed through controlled, audited database routines (SECURITY DEFINER functions) rather than by granting broad access. Administrative and legally-controlled fields (e.g. verification status, plan, feature entitlements) are protected by database-level guard triggers so that ordinary account owners cannot escalate their own privileges.
• Server-side secrets. API keys, access tokens, and other secrets are stored only in server-side environment/secret storage and are never embedded in client applications or source control. Third-party tokens (e.g. mailbox or bank connectors) are held server-side and are never exposed to the client.
• Authenticated access only. Sensitive server endpoints (edge functions) accept only a verified user session or a trusted service credential, and never trust client-supplied identifiers for authorization (defense against insecure direct object reference / IDOR).

4 Encryption

• In transit. All data is transmitted over encrypted connections (TLS/HTTPS).
• At rest. Data is stored on managed cloud infrastructure (Supabase / PostgreSQL) with encryption at rest provided by the platform.

5 Financial data (Plaid) — specific controls

• We access financial transaction data only through Plaid, only for organizations that explicitly connect their own account, and only to provide spending analysis and savings insights to that same organization.
• We do not sell or share consumer/organizational financial data obtained through Plaid. Financial data is used solely to deliver the service to the organization it belongs to.
• Bank connection tokens are stored server-side only; the application reads only the derived, non-secret data required to render insights.
• Financial features are gated and can be disabled per organization.

6 Auditability and monitoring

• Audit trail. Material organizational actions (financial entries, sends, exports, role changes, and similar) are recorded in an append-only compliance ledger, giving a durable, reviewable history of activity.
• We monitor our infrastructure through our cloud provider's logging and alerting, and review access and activity for anomalies relevant to our data.

7 Data retention and deletion

• Organizations own their data. We retain data for as long as needed to provide the service.
• Users and organizations may request export or deletion of their data; account deletion is supported and removes associated records per our procedures.
• Where records are subject to a customer's own legal retention obligations, deletion is handled consistently with those obligations.

8 Incident response

• If we become aware of a security incident affecting customer data, we will investigate promptly, take steps to contain and remediate it, and notify affected organizations without undue delay, consistent with applicable law.
• Post-incident, we review the cause and update our controls and this policy as needed.

9 Third-party providers

We rely on reputable providers that maintain their own security programs, including our cloud database/hosting provider (Supabase), and Plaid for financial data connectivity. We limit the data shared with each provider to what is necessary to deliver the service.

10 Personnel and change management

• Access to production data is limited to personnel who require it to operate the service.
• Changes to the platform are version-controlled and reviewed before release; security-relevant changes (access rules, data handling) receive particular scrutiny.

11 Review

This policy is reviewed periodically and updated as our platform and risk profile evolve.