How we handle personal information, how we meet our obligations under the GDPR, how we keep identifiable data out of our AI systems, and where in the world your data actually lives.
This document is written to be read by the people who will be asked to sign off on us: a privacy lead, a legal reviewer, a works council, or an IT security function. It states plainly what we hold, what we do with it, and what we will never do with it.
The four commitments everything else in this document follows from.
Exactly which fields are personal data, which are not, and the fields we deliberately refuse to collect.
Minimum group sizes, suppression rules and why a manager can never reverse engineer one person's answers.
Controller and processor roles, lawful bases, the data processing agreement, and the rights we help you honour.
How long we keep each category of data and what happens on the day you leave.
What our language models receive, what they never receive, and why your data is never used to train a model.
Regional hosting, data residency, encryption, isolation, backups and the certifications behind our infrastructure.
A short division of labour, plus who to contact.
Humanness asks people how they experience their work. That only produces honest answers if people trust what happens next. Privacy is therefore not a compliance layer bolted onto the product. It is the condition the product needs in order to work at all.
Every field we hold has to justify itself against a specific product purpose. We do not gather demographic data, device fingerprints, browsing history, location, or anything else we would only use to build a richer profile of a person. If a feature can work without a piece of personal data, it does.
You buy insight about an organisation, not surveillance of the people in it. Administrators see aggregated readings. They do not see, and cannot request, the row of answers a named colleague submitted.
We do not sell data. We do not share it with advertisers or data brokers. We do not use your employees' answers or conversations to train, fine-tune or improve any AI model, ours or anyone else's.
If something goes wrong we will say so, quickly, with what we know and what we are doing about it. Our notification commitments are contractual, not aspirational, and are set out in section 04.
Sections 02 and 03 describe the data itself. Sections 04 and 05 describe the legal framework and the lifecycle. Section 06 covers artificial intelligence, which is usually the question reviewers most want answered. Section 07 covers the infrastructure your data sits on. Section 08 is a one page summary of who is responsible for what.
Where this document says "you" it means the organisation that holds the subscription. Where it says "a member" or "an individual" it means an employee or participant who answers an assessment. The distinction matters, because the two have different rights and see different things.
Personal information, or PII, is any data that identifies a living person or could reasonably be combined with other data to identify them. Below is the complete inventory. There is nothing held outside this list.
| Category | What it is, and why we need it |
|---|---|
| Identity | Name and work email address. Needed to create an account, send an invitation, and let a person return to their own results. |
| Credential material | A one way cryptographic hash of a password, never the password itself. Hashes cannot be reversed to recover the original value. |
| Work context | Optional department, team and job title. Used only to group results. A person can leave these blank. |
| Preferences | Interface language and an optional profile image the person uploads themselves. |
| Assessment responses | Scale answers to the assessment questions, and any free text a person chooses to write. Stored against the individual so they can see their own history. |
| Coaching conversations | The messages exchanged between an individual and our AI companion. Visible to that individual only. See section 06. |
| Operational records | Account creation and update timestamps, invitation status, subscription state, and security event logs such as sign in attempts. |
The absence of these fields is a design decision, not an oversight. Several of them would make certain analytics easier. We consider the trade unacceptable.
Aggregation on its own is not privacy. An average of two people tells you almost everything about both. Our reporting layer therefore enforces minimum group sizes in code, before a number is ever drawn on a screen.
| Respondents in a group | What an administrator sees |
|---|---|
| 1 to 4 | No breakdown at all. No dimension scores, no perception spread, no free text. The group is reported only as part of a larger population. |
| 5 to 7 | Scores are shown and clearly marked as directional, signalling that the reading indicates a tendency rather than a reliable measurement. |
| 8 or more | Full breakdown, including distribution and the gap between how the organisation and the team are experienced. |
These thresholds are not a configurable setting, an administrator permission, or something we can lift on request during an implementation call. They are enforced by the same code path that produces every chart, for every customer, on every plan. A request to disable them is a request we are technically unable to honour.
The obvious way around a minimum group size is to stack filters until only one person remains: one department, one location, one tenure band. Suppression is applied to the population that results from the filters actually selected, so narrowing the view produces a suppression notice rather than an individual's answers.
A comment can identify its author even when a score cannot, through a turn of phrase or a reference only a few people would make. Free text is therefore held to the same thresholds as quantitative data, and is never attributed to a named person in any administrator view or export.
An administrator running an organisation of forty people can see that trust is low in one function and high in another. They cannot see who said what. If they filter down far enough to threaten that, the product stops showing numbers and tells them why.
Humanness is built to be deployed inside the European Union and the United Kingdom without special handling. The paragraphs below set out the roles, the lawful bases and the contractual terms that make that true.
For employee data processed on your instructions, you are the data controller and Humanness is the data processor. You decide who is invited, which assessments run, and what happens to the findings. We process that data only to deliver the service and only within your instructions.
For our own account and billing records, and for individuals who sign up directly rather than through an employer, Humanness is the controller. Those two roles are kept separate in our records of processing.
| Processing | Basis |
|---|---|
| Running assessments for an employer | Legitimate interests of the employer in understanding and improving working conditions, with a balancing test supported by our suppression rules. |
| Individual coaching conversations | Consent of the individual, given by choosing to start a conversation, and withdrawable at any time by deleting it. |
| Account creation and access control | Performance of the contract with you. |
| Security logging and fraud prevention | Legitimate interests in keeping the service and its users safe. |
| Billing and statutory records | Legal obligation. |
A data processing agreement is available and forms part of your contract. It carries the Article 28 terms in full: processing on documented instruction only, confidentiality obligations on our staff, appropriate technical and organisational measures, prior authorisation and flow down for sub-processors, assistance with data subject requests, assistance with impact assessments and regulator engagement, deletion or return of data at the end of the relationship, and audit rights.
Every person whose data we hold has the rights below. Where you are the controller, requests arrive with you and we support you in answering them. Where a request reaches us directly, we acknowledge it, tell the individual who the controller is, and notify you without undue delay.
An individual can obtain a copy of their personal data, including their own assessment history, in a structured and machine readable format.
Name, email, department, title and language can be corrected in the product at any time, by the individual or by an administrator.
An individual can be deleted from the platform. Their identity and conversations are removed. See section 05 for how aggregated history is handled.
Participation in an assessment can be declined, and processing can be restricted while a dispute is resolved, without loss of the account.
We do not carry out automated decision making that produces legal effects for an individual. Our AI features generate suggestions for a human to consider. They decide nothing about a person's employment and are not for performance management, a boundary we ask you to preserve in how you use the product.
We keep a current list of sub-processors, with the category of data each one touches and its location. Each is bound by written terms at least as protective as our own, assessed before onboarding and reviewed annually. Today the list covers infrastructure hosting, transactional email, AI model inference and payment processing. We give you advance notice of any addition, so you have the opportunity to object.
Where personal data moves outside the European Economic Area or the United Kingdom, the transfer is covered by the European Commission's Standard Contractual Clauses and the UK International Data Transfer Addendum, supported by a transfer impact assessment. If your policy requires that data never leaves a region, section 07 explains how we meet that.
We maintain a documented incident response process with defined severity levels and named owners. In the event of a personal data breach affecting your data, we will notify you without undue delay and in any case within 24 hours of confirming it, giving you what you need to meet your own 72 hour obligation to a supervisory authority. You will get facts as they are established, not a holding statement.
Data that no longer serves a purpose is a liability rather than an asset. Each category below has a defined life, and deletion is enforced rather than left to good intentions.
| Data | Retained | Then |
|---|---|---|
| Account and profile | For the life of the subscription | Deleted |
| Assessment responses | For the life of the subscription, so individuals and organisations can see change over time | Deleted or anonymised |
| Coaching conversations | Until the individual deletes them, or the account closes | Deleted |
| Invitations not accepted | Until expiry, then a short grace period | Deleted |
| Security and access logs | 12 months | Deleted |
| Encrypted backups | 35 days on a rolling window | Overwritten |
| Billing records | As required by tax and company law | Retained, then deleted |
An administrator can remove a member immediately. Identity, profile and coaching conversations are deleted. Their assessment responses are detached from their identity and retained only as anonymous contributions to historical aggregates, so that removing one person does not silently rewrite last quarter's reported numbers. If you require full erasure including the aggregate contribution, we will do that on request.
At the end of the relationship you can export your organisation's data. Thirty days after termination we delete it from live systems, and it ages out of encrypted backups within the backup window stated above. On request we will confirm completion in writing. There is no scenario in which we retain your data as leverage, or keep using it after you have gone.
Export is a standard feature, not an off-boarding concession. You can take a full copy of your organisation's data at any point during the subscription, without asking us and without a fee.
Humanness uses large language models for two things: a private reflective companion for individuals, and drafting suggested actions for administrators. Both are built on a simple rule. The model is given the meaning of the data, never the identity of the person behind it.
Nothing is passed to a model implicitly. Every request is constructed field by field on our servers, from an explicit list of values, and that construction is the only path by which data can reach a model. The context we assemble contains:
If a model response were somehow intercepted in full, it would read as advice about a pattern of scores. There would be no name in it, no employer, and no way to tie it back to a person from the content alone.
An individual can of course type their own name, or a colleague's, into a conversation. We cannot prevent that and we do not pretend to. What we guarantee is what happens to it: that conversation is visible to that individual and to nobody else. It is not readable by their manager, by an administrator in your organisation, or by our own staff in the ordinary course of support.
This is the commitment reviewers ask about most, so we will state it without qualification. Nothing your people write and nothing they score is used to train, fine-tune, evaluate or otherwise improve any machine learning model. Not ours, and not our model provider's.
We use enterprise inference terms under which prompts and completions are processed to return a response and are not retained for training, human review or product improvement. The model is stateless between requests: it has no memory of your organisation from one call to the next.
Requests travel over TLS to the inference endpoint. There is no intermediate store, no queue that keeps a copy, and no logging of prompt bodies in our application telemetry.
So that an individual can pick up where they left off, we store their conversation in your database region, under the same encryption and access controls as the rest of your data. The model never holds it.
We do not read conversations to improve the product. Where we need to investigate a specific fault, we work from the smallest necessary extract, with the individual's knowledge, under a logged and time limited approval.
The suggestions an administrator sees are generated from the same suppressed, aggregated readings that appear in the dashboard. The model that drafts them is not given, and has no way to reach, an individual response. It cannot surface a quote, it cannot name a person, and it cannot report on a group too small to be reported on.
Our companion is instructed to hold clear limits. It does not diagnose. It does not offer clinical advice. Where someone appears to be genuinely struggling, it says so plainly and points toward qualified human support rather than trying to handle it. These are product decisions about duty of care, and we treat them as part of privacy rather than separate from it.
If your policy does not permit AI processing of employee input, the AI features can be disabled for your organisation. Assessments, dashboards, reporting and exports all continue to work. No feature you rely on for measurement depends on a language model.
Humanness runs on our own managed cloud platform, deployed into enterprise data centre regions operated to internationally recognised standards. You choose the region at the point of provisioning, and your operational data stays in it.
Your application instances, your database and your backups are pinned to a single region. The choices are:
| Region | Location | Typically chosen when |
|---|---|---|
| Europe West | Amsterdam, Netherlands | The client is in the EU or the UK and wants data resident inside the EEA under the GDPR. |
| US East | Virginia, United States | The workforce is primarily North American and latency matters most. |
| US West | California, United States | The workforce is concentrated on the Pacific coast. |
| Asia Pacific | Singapore | The workforce is in Asia Pacific and local residency is preferred. |
Regional pinning covers your operational data. AI inference and transactional email are delivered by sub-processors that may process a request outside your region, under the transfer safeguards in section 04. Where that is unacceptable to you, the AI features can be switched off and email can be routed through your own relay.
We do not build data centres. We deploy into facilities operated by providers whose physical and organisational controls are independently audited, because an audited third party is a stronger assurance than our own word about a building. Those facilities hold current ISO 27001, SOC 2 Type II and PCI DSS attestations, and their controls cover:
Databases, file storage and backups are encrypted with AES-256. Keys are held in a managed key service, separated from the data, with rotation and access logging.
All traffic uses TLS 1.2 or above, with 1.3 preferred, and HTTP Strict Transport Security enforced. Plain HTTP is redirected, never served.
Your organisation's data lives in a dedicated database instance rather than a shared table shared with other customers. That instance sits on a private network with no public address: it is reachable only by your application containers, over an internal route, using credentials held in our secrets manager and never in source code. There is no port on the public internet through which your database can be addressed.
Backups run automatically, are encrypted with the same standard as live data, and are stored in your region. We retain a rolling 35 day window and support point in time recovery, so a restore can target a moment rather than only the previous night. Restores are tested. A backup nobody has ever restored is a hope, not a control.
The service targets 99.9 percent monthly availability, measured externally. Releases are deployed as immutable images with health checks and automatic rollback, so a bad change is withdrawn in minutes rather than patched under pressure on a live system.
Privacy in a workforce product is a shared job. We can make individual answers technically unreachable. We cannot make a manager ask the right question in a team meeting. Here is the division of labour we recommend writing into your rollout.
| Humanness does | You do |
|---|---|
| Enforce minimum group sizes and suppression in code. | Tell your people, before they answer, what will and will not be visible. |
| Keep identity out of AI context and out of training data. | Decide whether AI features are enabled, in line with your own policy. |
| Host in your chosen region under the controls in section 07. | Choose that region with your legal and works council requirements in hand. |
| Provide export and deletion on request, and confirm completion. | Keep your member list current, and remove leavers promptly. |
| Notify you of a personal data breach within 24 hours of confirmation. | Maintain your own notification path to your supervisory authority. |
| Give advance notice of any new sub-processor. | Review that notice, and object if it does not suit you. |
| Restrict administrator access to aggregate views only. | Grant administrator rights sparingly, and review them. |