Security
Your data, in its own database.
How Works is built, what we do, and what we do not have yet. Written plainly, because your IT department is going to ask anyway.
The architecture, first
Every client runs on their own WordPress installation with their own database, on their own subdomain. There is no shared multi-tenant schema.
That matters more than it sounds. In most safety platforms, every customer’s data sits in the same tables, separated by a column and a query filter. One mistake in that filter, or one permissions bug, and one customer can see another’s. That class of failure does not exist here, because there is no query that could reach another client’s data. The data is not in the same database.
It also means your configuration, your forms, and your branding are yours. Nothing about your setup is constrained by what another customer needs.
What we do
The controls that are in place today.
Access
- Multi-factor authentication required on administrator accounts
- Role-based access enforced on the server, not hidden in the interface
- A foreman sees their own scope, not the company’s
- No public registration on any client installation
- Administrative access limited to named staff
Data
- Encrypted in transit with TLS on every installation
- Hosted in the United States, single region
- Separate database and separate system account per client
- Automated backups on a scheduled cadence
- Your uploaded documents stay in your installation
Operation
- Automated daily health monitoring across every installation
- Failures alert us, not you
- Security plugin monitoring on every site
- Version-controlled deployment with a documented runbook
- Change history on every release
Straight answers to the usual questions
| Question | Answer |
|---|---|
| Is our data separated from other customers? | Yes. Separate database and separate installation per client, not a shared schema. |
| Where is it hosted? | United States. |
| Is it encrypted in transit? | Yes, TLS. |
| Is it encrypted at rest? | [CONFIRM: verify with host before publishing] |
| Do you have a SOC 2 report? | No. We are a small company and have not been through a SOC 2 audit. We will tell you that up front rather than after your procurement process has started. |
| Has the platform been penetration tested? | Not yet. It is on our list. |
| Do you support single sign-on? | Not yet. Multi-factor authentication is available today. |
| Do you publish an uptime SLA? | No. We would rather not publish a number we cannot stand behind on our current architecture. We will tell you honestly what our availability has actually been. |
| How often are backups taken and have you tested a restore? | [CONFIRM: state frequency, retention, and a tested restore time] |
| What happens to our data if we leave? | It is yours. [CONFIRM: define exactly what is delivered and in what timeframe] |
| Who are your subprocessors? | [CONFIRM: publish the list] |
| Will you sign a data processing agreement? | [CONFIRM: not yet drafted] |
If your procurement process needs a questionnaire completed, send it. We answer them.
What we are honest about
We are a safety consulting firm that builds software, not a hundred-person software company. That is the reason the product understands your job, and it is also the reason we do not have a compliance department.
If your organization requires SOC 2 before signing, we are not the right vendor today, and you should know that before you spend three weeks on an evaluation. If your organization wants to know whether its data is properly separated, monitored, and backed up, the answers are on this page.
Send us the questionnaire.
We would rather answer it early than surprise you late.