CivicPool Data Security

Version 1.0, 15 September 2026. Effective date: on publication by CivicPool; the current version is shown in the app and the console.

CivicPool is operated by a partnership of African Wood Inc. (United States and Kenya), African Wood Limited (England and Wales) and Dhamana Technologies Limited (Kenya), together "CivicPool", "we", "us" and "our".

This statement describes, for tenant societies and their members, how CivicPool protects the personal and financial data entrusted to it. It was adopted under founder decision 38 (15 September 2026). Technical detail is grounded in docs/CivicPool-Platform-Plan-v2.md §§ 5.3–5.4 and packages/integrations/README.md; it will be kept current as the platform's security posture evolves.

1. Architecture summary

CivicPool is a multi-tenant platform hosted entirely on Google Cloud, region us-east1, so tenant and member data stays resident in the United States. The stack: a global HTTPS load balancer and Cloud Armor (web application firewall, rate limiting, geo rules) in front of Cloud Run services (the API and web app), a private-IP, high-availability Cloud SQL PostgreSQL database, Cloud Storage for documents and evidence, Secret Manager for credentials, Cloud KMS for encryption keys, and a locked Cloud Logging sink feeding an immutable audit trail. Identity-Aware Proxy gates every administrative surface. See docs/CivicPool-Platform-Plan-v2.md § 5.3 for the full diagram.

2. Encryption

At rest: all storage — the database, document storage, and backups — is encrypted using customer-managed encryption keys (CMEK) issued per tenant through Cloud KMS, rather than relying solely on the cloud provider's default keys.
In transit: all connections to the platform (web, mobile app, API, and webhook traffic from Stripe and other providers) use TLS.
Column-level encryption: personal fields (names, contact details, relative data, government identification numbers, bank account references) are encrypted at the column level using each tenant's own key, so that plaintext personal data exists only transiently in application memory and never sits in the database or storage layer unencrypted.

3. Tenant isolation

All tenants share one database instance, but every table carries a tenant_id and row-level security (RLS) policies enforce that a request can only read or write rows belonging to its own tenant, at the database layer — not merely in application code. Schema-per-tenant isolation is available on request for a tenant with heightened requirements. Each tenant's encryption key is also separate, so a key compromise for one tenant does not expose another's data.

4. Sign-in and session security

One-time codes: sign-in begins with a one-time code sent by SMS or e-mail to the phone number or address on file.
Passkeys and biometrics: after the first sign-in, users authenticate with a passkey (web) or device biometrics (companion app), reducing reliance on passwords and codes for routine access.
Session revocation: every account can see its active sessions/devices and revoke any of them; an administrator or the platform can also revoke a session it believes is compromised. The companion app additionally times out an inactive session after a short background period, uses certificate pinning, detects rooted/jailbroken devices (with a warning, not a hard block), and blocks screenshots on document screens (docs/CivicPool-Companion-App.md).

5. Two-person rules for disbursements

No single person can move money out of a tenant's agency fund. Every disbursement requires two distinct officers who are not household members of each other (enforced by a relationship flag on officer accounts): one to initiate and one, independent, to approve. Money-movement approvals additionally require biometric step-up in the companion app. See docs/CivicPool-Platform-Plan-v2.md § 5.2.

6. Audit logging

Every action that changes data — enrollment, validation, a call, a payment, a disbursement, a policy change — is written to an append-only, hash-chained audit_events record, backed by a locked (write-once) Cloud Logging sink that even a platform administrator cannot alter or delete. This lets a tenant, an auditor, or a regulator verify that the recorded history has not been tampered with after the fact.

7. Retention-locked storage

Evidence documents (death certificates, notices, notarized forms), Call Sheets, and statements are stored in Cloud Storage buckets with Bucket Lock retention policies, which prevent deletion or modification before the retention period expires — including by CivicPool's own operations staff. This backs the seven-year retention described in docs/legal/Privacy-Policy.md.

8. Backups, point-in-time recovery, and restore drills

The production database runs in a high-availability configuration with automated backups retained for 35 days and point-in-time recovery, so a tenant's data can be restored to any moment within that window. CivicPool performs a quarterly restore drill — actually restoring a backup and verifying it — rather than relying on backups never tested.

9. Least-privilege access

Cloud Run services authenticate to other Google Cloud services using Workload Identity rather than long-lived static credentials, and each service account is scoped to only the permissions it needs (for example, the API's service account can create and rotate only its own provider secrets, not arbitrary project secrets, enforced by an IAM condition on the secret name prefix — see packages/integrations/README.md). CivicPool's own staff do not have standing access to tenant personal data in normal operation; any emergency ("break-glass") access is logged, time-boxed, and visible to the affected tenant.

10. Secret management

Provider credentials (Stripe, e-mail, SMS, WhatsApp, notarization, push, and AI integration keys) are never stored in application database tables. They are written to Google Secret Manager under a deterministic, per-environment, per-tenant naming scheme and referenced by name only; the application resolves a credential to its real value in memory, for the duration of a single request, and never persists the resolved value. Every integration is built and tested against a sandbox credential set before a verified switch to production credentials is permitted — production traffic never begins on an unverified credential (packages/integrations/README.md).

11. Vulnerability management and penetration testing

CivicPool commits to an annual third-party penetration test of the platform and the companion app, with a further accessibility- and security-focused test ahead of the companion app's public store release. CivicPool targets a SOC 2 Type I report by month 12 of operation.

12. Incident response and breach notification

CivicPool maintains an incident response process to detect, contain, and investigate a security incident, and to notify affected tenants promptly so they can meet their own notification duties. Statutory timelines that apply:

Delaware (6 Del. C. § 12B-102): notice to affected Delaware residents without unreasonable delay and in no case later than 60 days after determination of a breach, absent a law-enforcement delay; notice to the Delaware Attorney General is required where more than 500 Delaware residents are affected.
Kenya: under the Kenya Data Protection Act, notice to the Office of the Data Protection Commissioner (ODPC) within 72 hours of becoming aware of a breach affecting data subjects in Kenya.

13. Responsible disclosure

CivicPool welcomes reports of security vulnerabilities from researchers and the public. To report a suspected vulnerability, write to support@proton.com. CivicPool will acknowledge a good-faith report, investigate promptly, and will not pursue legal action against a researcher who reports a vulnerability responsibly and does not access, alter, or exfiltrate tenant or member data beyond what is necessary to demonstrate the issue.

---

*Adopted under founder decision 38 (15 September 2026); grounded in `docs/CivicPool-Platform-Plan-v2. Counsel may revise it; a revision is a new version.*