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.

Our hosting provider is independently audited — SOC 2 Type II and SOC 3 — and runs on Google Cloud and Amazon Web Services underneath. Their report and their penetration-test results are available to your IT department on request. Those cover the infrastructure rather than Civic Lattice's own controls: for ours we provide a security packet, our vulnerability-management evidence, and independent testing results during your procurement review.

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. Sessions are held server-side, so a departing employee's access can be ended immediately rather than waiting for a token to expire.

Two-factor authentication is a policy your municipality sets, not a preference each person may or may not turn on. An administrator can require an authenticator app for every member of the account; recovery codes are one-time and stored hashed; and when someone loses their phone, an authorized administrator can reset their second factor without a support ticket to us. Actions with real consequences — a transfer of ownership, a reset — ask for a recent second factor again, whatever the session says. Administrative access to the platform itself requires an authenticator unconditionally.

Sign-in codes are never stored in a readable form, so a copy of the database yields no working code.

In transit

All traffic is encrypted in transit, and the browser is instructed never to fall back to an unencrypted connection. Application responses carry the standard browser hardening protections.

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 delivered as files to save, never as pages to run, so an uploaded file cannot be coaxed into executing 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. Every governance-significant edit is written to a change ledger that records who changed what, when, and from which value to which — and the change and its record succeed or fail together, so there is no such thing as an edit that went through while its record did not. 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.

What your council reviewed is kept, not merely referred to. Preparing a plan for adoption freezes a complete revision — the plan's own language, the structure beneath it, and the document generated from it — under a single identifier, fingerprinted. No version becomes the adopted one without the official resolution uploaded and permanently recorded against it. Years later, "what exactly did we adopt, and on whose authority" has one answer, with the document attached.

That evidence cannot be erased by accident. Adoption, publication and ownership records, amendment funding decisions, and finalized reporting are protected on every destructive path in the system — including a full reset of the account. An administrator can clear working data; nobody can clear the record of what the city decided.

Your data, and public records

Your data is yours. It can be exported by your own administrators at any time, in open formats, without asking us.

All of it, in one file: an administrator can download the complete state of the organization — the plan and its units, implementation, projects, funding, budgets, reporting, amendments, departments and members — as spreadsheets and JSON, with the full governance history and every uploaded document, and a manifest that fingerprints each file. That is the handover a contract's data-return clause describes, available on any day, not only the last one.

When a records request arrives, an administrator can generate a package for any date range: the governance records, the change history, and the linked evidence documents, with every entry attributed to the person who made it, as a single archive with a readable summary. Financial figures are included only for a requester authorized to see them. The act of exporting is itself logged, so the records show who produced them and when.

Where a matter calls for it, an administrator can place the account under a records hold. While the hold is in force, nothing account-wide can be deleted — the hold is checked before any other rule, and releasing it never weakens the permanent protection above.

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.

If something goes wrong

If we ever have reason to believe your data was accessed by someone who should not have had it, we tell you — promptly, in writing, with what we know and what we are doing about it — and we keep telling you until it is resolved. We do not wait to have every answer before saying anything.

Reporting a security issue

If you believe you have found a security issue, email support@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.