This page summarizes how CoopTools protects the data cooperatives entrust to it. Items marked ✓ Verified were confirmed by direct inspection of the production system, its schema snapshot or its nightly gate logs on or before the version date above; items marked Platform guarantee are provided and maintained by our infrastructure vendors.
1. Executive summary
CoopTools is a multi-tenant platform for electric distribution cooperatives. Every cooperative's data is logically isolated at the database level, encrypted in transit and at rest, and backed up to an independent, encrypted, tamper-resistant offsite location every day.
Critically, security is enforced where it cannot be bypassed — inside the database, not only in the application — and the tenant-isolation guarantee is automatically re-checked on every backup run, so a regression cannot ship silently.
| Control | Status |
|---|---|
| Row Level Security enabled on every application table | ✓ Verified (107/107) |
| Tenant-isolation policies in force | ✓ Verified (267) |
| No cross-tenant policies on cooperative data | ✓ Verified clean |
| Encryption in transit (TLS) | Platform guarantee |
| Encryption at rest (AES-256) | Platform guarantee |
| Daily offsite backups, client-side encrypted | ✓ Verified working |
| Automated security gates on every backup (10) | ✓ In place |
| Backup restore drill | ✓ Passed (July 21, September 8 and October 5, 2026) |
| Two-factor authentication for administrators | ✓ In place |
| Content Security Policy enforced on the application | ✓ In place |
2. Architecture & hosting
| Layer | Provider | Notes |
|---|---|---|
| Application (web + mobile) | Vercel; iOS and Android via Capacitor | React front end; one code base for the office app and the native field apps |
| Database, Auth, Storage, Functions | Supabase (managed Postgres) | SOC 2 Type II infrastructure |
| Offsite backup | Backblaze B2 | Independent provider; private, object-locked bucket |
| GIS map feed (optional) | Railway | Read-only, per-cooperative authenticated feed into a co-op's own ArcGIS |
CoopTools is a single application serving all cooperatives, with data separated logically by an organization identifier on every tenant table and enforced by database Row Level Security. Physical per-tenant database separation was evaluated and deliberately deferred — logical isolation backed by Row Level Security and verified on every backup run is sufficient at current scale, and can be revisited if a cooperative contractually requires it.
3. Tenant isolation — the core control
The most important guarantee in a multi-tenant system is that one cooperative can never see or modify another cooperative's data.
3.1 How it works
- Every cooperative table carries an organization identifier.
- Row Level Security is enabled on every table in the application. This pushes the "which rows may this user touch" decision into the database itself, so it holds even if application code has a bug — the database refuses the rows.
- Access is governed by helper functions that resolve the user's organization and role from their authenticated session, so the role assigned in the application is the same role the database enforces.
- External joint-use ("attacher") companies authenticate as their own accounts with no cooperative affiliation, so they can never match a cooperative's rows; their limited access is granted only through specific, session-derived functions that never trust a client-supplied identifier.
3.2 Independent verification
✓ Verified: A schema snapshot of the production database on September 28, 2026 shows Row Level Security enabled on all 107 application tables (0 disabled), with 267 active isolation policies, and the same check runs as a hard gate on every nightly backup. A second check confirmed there are no policies that expose cooperative data to other tenants. The only tables intentionally readable by all users are platform-wide reference data and help documentation, which contain no cooperative data.
3.3 Regression protection
Ten automated gates run as required steps in the daily backup process: the two tenant-isolation checks, plus checks that every update policy carries a row check, that the profile privilege guard is intact, that storage buckets and policies match their migrations, that every user-identity column is covered by the single-sign-on rekey inventory, that anonymous callers can reach nothing outside the documented surface, and that no credential is committed to the source repository. A table shipped without Row Level Security, or a policy opened to other tenants, fails the build and stops the process. In practice these gates have already caught and blocked configuration issues before they could reach production.
Beyond the automated gates, four full security audits have been performed (most recently in August 2026, covering edge functions, webhooks, scheduled jobs and file storage as well as the database), followed by a September 2026 review of administrative functions, storage policies and the build pipeline. Every finding was remediated and the fixes deployed; none of the audits found a live cross-tenant exposure of cooperative data.
4. Authentication & access control
- Authentication uses industry-standard session tokens. Passwords are hashed by our infrastructure provider; the application never stores raw credentials.
- Two-factor authentication. Time-based one-time codes are supported for every account and required for CoopTools platform-administrator accounts; the most privileged administrative functions refuse a session that has not completed the second factor.
- Role-based access. Each user has a role (field, admin, supervisor, or owner) that governs both the interface and database access. There is no public self-registration — accounts are provisioned by a cooperative administrator or by CoopTools. Cooperative administrators can deactivate a user themselves, which blocks sign-in and ends any live session.
- Least-privilege platform support. CoopTools support access uses a read-only "view as cooperative" snapshot rather than impersonation, and every privileged action is written to an immutable audit log that records the actor from the session so entries cannot be forged.
- Rate limiting. Abuse-prone endpoints (document uploads, public form submissions, notification emails) are rate-limited, and repeated failed logins are locked out.
- Browser hardening. The application is served with an enforced Content Security Policy, so a script, frame or connection to any origin not on the allow-list is blocked by the browser, and production builds ship without source maps.
- Minimized public surfaces. The previously anonymous permit portal was replaced with authenticated attacher accounts. Public self-serve document forms are protected by CAPTCHA and per-form rate limits, and fail closed if CAPTCHA is not configured.
- GIS map feed. The optional read-only feed into a cooperative's own ArcGIS uses per-cooperative credentials stored only as strong one-way hashes, exposes no write operations, and locks out repeated failed login attempts before they can consume resources.
5. Encryption
| Data state | Protection | Basis |
|---|---|---|
| In transit | TLS/HTTPS on all connections | Platform guarantee |
| At rest | AES-256 disk encryption on managed infrastructure | Platform guarantee |
| Backups (offsite) | Client-side encryption before data leaves our infrastructure; key held offline | ✓ Verified |
| Files in storage | Private buckets, served only via short-lived signed links | ✓ Verified |
Encryption at rest is provided and managed by our infrastructure provider and is on by default. Backups receive an additional, stronger guarantee: the database export is encrypted on the backup runner itself, so the offsite copy is unreadable without a private key that is held offline and never stored in our automation.
6. Backups & disaster recovery
CoopTools follows a 3-2-1 backup strategy: multiple copies, on more than one medium, with at least one copy offsite and independent.
| Copy | What & where | Restore |
|---|---|---|
| Primary | Full database — managed daily backups (~7-day retention) | Minutes, in-console |
| Offsite | Encrypted database export + all files — Backblaze B2, private + immutable | Scripted download + restore |
| Account-loss insurance | Same offsite copy is at a different provider — survives total loss of the primary account | — |
Each day, the system: (1) exports the entire database, compresses and encrypts it, and uploads it offsite — the export includes the isolation policies, so a restore re-creates tenant separation, not just rows; (2) copies all stored files (documents, photos, signed PDFs) offsite; (3) runs the ten security gates described in Section 3.3, making the backup a daily security audit; and (4) records a success/failure heartbeat.
Tamper resistance. The offsite bucket is private with object-lock immutability, and the automation key can write but cannot delete — so a compromised pipeline could add to backup history but not erase it.
✓ Verified working: Encrypted backups have landed offsite on consecutive daily runs, most recently on the morning of the version date above. The pipeline is operating as designed and is confirmed healthy.
✓ Restore drill passed: a full test restore — decrypting the most recent offsite backup and restoring it into a scratch database — was performed on July 21, 2026, again on September 8, 2026, and most recently on October 5, 2026. Each run verified the restored schema, every isolation policy and every cooperative's data. The drill is scripted and repeats monthly.
7. Document & personal-information handling
- Private storage with short-lived links. Document, permit, and completion files are stored privately and served only through short-lived signed links after the requester is authorized. Direct public access is refused.
- Access audit trail. Every document download is logged with the actor, IP address, and timestamp before a link is issued.
- Retention and erasure. Retention is enforced automatically by nightly purge processes: signed documents and their personal information are removed after a configurable default of seven years; document-access and administrative audit logs after two years; and soft-deleted items after thirty days. Operational records (storm, FEMA, inspection, and permit data) are retained for the life of the account, consistent with federal disaster-assistance record-retention expectations. If a cooperative leaves the platform, its data is deleted permanently after a 90-day grace period. Cooperatives can also erase personal information from a signed document on demand; a purge leaves a non-personal record for the audit trail.
- E-signature integrity. Each completed signature produces a Certificate of Completion capturing IP address, sent/viewed/signed timestamps, and explicit electronic-signature consent.
8. Honest disclosure — open items
We believe transparency is itself a security practice. The following items are on our active roadmap and are disclosed candidly:
- Key-system migration. Following a precautionary review, embedded credentials were removed from all database objects and infrastructure keys were rotated. Server-side functions already use our vendor's newer, more finely scoped keys; the remaining step is retiring the legacy key format entirely.
- Durable sign-in history. Sign-in events are visible while a session lives; a permanent sign-in log that survives session expiry is specified and scheduled.
None of these items represents a known exposure of cooperative data. They are hardening and assurance steps that move the platform from "protected" to "protected and independently proven."
9. Questions
CoopTools is happy to answer security questions from prospective and current cooperatives and to provide a current sub-processor list on request. Contact: seth@cooptools.io.
This page describes the state of the system as verified at the version date and is updated as the platform evolves.