How we prove who someone is, how we enforce what they are allowed to see, and the controls that stand behind both. Written for the people who have to sign off on us.
Humanness holds one of the most sensitive datasets an organisation can produce: how its people honestly feel about working there. That data is only worth collecting if it is genuinely safe. This document sets out how we keep it that way.
The five layers, and the assumption each one is designed to survive.
A dedicated identity platform, why we do not build login ourselves, and what that removes from the risk register.
Supported factors, enforcement policy, step up authentication, and recovery that cannot be talked past.
Federating with your own directory, provisioning, and instant off-boarding.
What a signed in browser actually holds, how long it lasts, and how we revoke it.
Roles, least privilege, and the boundary that stops one customer's query reaching another customer's data.
Transport, input validation, secrets, dependencies, and the controls in the delivery pipeline.
How we find out, how fast we tell you, and what we test before you have to ask.
A single reference table for your security questionnaire.
We design on the assumption that any single control will eventually fail. Each layer below is therefore built to hold even when the layer above it has already been defeated.
Authentication is delegated to a dedicated enterprise identity platform. Credentials are verified on infrastructure built for nothing else, and never pass through our application. Assumption it survives: our application code contains a flaw.
Multi-factor authentication with phishing resistant options. Assumption it survives: a person's password has already been leaked in a breach somewhere else and reused here.
Roles and organisation scope are re-evaluated server side for every single request, never trusted from the browser. Assumption it survives: an attacker holds a valid session for a legitimate low privilege account.
Each customer's data sits in its own database instance on a private network. Assumption it survives: an authorisation check has been missed somewhere in the application.
Encrypted in transit and at rest, with the smallest useful dataset and the shortest defensible retention. Assumption it survives: someone has obtained a copy of the storage itself.
Nothing the browser tells us is trusted. Identity, role, organisation membership and group size thresholds are all determined on the server, from the session, on every request. A modified request from a legitimate user gets the same answer as an unmodified one.
Authentication is the single highest consequence piece of code in any application, and the one most often written badly. We do not write ours. Humanness authenticates through a dedicated enterprise identity platform used by regulated banks, healthcare providers and public sector bodies.
When login is built into an application, every credential in the system is only as safe as that application's weakest route. A dependency flaw, a logging mistake, or a single missed check can expose passwords for everyone. Delegating identity removes that whole class of risk, because there is nothing in our application to expose.
The consequence is worth stating plainly: an attacker who fully compromised the Humanness application would still not obtain a single user password, because we have never had one to lose.
Because identity is handled by a platform that does nothing else, it applies protections that would be impractical for us to build and maintain alone.
| Control | What it does |
|---|---|
| Modern password hashing | Passwords are stored only as salted hashes using a deliberately slow, memory hard algorithm, which makes offline cracking economically impractical. |
| Breached password detection | Credentials are checked against a continuously updated corpus of passwords exposed in third party breaches. A person cannot set, or keep using, a password already known to attackers. |
| Brute force protection | Repeated failures against one account trigger progressive delays and lockout, with notification to the account holder. |
| Credential stuffing defence | Distributed attempts across many accounts from shared infrastructure are detected as a pattern and blocked, which per account limits alone would miss. |
| Bot detection | Automated traffic is identified and challenged before it reaches the credential check at all. |
| Anomaly detection | Impossible travel, a new device, a new country or a suspicious network raises the risk score for that attempt and can force a second factor. |
| Password policy | Minimum length and complexity, rejection of dictionary and context based guesses, and enforced rotation where your policy requires it. |
Password reset is handled by the identity platform, using single use, time limited, cryptographically random links delivered to the verified email address. A reset link cannot be reused, cannot be extended, and is invalidated the moment it is consumed or a newer one is issued. Support staff cannot see, set or reset a password on someone's behalf, which closes the social engineering route that defeats many otherwise strong systems.
Where a security questionnaire asks whether you store passwords, hash them, and how you protect the hashes, the accurate answer for Humanness is that we do not store credentials at all. Verification happens at a certified identity platform, and we receive only a signed assertion of who the person is.
Passwords leak. They get reused across a personal account and a work account, they get typed into a convincing imitation of a login page, and they get exposed in breaches of systems that have nothing to do with us. Multi-factor authentication is what makes that survivable.
| Factor | How it works | Phishing resistant |
|---|---|---|
| Passkeys and security keys | Public key cryptography bound to the device and to our domain, using WebAuthn and FIDO2. Unlocked by fingerprint, face or device PIN. | Yes, strongly. Recommended. |
| Authenticator app | A six digit time based code from any standard app, such as Microsoft Authenticator, Google Authenticator or 1Password. | Partially |
| Push notification | An approve or deny prompt on a registered device, showing the location and context of the attempt. | Partially |
| Email one time code | A single use code to the verified address. Available as a fallback where no stronger factor can be registered. | No |
| Recovery codes | Single use codes, issued once at enrolment, to be stored offline. Each works exactly once. | Not applicable |
We favour passkeys because they cannot be phished. The credential is cryptographically bound to our domain, so a fraudulent site that looks identical to ours simply cannot elicit a usable response. Where your policy prohibits SMS as a factor, that is our default position too, which is why it does not appear above.
Asking for a second factor on every single sign in trains people to approve prompts without reading them, which is precisely how push fatigue attacks succeed. Risk based policy is therefore evaluated on each attempt, and a challenge is raised when the signals justify it.
You can override this and require a factor on every sign in if your policy demands it. The default balances real protection against the habituation that undermines it.
Some actions deserve a fresh proof of identity even inside a valid session, because the cost of getting them wrong is not recoverable. We re-challenge for:
Promoting a member to administrator, or changing who can see organisation wide results.
Exporting a full organisational dataset, or deleting an assessment round.
Changing multi-factor policy, single sign on configuration, or session lifetime.
Removing members in bulk, or closing the organisation account.
Most successful attacks on multi-factor authentication do not break the cryptography. They call the help desk. Our recovery path is therefore deliberately narrow: a person uses a recovery code they were issued at enrolment, or an administrator in your organisation resets their enrolment, which is logged, notified to the individual, and requires the administrator's own second factor. Humanness support staff cannot reset a second factor. If you ask us to, we will tell you no, and point you at your own administrator.
If you already run an identity provider, the safest thing we can do is get out of its way. Humanness federates with your directory so your existing policy, your existing factors and your existing off-boarding all apply here without duplication.
Password rules, factor requirements, conditional access, device compliance and session lifetime are all enforced by your provider. We honour the result.
Disabling someone in your directory ends their access to Humanness. No separate account lingers, and nothing depends on an administrator remembering to remove them here as well.
Accounts, departments and role assignments can be created and updated from your directory, which keeps the member list accurate without manual maintenance.
People never set a Humanness specific password, so there is no separate credential to reuse, leak or be tricked out of.
Single sign on and direct login can run side by side during a transition, then direct login can be switched off entirely so federation is the only way in. We recommend closing that door once migration is complete, and will confirm in writing when it is closed.
Authentication proves who someone is once. A session is what carries that proof forward. Handled carelessly it becomes the easiest thing in the system to steal, so it gets the same attention as the credential itself.
A single signed session cookie. It carries a user identifier, organisation membership, role and an expiry, and it is cryptographically signed by our server so any tampering invalidates it. It does not contain a password, an email password, a payment detail, or anything an attacker could use elsewhere.
| Cookie property | Setting and why |
|---|---|
| HttpOnly | Set. The cookie is invisible to JavaScript, so a cross site scripting flaw cannot read the session out of the browser. |
| Secure | Set. The cookie is only ever transmitted over TLS, never over plain HTTP. |
| SameSite | Lax, so another site cannot induce a browser to make an authenticated request on the user's behalf. |
| Signature | Verified server side on every request against a secret held in our secrets manager. A forged or edited token is rejected. |
| Scope | Bound to our own domain, with no wildcard subdomain sharing. |
An administrator can end a member's access immediately. Removing a member, changing their role, or disabling them in your directory takes effect on their next request rather than at their next sign in. We do not rely on a token simply expiring in its own time when someone's access should have ended.
Proving identity is only half the problem. The other half is making sure a correctly authenticated person reaches exactly what they should and nothing more. This is where most real data exposure in multi-tenant software originates.
| Role | Can |
|---|---|
| Member | Complete assessments, see their own results and history, hold private coaching conversations. Cannot see another individual's data, or organisation wide reporting unless you grant it. |
| Owner | Everything a member can, plus invite and remove people, configure assessments, and view aggregated reporting subject to the minimum group size rules. Cannot see an individual's answers or conversations. |
| Individual | A person using Humanness for themselves, with no organisation attached. Their data is visible to them alone. |
Note what is absent: there is no role, at any price, that reveals a named individual's assessment answers or coaching conversations to somebody else. It is not a permission we withhold. It is a capability the product does not have.
Authorisation is not a property of the interface. Hiding a button is presentation, not security. Every request that touches data performs the full check on the server: the session is verified, the user is loaded, their organisation and role are read from our own records rather than from the request, and the query is scoped to that organisation. A request naming another organisation's identifier returns nothing.
Each client organisation's data sits in a dedicated database instance rather than shared tables partitioned by a customer column. A missed filter in application code is the classic cause of cross tenant leakage, and a separate instance means such a mistake has nowhere to leak to. Those instances sit on a private network with no public address.
The controls below are unglamorous and they are where most real attacks are stopped. They are applied by default rather than configured per deployment, so there is no environment where somebody forgot.
Credentials, signing keys and API keys live in a managed secrets store, injected into the runtime as environment values and never written to source control. Access is logged, rotation is supported without redeployment, and our repositories are scanned automatically for accidentally committed secrets on every push.
Volumetric and protocol attacks are absorbed at the network edge before traffic reaches the application, by infrastructure whose capacity is orders of magnitude larger than any single tenant would ever provision. Application level abuse is handled by the rate limits described above.
Background checks appropriate to role, confidentiality obligations in every contract, security awareness training at induction and annually, and access removed on the day someone leaves.
Company devices are encrypted at rest, enrolled in management, automatically patched, screen locked, and remotely wipeable.
Multi-factor authentication is mandatory on every internal system. Credentials are held in a managed password manager and never shared.
Production changes are logged with an author and a reason. Emergency changes follow the same path, reviewed immediately afterwards.
Controls that are never tested are assumptions. The purpose of this section is to describe how we find out that something is wrong, and what happens in the hours after we do.
Logs deliberately exclude request bodies, assessment answers, conversation content and credential material, because a log store is a second copy of your data and we would rather it were not one. Logs are retained for twelve months.
| Activity | Frequency | Output |
|---|---|---|
| Automated test suite | Every change | Blocks merge on failure |
| Dependency scanning | Continuous | Automated patch pull requests |
| Independent penetration test | Annual, and before major releases | Summary report available to clients under NDA |
| Access review | Quarterly | Documented revocations |
| Backup restore test | Quarterly | Verified recovery time |
| Incident response exercise | Annual | Updated runbook |
We publish a security contact and will work in good faith with anybody who reports a vulnerability responsibly. We do not threaten researchers who follow that path. If you would like to test us yourself, tell us and we will agree a window and a scope rather than blocking you.
We maintain a documented incident response plan with severity levels, a named incident lead, and predefined communication paths. It is rehearsed, not filed.
| Stage | What happens |
|---|---|
| Detect | Automated alerting, log review, or an external report. On call cover is continuous. |
| Contain | Isolate the affected component, revoke credentials and sessions, and stop the bleeding before investigating the cause. |
| Assess | Establish what data was involved, whose it was, and whether it was accessed or only exposed. |
| Notify | Where your data is affected, we contact you without undue delay and in any case within 24 hours of confirmation, with the facts as established. |
| Remediate | Fix the cause, verify the fix, and restore normal service. |
| Learn | A written post-incident review, shared with affected clients, covering cause, impact, timeline and the changes we made. |
You will hear about a security incident affecting your data from us, and you will hear it early, including while the picture is still incomplete. We would rather send you an awkward message on day one than a tidy one on day ten.
A single reference for the questions security questionnaires ask most often. Each row is expanded earlier in this document.
| Control | Position |
|---|---|
| Password storage | None. Credentials are never held by Humanness. |
| Identity platform | Dedicated enterprise platform, certified, OpenID Connect and OAuth 2.0. |
| Multi-factor authentication | Passkeys, authenticator apps, push, email fallback, recovery codes. Mandatory for administrators. |
| Single sign on | SAML 2.0 and OpenID Connect, with automated provisioning. |
| Encryption in transit | TLS 1.2 minimum, 1.3 preferred, HSTS enforced. |
| Encryption at rest | AES-256 for databases, storage and backups, with managed key rotation. |
| Tenant isolation | Dedicated database instance per client, on a private network with no public address. |
| Access control | Role based, enforced server side on every request, scoped from the session. |
| Individual answer visibility | Not available to any role. Minimum group sizes enforced in code. |
| Audit logging | Authentication, authorisation denials and administrative actions. Retained 12 months. |
| Penetration testing | Annual and pre-release, by an independent third party. |
| Breach notification | Within 24 hours of confirmation. |
| Data centre certifications | ISO 27001, SOC 2 Type II, PCI DSS held by the operators of our hosting regions. |
| Availability target | 99.9 percent monthly, externally measured. |
This volume is written to be handed to a reviewer without a covering explanation. If you are completing a security questionnaire about us, the three notes below will save you the most time.
Questions about password storage, hashing algorithms and salt handling do not apply to us, because credentials never reach our systems. Section 02 gives you the wording to explain why, which reviewers accept more readily than a blank field.
The strongest answer to "could a manager see one person's answers" is that the capability does not exist rather than that a policy forbids it. Section 06 and the privacy volume both cover this.
Penetration test summaries, the data processing agreement and the sub-processor register are ready to send and usually clear the remaining questions in one pass. Requesting them at the start of a review rather than the end tends to shorten it considerably.
Penetration test summary under NDA, current sub-processor register, data processing agreement, business continuity plan summary, and completed responses to your own security questionnaire.