How the platform holds a client's environment, a worker's identity and authority, every write and the record of it, the people's secrets and records, and what happens when something goes wrong. Written to be true of the platform as built; the last clause lists what the policy does not claim.
This policy covers the Humetry platform: the console a client's people use, the practitioner panel, the operations surface, the workers and the adapters through which they read and write a client's systems, and the case record. It applies to every client and every region the platform serves.
Two roles own it: the security owner (engineering) and the data protection owner (operations). It is reviewed at every release that changes data handling, and at least quarterly.
A client's records, procedures and lessons are isolated in that client's own environment. Nothing is pooled between clients: a lesson learned on one engagement stays on it, and improvements to general method carry no client data. Access by Humetry's people to a client's environment is by named person, least privilege, and logged; there is no standing access to a client's systems.
A worker acts through an integration identity the client's administrators provision, with read access to what its remit needs and write access limited to the actions in the service description. A worker holds exactly the authority the client delegates, the way it is delegated to a person in the role: approval requirements, thresholds and reserved decisions are rules the platform checks before any write, and a learned preference never grants a transaction right.
Where the system supports it, every write carries an idempotency key or a transaction identifier, and where it does not, a documented substitute. A timeout after a write triggers a status check before any retry, because a write that timed out may have landed. The resulting document state is re-read from the system and recorded. A write that cannot be made safe is escalated, not attempted.
Invoices, remittances, emails and portal messages are treated as evidence. Text inside them that reads as an instruction cannot change a worker's permissions, its rules or its next action. Numerical validation and rule enforcement use explicit logic, and a model's conclusions are checked against source documents and system state before they become actions.
Every read, write, approval, intervention and incident is written to an append-only log, each entry carrying the digest of the one before, so nothing can be removed or reordered without breaking the chain. Each closed case carries a signed evidence pack. The record is the client's, exportable at any time, and retained as the service description says.
Credentials for a client's systems are written to the client's secret store, referenced by id, never displayed again and never written to a log. Humetry API keys are shown once and stored as SHA-256 hashes with a visible prefix. Session cookies are signed, HTTP-only and same-site. Passwords are hashed with scrypt and a per-user salt. Any credential suspected of exposure is rotated first and investigated second.
The records of the people Humetry engages by assignment, the application and its questionnaire, the qualification, assignments and hours, the ledger, standing and its changes with their reasons, grievances and their answers, are personal data of which Humetry is the controller. Practitioners agree to versioned terms in the panel, and the signed version is recorded by hash. A practitioner reads their own records; staff reads are logged.
Model selection, processing location, retention and any third-party service are agreed at deployment and written into the service description. For clients in the European Union and the United Kingdom, in-region processing is available where required. A change to any of these is a change to the service description, agreed with the client before it takes effect.
Client data is retained for the engagement term plus ninety days unless the service description says otherwise or the client asks for earlier deletion. A deletion request produces a deletion manifest listing everything removed and everything a holder of an export must purge. Practitioner records are kept for the engagement and the retention the practitioner standard states; the ledger of paid work stays under a number, not a name.
A suspected incident is triaged within one business day. Affected identities, keys and sessions are revoked first, root cause second. Confirmed incidents affecting personal data are notified to the affected client and, where the law requires, to the regulator within the statutory period (seventy-two hours under the GDPR). The record is the primary evidence of what happened.
Report a suspected vulnerability to security@humetry.ai. In scope: the public site, the console, the panel and the API. Out of scope: client systems, which are the client's, and denial of service. Research conducted in good faith within this policy will not be met with legal action; reports are acknowledged within one business day and answered with a finding. Do not test the platform outside this channel.
Humetry runs the platform on infrastructure it controls. Vendor sandboxes used to build and test adapters receive no client data. Any new subprocessor is listed here before use, and a client's service description names the ones that touch that client's data.
The platform adds no encryption of its own: the database, the case record and stored files rely on the host's disk encryption. Nightly backups are written on the same host; copying them elsewhere is a deployment step. One region per client; no geographic failover. These are stated so that the policy describes the platform as it is.
Counsel reviews each version before it is deployed publicly. A question about any clause goes to the address on the contact page.