Trust
Security
This page answers the questions your IT department will ask, so a security review can take days instead of months, and anything it doesn't cover is probably in our prepared questionnaire answers.
Last reviewed October 20, 2026
The short version
- Each agency's workspace has its own database, file storage, AWS credentials, and server process. One agency's workspace can't read another's data.
- Data is stored in the United States, on Amazon Web Services, in a single region. It's encrypted in transit and at rest.
- People sign in with a one-time code sent to their work email. There are no passwords to steal, reuse, or reset.
- Every change is recorded with who made it and when, in a log that the application itself can't edit or delete.
- Your database is backed up every night to your workspace's own storage, and we restore a backup every month to prove it works.
- If we confirm a security incident that affects your data, we tell you within 24 hours.
- Your agency owns its data and can export all of it at any time. We never sell it or use it to train AI models.
The full security packet has the architecture, data flow, and prepared questionnaire answers.
Your agency's own workspace
Workspaces run on shared servers, but each one is walled off from the others. Even someone who took over one workspace's server process couldn't read another workspace's files, database, or storage.
| Each workspace has its own | How |
|---|---|
| Web address and certificate | youragency.inspectorjay.com, with sign-in cookies limited to that address |
| Server process | Running as its own unprivileged operating system user, with systemd sandboxing |
| Database | A separate PostgreSQL database that only that workspace's user can reach, with no network listener |
| Photo and backup storage | A separate S3 bucket: private, versioned, encrypted, and reachable only over TLS |
| Cloud credentials | A separate AWS IAM user, limited by policy and a permissions boundary to its own bucket and sending email |
| Users and settings | Users, roles, retention schedule, webhooks, and GIS feed keys, all kept in its own database |
If your agency needs it, we can run your workspace on a dedicated server of its own.
Encryption
- In transit. HTTPS only, with TLS 1.2 and 1.3, and HSTS. Plain HTTP redirects to HTTPS. The server reaches AWS storage and email over HTTPS, and its database over a local socket that never leaves the machine.
- At rest. Photos and backups are encrypted in S3. The database and logs are on an encrypted disk. Customer-managed keys (AWS KMS) are available on request.
- Secrets. Sign-in codes, session tokens, report links, and GIS feed keys are stored only as SHA-256 hashes, never in readable form.
Sign-in and access
- No passwords. A user enters their email and gets a six-digit code and a link, which work once and expire after 30 minutes. Because sign-in depends on the user's email account, your email's multi-factor authentication protects it too.
- Guessing limits. Each code allows 5 wrong tries, each address 10 wrong codes an hour, and each IP address 30 sign-in emails and 30 code tries every 15 minutes.
- Sessions you control. Admins set an idle timeout (down to 30 minutes) and a maximum session age. Each user's page lists their signed-in devices, and an admin can sign out a lost phone or every device at once. Deactivating a user ends all their sessions immediately.
- Roles. Admins manage everything. Inspectors and viewers see only the projects they're assigned to, and viewers can't change anything. Contractors see only their own projects' results and reports. Asking for anything else gets "not found", so record IDs don't leak.
- Links without an account. Emailed report links are read-only, cover one project's report, and expire after 30 days. GIS feed keys are read-only and can be revoked at any time. Opening a report link and using a feed key are both logged.
- Our staff. Only our operators can reach the servers. Our admin console needs a password and an authenticator code, and every action it takes on a workspace is recorded. It can create a workspace's storage but can't read what's in it.
A record that can't be quietly changed
- Every create, change, and removal is written to an event log in the same database transaction, with the user, the old and new values, the phone's time, and the server's time.
- Database rules reject any change to the event log or to signatures, and any hard delete of business records. Removed items stay in the history.
- Sign-ins, sign-outs, failed codes, and device sign-outs are in the same log, with the IP address. Admins can view it and export it as CSV.
How the software is built
- All database queries are parameterized and generated from checked SQL. Pages are built with context-aware escaping.
- A strict Content Security Policy allows no inline script and no
eval. Pages can't be framed, and requests from other sites that would change data are rejected. - Uploads are checked for type and size: photos must be JPEG and signatures PNG. Nothing uploaded is ever run.
- Few third-party packages, and the browser libraries are served from our own servers, not a CDN. We scan dependencies for known vulnerabilities before each release.
- Our targets for patching are 7 days for critical vulnerabilities and 30 days for high ones.
- Automated tests, including browser tests and accessibility scans, run on every change before release.
Backups and recovery
- Each workspace's database is backed up every night to its own S3 bucket and kept for 90 days. Photos are copied to S3 as they arrive, checked with a checksum, and versioned.
- Every month, the newest backup is restored into a scratch database and checked against the live one.
- At worst, a failure loses up to a day of database changes. Work still waiting on inspectors' phones isn't lost: it uploads once the service is back.
- Recovery takes a few hours. During an outage, the inspector app keeps saving work offline.
Who else handles your data
| Service | What it receives | Why |
|---|---|---|
| Amazon Web Services | All data, and email addresses and contents | Hosting, storage, backups, and email |
| OpenStreetMap tile servers | Users' IP addresses and the map areas they view | Map backgrounds |
| US National Weather Service | Project locations and dates | Weather for daily diaries (can be turned off) |
| Let's Encrypt | Each workspace's web address | Security certificates |
| Your own systems | What your admins choose to send: parcel lookups to your ArcGIS server, and inspection results to your webhooks | Integration, only if you set it up |
We tell agencies at least 30 days before adding a new service that receives their data. The Privacy Policy has the full details.
Your data, start to finish
- Your agency owns everything it puts in. We use it only to run the service, never for advertising or AI training.
- Export it any time: each project as a zip with its photos and history, the full activity log as CSV, GeoJSON for GIS, and a database copy on request.
- Records stay until your agency disposes of them under its retention schedule. The app never hard-deletes them.
- When a subscription ends, we keep the data for at least 90 days so you can export it, then delete it, including backups, once you confirm in writing.
- The service doesn't collect payment card numbers, Social Security numbers, health information, or criminal justice information.
If something goes wrong
We have a written incident response plan with severity levels and response times. If we confirm an incident that affects your agency's data, we tell you within 24 hours, work with you to contain it, and give you what you need for your own notification duties. These promises are in our Terms of Service.
What we don't have yet
You'd find these in our questionnaire answers anyway, so here they are.
- Single sign-on. Sign-in with Microsoft Entra ID (OIDC) is planned, bringing your own multi-factor policy with it. SAML is available on request.
- Independent penetration test. Planned before our first production contract.
- SOC 2 or StateRAMP. We'll pursue them when a contract requires them. Until then, the security packet and our source code are available for review.
- Redundant hosting. The service runs on one server in one AWS Availability Zone. At county scale we think the offline-first app covers an outage better than a second server would.
The full security packet
Write to hello@inspectorjay.com with your agency's name and we'll send:
- Prepared answers for HECVAT Lite, SIG Lite, CAIQ, and county security questionnaires, ready to copy into your form.
- The security overview: architecture, data flow, hosting, logging, retention, and deployment requirements.
- Our incident response plan.
- Access to the source code for review, if your reviewers want it.
We send these on request because they describe our setup in detail. The Accessibility Conformance Report is public, and Buying inspectorjay lists everything else purchasing usually needs.
Report a security problem
If you think you've found a vulnerability, email hello@inspectorjay.com. Please don't test the service's security without our written permission, and don't use the demo for it either, since it's shared with other visitors.