This page summarizes how CoopTools protects the data cooperatives entrust to it. Items marked ✓ Verified were confirmed by direct inspection of the production system on 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 (96/96) |
| Tenant-isolation policies in force | ✓ Verified (233) |
| 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 isolation check on every backup | ✓ In place |
2. Architecture & hosting
| Layer | Provider | Notes |
|---|---|---|
| Application (web + mobile) | Vercel; Android via Capacitor | React front end |
| 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 direct check against the production database on July 17, 2026 confirmed Row Level Security is enabled on all 96 application tables (0 disabled), with 233 active isolation policies. 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
Both isolation checks run as required steps in the daily backup process. A table shipped without Row Level Security, or a policy opened to other tenants, fails the build and stops the process. In practice this protection has already caught and blocked a configuration issue before it could reach production.
Beyond the automated gates, three full security audits have been performed (most recently in July 2026, covering edge functions, webhooks, and scheduled jobs as well as the database). 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.
- Role-based access. Each user has a role (field, viewer, 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.
- 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 two tenant-isolation checks, 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.
In the interest of full transparency: the restore procedure is scripted and rehearsable, and a full test-restore drill — decrypting the most recent backup and restoring it into a scratch database — is the final step that proves recoverability end to end. This drill is a top priority on our roadmap. See Section 8.
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:
- Backup test-restore drill. The restore procedure is scripted; performing a full decrypt-and-restore of the latest backup into a scratch environment is the step that conclusively proves recoverability. This is our top priority.
- Key-system migration. Following a precautionary review, embedded credentials were removed from all database objects and infrastructure keys were rotated. The remaining step is migrating to our vendor's newer, more finely scoped key system and retiring the legacy key format.
- Operational notification recipients. Recipient addresses for certain operational security emails are being finalized so alerts reach the right people.
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.