How your data is separated and protected.

Hosting

The application and its database are hosted in the United States. The database is not reachable from the public internet — only the application can connect to it, over a private network. This marketing website is a separate deployment that holds no customer data.

Backups

The database is backed up automatically on daily, weekly, and monthly schedules, with copies retained for up to three months. Backups are managed by the hosting platform and stored separately from the running database.

Separation between customers

Every municipality and every firm is a separate account. Data access is scoped to the account making the request and enforced on the server for every request, not in the browser. Within an account, permissions follow municipal roles: department staff see their department's work, fiscal roles approve budget requests, executives get read-only oversight.

Authentication

Sign-in uses a one-time code sent to a verified email address. There are no passwords to be reused across systems, phished in bulk, or exposed in someone else's breach. Two-factor authentication with an authenticator app is supported, and is required for administrative access to the platform itself. Sessions are held server-side, so a departing employee's access can be ended immediately rather than waiting for a token to expire.

Sign-in codes are never stored in a readable form. Each is held as a keyed hash, bound to the address and the purpose it was issued for, and checked in constant time — so a copy of the database yields no working code.

In transit

All traffic is served over HTTPS with HTTP Strict Transport Security. Application responses carry a Content Security Policy and the standard browser hardening headers.

Third-party code

The application loads no third-party scripts. Everything the browser runs — the charting library included — is served from our own domain, so no outside vendor can change what executes inside a session on your network. Production dependencies are audited on every build, and a known high-severity vulnerability fails that build rather than shipping.

Files you upload

Plans, budgets, and evidence are checked by their actual contents rather than their file name. The bytes have to match the type being claimed — a file that says it is a spreadsheet and is not gets rejected before it is stored. Downloads are always served as attachments with content-type sniffing turned off, so an uploaded file cannot be coaxed into running in someone's browser.

The record of decisions

Adopted plan text is locked: it cannot be altered through ordinary operations, only through a formal amendment. Changes to the plan itself are written to an append-only audit log that records who changed what, when, and from which value to which. Finalized reports are fingerprinted, so a published figure can be shown not to have changed after the fact — which matters both for public-records obligations and for defending a decision years later.

Working with your IT department

Every municipality reviews software before it touches city data, and we would rather have that conversation at the start of your process than at the end. Tell us what yours requires — a security questionnaire, specific certifications, identity-provider integration, contractual data-processing terms — and we will work through it with you directly, against the release you would actually be deploying.

Reporting a security issue

If you believe you have found a security issue, email contact@civiclattice.com with enough detail to reproduce it. We acknowledge within five working days and will keep you informed through to a fix. We support good-faith security research and will not pursue action against researchers who avoid privacy violations, service degradation, and access to data that is not their own.