Security and data
Where the data lives, and who can reach it
Written for the person whose job it is to ask. If something here isn't enough, or you need it on your own paper, email support@psychsafety.com and you'll get a person who built this, not a form.
The short version. Respondents give us no name, no email address, no employee ID and no IP address. There is nothing in a team's answers that identifies who gave them — which means, for the survey itself, there is very little personal data for anyone to process, protect or leak.
That is architecture, not policy. It is also the reason most of the questions below have short answers.
Who is the controller, and who is the processor?
This is usually the first question, and the answer is unusual enough to be worth stating carefully.
Your team's answers
A response carries a rating per question, optional free text, the date it was submitted and nothing else. No name, no email, no IP address, no device identifier, no time of day. Because we never receive identifying information about your employees, we are not processing your employees' personal data on your behalf — there is no identifiable person attached to a response for anyone to act on.
Two honest qualifications, because absolute claims in this area are usually wrong:
- Someone can type a name. Free-text comments are written by people, and a person can write "my manager said…" or name a colleague. We can't prevent that. Comments are shown to the organiser and, once released, to the team — the same people who were in the room. They go nowhere else.
- Our infrastructure providers keep short-lived technical logs that include IP addresses, as every web host does. We don't use them, we can't join them to any response, and retention is set as short as their tooling allows.
Organisers
The person who builds a survey gives us an email address, so we can send them a sign-in code and tell them when their report is ready. For that, Iterum Ltd is the controller — it's our own relationship with them, not something we do on an employer's instruction.
What this means in practice
Most organisations conclude a data processing agreement isn't needed for the survey data, because there is no personal data to process. If your legal team reaches a different conclusion, say so and we'll work through it rather than argue — we'd rather understand your reasoning than win the point.
Where it is
| What | Where | Region |
|---|---|---|
| Database and application logic | Supabase (managed PostgreSQL) | EU — Ireland |
| The website itself | Render | Served via CDN |
| Email delivery | SendLayer | Organiser emails only |
| Payments | Stripe | We never see or store card details |
These four are our only sub-processors. There is no analytics vendor, no advertising pixel, no session-recording tool, no third-party chat widget and no data broker. Nothing about your teams is sold, shared or used to train anything.
Who can see what
| Who | Can see | Cannot see |
|---|---|---|
| A respondent | Their own answers as they give them; the team report once released | Anyone else's answers |
| The organiser | The aggregate report for their own team, after it closes | Who answered, who said what, or individual responses |
| A licence administrator | Who holds a seat and how active they are; pooled findings across teams | Any individual team's report — at any price |
| Us | The database, as any vendor's engineers can | Any way to attribute a response to a person, because that link was never recorded |
During the preview, someone at Psych Safety may read a finished report to check it describes teams fairly. Respondents are told this before they start, it is the same aggregate report the team sees, and every such read is logged.
How it's protected
- In transit: TLS everywhere. The site is HTTPS-only.
- At rest: encrypted by the database provider.
- Sign-in: no passwords exist. An organiser receives a six-digit code by email, valid briefly and once. There is no password to reuse, phish or breach.
- Survey links: long random keys, stored only as hashes. We hold no copy that could be leaked and used.
- Access control: every read and write goes through a database function with its own permission check. There is no general-purpose API that returns rows.
- Backups: managed by the database provider, point-in-time.
- Payments: handled entirely by Stripe. Card details never reach our systems.
Retention
While the tool is in preview, surveys and responses are kept for as long as the pilot runs, and this page and the privacy page will carry a fixed schedule with a date when one is set. Infrastructure logs follow provider defaults, set as short as their tooling allows.
If you want a team's data removed, email us and we'll do it — and because responses aren't linked to people, removal is of the survey rather than of a person.
Availability, and what happens if something breaks
We are a small company and we won't pretend otherwise. What we do have:
- An automated check every hour for states that shouldn't be possible, which emails us when one occurs.
- A daily report of errors, usage and anything outstanding.
- A release gate that refuses to deploy if any check fails.
- Named people rather than a queue: Nick on the web application, Tom on infrastructure, systems and design, Jade on practice and interpretation. You'll get one of them, not a ticket.
If something goes wrong that affects your data, we'll tell you what happened, when, and what we did — without waiting to be asked.
Questions this page doesn't answer
If you need a signed data processing agreement, a completed security questionnaire on your own template, penetration test results, or a specific contractual commitment, email support@psychsafety.com. Some of those we can do immediately, some need a conversation, and we'd rather tell you which is which than go quiet.
Last reviewed 18 September 2026.