Security
You are about to put your colleagues' personal data - including health information - into someone else's software. Here is exactly what happens to it, in terms you can check rather than take on trust.
Your own database, hosted in the EU, encrypted backups tested monthly, and CoDash staff cannot get into your workspace unless you switch access on - visibly, temporarily, and with every action logged. The privacy promises are enforced in the code, not written in a policy: anonymous feedback genuinely has no author column, so there is nothing to reveal even if someone demanded it.
Can CoDash staff see our data?
Not unless one of your administrators lets us in. We hold no standing account on your workspace. When you need us to investigate something, your admin opens a support window from your own settings, for 8, 24 or 72 hours. While it is open:
- Everyone in your company sees a banner saying support has access and when it ends - not just admins. Our presence is visible to the people whose records we could look at.
- The support account is a named, visible user in your list, with no more permission than one of your own administrators.
- Every action is written to your audit log, and shows up in the affected person's “who has accessed my record” view.
- You can revoke it instantly, and it expires on its own.
We cannot grant ourselves access, extend it, or hide it. Most vendors have a support account that simply exists all the time; we decided that was incompatible with what we were asking you to believe.
What does “anonymous” actually mean here?
It means the database has nowhere to put a name. Anonymous feedback and suggestions are stored in tables with no author, user or created-by column at all - not blanked, not hashed, absent. If a manager demanded to know who wrote something, there would be no answer to give, and that is the point.
Mood, eNPS and survey results are only ever shown to managers as group figures, and only once the group is large enough that no individual can be inferred. A team of three does not get a “team wellbeing score” - because that score would be about identifiable people.
Where does our data live?
| Question | Answer |
|---|---|
| Where is it hosted? | The EU (France), with our error monitoring in the EU region too |
| Is it a shared database? | No - your own database, your own subdomain, your own application instance |
| Who are the sub-processors? | Listed in full in the DPA: hosting, transactional email, error monitoring, payments, and the AI coach where enabled |
| Is it encrypted? | In transit (TLS) and backups are encrypted at rest with AES-256 before they leave the server |
What happens if something breaks?
- Backups run nightly, encrypted, and are stored away from the server they came from.
- Restores are tested monthly - an automated drill decrypts the latest archive and rebuilds it. An untested backup is a rumour, not a backup.
- Monitoring runs off our own infrastructure, so if the server itself fails, the alerting does not fail with it.
- Application errors are captured with personal data stripped out: no user identifiers, no request bodies, and no stack-frame variables - the last of which is how error trackers usually leak the very records they are meant to help you fix.
What about our staff's rights?
The tooling is in the product, not a support ticket you have to raise with us:
- Subject access - one-click export of everything held about a person
- Erasure - a leaver's record is irreversibly anonymised in place, keeping the statutory history you must retain
- Retention - set a period and leavers are anonymised automatically
- Transparency - every employee can see who has accessed or changed their record
- Your data is yours - you can export the whole company at any time, including if you stop paying. We do not hold records hostage over an invoice.
Access control
Role-based separation across Admin, HR, Manager and Employee, enforced by a permission matrix in code rather than by hiding buttons. Two-factor authentication is available on every plan and can be enforced company-wide; single sign-on (OIDC) is available on Scale. Sickness reasons are restricted to HR roles, and pay information sits behind its own permission.
Certification: where we actually are
If you are more than about fifty people, someone will ask this in week one, so here it is without the hedging.
We are not ISO 27001 certified. We are not SOC 2 certified. No audit is in progress, and we are not going to imply otherwise by calling it “in flight”.
What we are doing instead
Certification is evidence that controls exist. These are the controls, and every one is checkable in the product today rather than promised:
- A separate database and file store per customer. Not a shared table with a tenant column - there is no query that can return another company's rows, because their data is not in the same database.
- EU-region hosting, with encrypted backups that are restore-tested rather than assumed.
- No hidden super admin. Support access is granted by you, time-boxed, self-closing, visible to everyone in your workspace, and refused at login the moment it expires.
- Permissions enforced in code - 131 permission keys checked server-side, not by hiding buttons in the interface.
- Health data restricted by design. Sickness reasons reach HR roles only; individual mood check-ins are never shown to managers, and anonymous feedback is stored with no author column at all - so there is nothing to disclose, not merely a rule against disclosing it.
- Two-factor authentication on every plan, enforceable company-wide, with OIDC single sign-on on Scale.
- An access log your employees can read, showing who opened or changed their record.
- Export at any time, including after you stop paying.
What we are not claiming
- We do not currently run scheduled third-party penetration testing.
- The live database volume is not separately encrypted at rest - it relies on the hosting provider's physical and logical controls, and on host access being restricted. Backups are encrypted.
- We have no formal, externally audited information security management system. That is precisely what ISO 27001 would be.
When
- ICO registration - ZC223521. Listed for completeness rather than as an assurance: ICO registration is a legal requirement for any data controller, not a security credential. Judge us on the architecture above instead.
- ISO 27001 - targeted for 2027. We are not going to claim a nearer date to win a deal and then miss it.
If CoDash ever shuts down
The question every buyer of a young product has and rarely asks: you would get at least 90 days' written notice, the service and its export tooling would stay up throughout, and you would leave with a complete export of your data. That is a commitment in our subscription agreement, not just a line on this page.
If any of that is a dealbreaker for your organisation, we would rather you knew in week one than during a security review in week six. Tell us early what your procurement needs and we will be straight about whether we can meet it - including saying no.
Questions we are happy to answer
Send a security questionnaire, ask for the DPA, or ask something awkward: support@codash.co.uk. Our data processing agreement covers the formal position, and the privacy notice covers what we collect about you as a customer.
See it before you trust it
The demo is a full working instance with realistic data. Poke at it, try to break the privacy claims, then come and ask us the hard questions.