How we protect data
What is actually in place, in plain words, so a client's counsel can read it in five minutes. None of this is a promise that nothing can ever go wrong; it is what we do so that it rarely does, and so that we notice fast when it does.
One service, one door
- The Portal, Sentinel, the Lab and the operator console run as one service on one managed host, behind one login system. There is no separate copy of anything to fall out of sync.
- Every page is served over encrypted connections. The data disk on the host is encrypted at rest and snapshotted daily by the hosting provider.
- Secrets (API keys, tokens, mail and messaging credentials) live in the host's environment, never in code or in the repository.
Who can see what
- Every login belongs to exactly one client, or to the operator. A client login is locked to its own client's data by the service itself; it cannot name another client's data set in a request. If no data has been attached to a login, it sees nothing (deny by default).
- The operator console, where logins are created and data is attached, is reachable only by the operator and is never linked from any client-facing page.
- The Lab is a separate workspace with its own data set and its own logins.
- Sentinel logins can be limited to particular races.
Keeping the door locked
- Every login accepts a click-through that makes the material a trade secret under the Kansas Uniform Trade Secrets Act. Re-acceptance can be required at any time.
- Passwords are stored as salted hashes. Repeated failed sign-ins lock the address out for a period.
- Every sign-in, page view, search and export is logged with the login, time, address and device.
- The brake. Page views, roster views, person lookups, searches and exports each have a rate limit. A login that exceeds one (the pattern of scraping or bulk download) is stopped mid-request, signed out, locked, and its password is replaced. The operator sees why and can restore it.
- Breach signals. A burst of failed attempts followed by success from a new address and device, or one login used from three addresses within ten minutes, locks the login and rotates its password automatically. A sign-in from a new device soon after the last one is flagged for the operator.
- Sessions expire; cookies are marked secure and unreadable by page scripts.
What leaves the building
- No advertising trackers, no analytics pixels, no social-media scripts.
- Voter and donor records never go to an AI model. Memos and drafts marked AI-generated are built from cited public material and the client's own tested messages.
- Exports are logged, rate-limited and, for research texts, mask phone numbers.
Watching it
- An automated check runs every morning against the live service: are the pages up, is every data feed fresh, did anything error. Problems are recorded and a maintenance routine fixes what code can fix and writes the fix into the public changelog.
- Every unhandled error is recorded with the page and the time (never with the content of a client's data) and shown to the operator.
- Dependencies are monitored for published vulnerabilities and updated.
If something goes wrong
The affected client is told without unreasonable delay, with what happened, what was involved and what we did. Kansas's breach notice statute (K.S.A. 50-7a01 and following) and the client's contract govern notice to individuals. Affected passwords are rotated and the logs are preserved.
What we do not claim
We do not hold a SOC 2 report or an ISO 27001 certificate. Those are audits of process that large vendors buy for procurement departments; if a client's procurement requires one, ask and we will discuss it. What is listed here is in place today and can be shown on request.