What we do with your data, in plain terms.
This page is maintained by IO-HQ to answer the questions security and procurement teams ask first. It describes controls that are in place today, it is not an independent audit or certification. Questions and disclosures go to Jacob Revord, the founder, directly.
Six things that are true today.
Each customer's signal and derived state is held in an isolated tenant. There is no cross-tenant querying.
TLS for data in transit and encryption at rest for stored signal, derived state and reports.
IO holds read-only credentials and never writes to your systems. Where IO's output triggers action, that action is performed by your automation, under your credentials, subject to your existing approvals.
Seats receive the data their role requires. Executive views are aggregations, not wider data grants.
No report is published and no execution event is emitted until a named person approves it.
Approvals, baselines, executions and verification results are recorded and are not editable after the fact.
Where models are used, and where they are not.
What leaves the tenant
Only the playbook catalogue, static cohort definitions, and whatever a user types into the Coach input are sent to the AI provider. No tenant records leave, no names, email addresses, supplier names, signal contents, policy text or figures. Coach input is forwarded verbatim and is not redacted.
Deterministic where it matters
Correlation, gating and verification measurement are deterministic. Language models assist with drafting and explanation, not with deciding whether a measure moved.
Human in the loop
Every model-assisted output that leaves the platform passes the approval gate first.
This section describes what leaves the tenant. It does not assert that customer data is never used for training by every model provider in the chain, because that commitment is not held in writing from all of them today.
What leaves IO when an action is approved.
Where your organisation has configured an execution endpoint, IO sends a signed event to it when an action is approved and accepted by a named owner. The endpoint is an address you choose and control, configured per tenant by an organisation administrator. No endpoint is configured by default, and where none exists nothing is sent.
The payload carries the tenant identifier, the accepted action and its instructions, the accountable owner identifier, the playbook, the capability area, the verification measure with its name, method, unit, baseline value, baseline capture time, direction of improvement and target, and the re-measurement date. It does not carry raw signal payloads, and it carries no personal data beyond the owner identifier and the owner's display name.
An emission that fails never blocks an approval: the failure is recorded against the event rather than raised into the approval path. Delivery is retried up to five times with exponential backoff at 2, 4, 8 and 16 minutes. Where no callback arrives within seven days of emission, the work is marked not attempted with that reason recorded.
Two credentials are held for that endpoint: a signing secret used to sign each event, and a bearer token your automation presents when it reports a result back. Both are held encrypted at rest, both are shown once at creation and never returned by any read path afterwards, and either can be rotated independently of the other.
IO holds read-only credentials and never writes to your systems. Where IO's output triggers action, that action is performed by your automation, under your credentials, subject to your existing approvals. This path is new: it is built and available, and it has not yet been run against a live customer endpoint.
Where your data physically sits.
Signal, derived state and reports are held in a managed Postgres instance in the AWS US West (Oregon), us-west-2 region. The application itself is served from an edge network, so static assets are cached close to the reader, but tenant data is read from and written to that single region.
We intend to offer customer-selected regional hosting, and we will not move customer data between regions without notice. There is no EU or UK region today, so if your obligations require one, raise it before a deployment rather than after: it is a hosting decision and not a configuration switch.
None held today, and here is the plan.
IO-HQ holds no SOC 2, ISO 27001 or equivalent attestation today. We intend to pursue SOC 2, scoped to the Security criteria first, with Confidentiality added once the platform handles customer evidence at volume. Type I before Type II.
We will publish the auditor, the scope and the report date on this page when an engagement is signed. Until then this section says none held, because a certification you cannot show is not a certification.
Where our boundary sits.
Platform security, tenant isolation, encryption, availability of the service, and the integrity of the verification record.
Which systems you connect, which fields those connectors are scoped to, who holds a seat, and disclosure to your staff where required.
Deciding what is monitored, agreeing verification measures, and reviewing what the record shows each quarter.
Two things to know.
Subprocessors
The current list of subprocessors, hosting, model providers and operational tooling, is maintained at /legal/subprocessors.
Security disclosure
Found something? Report it through the contact page, marked as a security disclosure. Reports go directly to Jacob Revord, the founder, there is no queue and no triage tier. He acknowledges every report and will tell you what was done about it.
Still want to see it?
The demo runs on fictional data. Nothing you do in it touches your systems.