Federal Index
For your security reviewer
Trust and security
Written to be forwarded. If you are reviewing Federal Index for your organization, this page describes the controls in place today, how answers are checked against their sources, and how to get anything else in writing.
In place today
- Customer data is separated by organisation: Row-Level Security in the database, and organisation scoping enforced in our code for the API and the pipeline.
- Every citation in an interpretation is checked against its source document, and every customer-facing summary passes an automated check against its source text before it is published.
- HTTPS on every surface with Strict-Transport-Security; data encrypted at rest by the hosting provider.
- Append-only audit records, a private file bucket, and rate limits on public forms.
Each control on this page is checked against the code by an automated test on every build. Formal assurance status is stated in your written quote, as of .
Customer data is separated by organisation, in two places
In the database, for what the customer app reads and writes directly. The app connects to the database as the signed-in user, and a Row-Level Security policy inside PostgreSQL filters every tenant-scoped table by organisation before any row is returned. That rule lives with the data, not in a middleware check that a future code path could forget to call.
In our code, for our API and our processing pipeline. The pipeline routes each new government document to every organisation it affects and delivers each organisation's briefing, and the API serves the few actions the app sends through our server. Both connect with a privileged database key that Row-Level Security does not filter, so for them organisation scoping is enforced in our code. Apart from search, which reads only the shared library of published government documents, the API routes a signed-in customer can call act only for the organisation that user belongs to — or, at first sign-in, for the seat registered to that user's exact email address.
- Row-Level Security on every table. Every table our schema defines has Row-Level Security switched on, and an automated check in our test suite fails if a new table arrives without it.
- Role views inside a customer. Each seat opens the dashboard for the role it was registered with, and a seat without a recognised role is not given one. The organisation is the data boundary; the role decides which view each person is shown.
- Append-only records. The ingest log, the AI run log, the account audit log, signed agreements and the version history of workspace documents reject updates and deletes inside the database, so an attempt to change the trail fails instead of rewriting it.
- No storage bucket is public. Customer files sit in a private bucket whose policies admit only members of the organisation named in each file's path.
- Encrypted in transit and at rest. The site, the customer app and the API each redirect plain HTTP to HTTPS and send a Strict-Transport-Security header. The database and file storage are encrypted at rest by our hosting provider.
- Rate limits on public forms. Requests for an email verification code are limited per address, per network and overall; new applications per network and overall. A request over a limit is answered with a time to try again.
Certifications and assurance
Where Federal Index stands on formal assurance is answered in writing, in your quote: the current status of each item below, dated, and the date of any audit or test once it is booked.
- Formal certification — SOC 2 and ISO 27001: not currently certified. Status and dates are stated in your written quote.
- Independent testing — the status of third-party penetration testing is stated in your written quote.
- Enterprise sign-in — each person signs in with their own email address and their own seat. Where SSO, SAML and SCIM stand is stated in your written quote.
- Tenant isolation — in place today: Row-Level Security in the database for the customer app, and organisation scoping in code for our API and pipeline, as described above.
Security questionnaires are answered in writing. Write to hello@federalindex.us and we reply with the subprocessor list, data residency and DPA status.
Correctness is a security property here
For a regulatory-intelligence product, a wrong answer delivered confidently is a worse outcome than downtime. Two controls sit in front of anything a customer sees. First, every citation in an interpretation that identifies a statute or regulation must appear in the source document it came from; an interpretation with no citations, or citing one the source does not contain, is stopped. That is an exact check in code — not a scoring threshold or a confidence percentage — and it fails closed. Second, every customer-facing summary passes an automated review against its source text before it is published; one that does not pass is held back, never sent. Adding a new source to the system requires a person to approve it.
Subprocessors
Federal Index uses third parties to host the application, run the ingestion pipeline, send email, interpret documents, and process payment. Each is listed, with the purpose it serves, on the subprocessors page. The binding statement is §5 of the Privacy Policy; the subprocessors page lists Google Workspace ahead of the Policy's next version.
References
Federal Index names customers only with their permission. If anyone presents themselves to you as a Federal Index customer or reference, confirm it with us at hello@federalindex.us before you rely on it.
Reporting a vulnerability
If you believe you have found a vulnerability, write to hello@federalindex.us with enough detail to reproduce it. Every report is acknowledged, and you are told when it is fixed. The same contact is published in machine-readable form at /.well-known/security.txt.