How CultureMonkey secures your data
A plain-language overview of how CultureMonkey protects your employee data - tenant isolation, encryption in transit and at rest, access controls, data residency options, and anonymity as a security layer.
On this page
- The four layers of protection
- Tenant isolation: your data is walled off from everyone else's
- Encryption in transit
- Encryption and protection at rest
- Access controls: least privilege inside your organization
- Anonymity as a data-protection layer
- Data residency: US and EU regions
- Shared responsibility: what we secure, what you control
- Frequently asked questions
- Where to go next
Employee feedback is some of the most sensitive data an organization holds. When people tell you how they really feel about their manager, their workload, or their future at the company, they are trusting you to keep that information safe. CultureMonkey is built around that trust.
This article gives you a clear, non-technical overview of how your data is protected. It covers the four pillars that matter most: how each customer's data is kept separate (tenant isolation), how data is encrypted in transit and at rest, who is allowed to see what (access controls), and how anonymity adds protection on top of all of it. If you are being asked to sign off on CultureMonkey from a security or IT perspective, this is the place to start.
Every customer's data lives in its own isolated database space, so one organization can never see another's. Traffic is encrypted in transit with HTTPS, access is limited by role, and sensitive responses are protected by anonymity thresholds that hide any group too small to be safe. Together these controls keep your feedback private and secure.
The four layers of protection
Security is not a single feature. It works best as a set of layers, so that if one control is bypassed, others still stand. In CultureMonkey those layers are:
- Tenant isolation keeps your organization's data physically separated from every other customer's.
- Encryption protects that data both while it travels across the internet and while it sits in storage.
- Access controls make sure that even inside your own organization, people only see what their role allows.
- Anonymity ensures that individual employees cannot be identified from their responses, even by administrators.
The rest of this article walks through each layer in turn, then covers data residency, the shared-responsibility model, and the questions we hear most often.
Tenant isolation: your data is walled off from everyone else's
CultureMonkey is a multi-tenant platform. That means many organizations use the same application, but each organization (a "tenant") gets its own isolated slice of the data layer. The important thing to understand is that "shared application" does not mean "shared data."
Under the hood, CultureMonkey gives each customer its own dedicated database schema - effectively a separate, named container inside the database that holds only that customer's tables and records. When you log in through your company's subdomain (for example, yourcompany.culturemonkey.io), the platform identifies your tenant from that address and routes every request to your schema and only your schema for the duration of that request.
The practical effect is strong separation:
- No cross-tenant queries. Your employees, surveys, and responses live in your schema. A request scoped to your tenant cannot read another tenant's tables, because it is never pointed at them in the first place.
- Isolation by default, not by filter. Some systems keep everyone's data in one big shared table and rely on a
WHERE company_id = ?filter on every query to keep it apart. A single missing filter in that model can leak data. CultureMonkey's schema-per-tenant approach means separation is handled at the database routing level, not left to individual queries to remember. - Cleaner data lifecycle. Because your data sits in its own container, operations like exporting or removing a tenant act on that container as a unit.
"How do you keep our data separate from other customers?" is usually the first question a security team asks about any SaaS tool. CultureMonkey's answer is architectural: separation is built into how the database is structured, so it holds even if application code has a bug.
Encryption in transit
Every interaction with CultureMonkey happens over HTTPS (TLS). Whether an employee is answering a survey on their phone, an admin is reading a report, or your HRIS is syncing employee records through an integration, the connection is encrypted so the data cannot be read or tampered with as it crosses the internet.
A few specifics worth knowing:
- Connections are forced to HTTPS. Requests that arrive over plain HTTP are upgraded to the secure equivalent, so data never travels unencrypted.
- CultureMonkey uses HTTP Strict Transport Security (HSTS), which instructs browsers to only ever connect over HTTPS. This protects against downgrade attacks where an attacker tries to force an insecure connection.
- The same encrypted transport applies to API calls and integrations, not just the web app, so the data flowing between CultureMonkey and your other systems is protected too.
In short: from the moment data leaves an employee's device to the moment it reaches our servers, it is encrypted end to end.
Encryption and protection at rest
"At rest" means data that is stored - sitting in the database, in backups, or in file storage - as opposed to data that is moving. CultureMonkey protects stored data through a combination of infrastructure-level encryption provided by our cloud hosting and application-level safeguards for the most sensitive fields.
Two application-level safeguards are worth calling out because they are visible in how the product behaves:
- Passwords are never stored in plain text. Admin and participant passwords are stored as one-way bcrypt hashes. Even someone with direct database access cannot read the original password, because a hash cannot be reversed back into the text it came from. When you log in, the system hashes what you typed and compares the hashes.
- One-time passcodes. For flows that use a one-time passcode (OTP) instead of a password, those codes are time-limited and expire quickly, so a captured code is useless after a short window.
This article deliberately avoids naming specific encryption algorithms, key-management services, or compliance certifications where they could not be confirmed from the product itself. For the exact technical specifications your security team needs (cipher suites, key rotation, certifications), please request CultureMonkey's security documentation or reach out to your account contact.
Access controls: least privilege inside your organization
Isolation keeps other companies out. Access controls decide who inside your own organization can see and do what. CultureMonkey uses role-based access so that people only get the visibility their job requires, following the principle of least privilege.
The main roles are:
| Role | Typical use | What they can generally see |
|---|---|---|
| Super Admin | HR or People team owner of the account | Full account: all surveys, all reports, settings, and user management |
| Sub Admin | Regional HR, HRBPs, or delegated admins | A scoped slice of the account, often limited to certain teams, locations, or surveys |
| Manager | People managers | Results for their own team only, always subject to anonymity thresholds |
| Report Viewer | Leaders who need read access | Reports they have been granted, without edit or admin rights |
This structure means a frontline manager cannot browse the whole company's raw feedback, and a leader granted report access cannot change survey settings or export employee lists. Admins decide who holds each role, so you stay in control of your own access model.
On top of roles, CultureMonkey supports enterprise sign-in controls:
- Single sign-on (SSO) via SAML lets you centralize admin authentication in your own identity provider, so access follows your corporate joiner-mover-leaver process and de-provisioning is immediate when someone leaves.
- One-time passcode (OTP) verification adds a second factor to certain login and access flows.
To go deeper on exactly which roles see which responses, read Who can see survey responses?.
The platform gives you the controls, but the review discipline is yours. Periodically check who has Super Admin and Sub Admin access, remove people who have changed roles, and prefer SSO so that access is governed by your identity provider rather than standalone passwords.
Anonymity as a data-protection layer
Anonymity is usually described as a feedback feature, and it is - honest feedback depends on people trusting that their individual answers will not be traced back to them. But anonymity is also a genuine security control. It reduces the amount of identifiable, sensitive data that anyone, including your own administrators, can ever see.
Here is how it protects data in practice:
- Individual responses are decoupled from identities in reporting. In an anonymous survey, the reports show aggregated results, not "who said what." Admins read the sentiment, not the name attached to it.
- Small groups are hidden automatically. CultureMonkey enforces a minimum response threshold before it will show results for any group. By default a group needs at least 3 responses before its results appear. If you filter a report down to a team of two, or slice the data so narrowly that only one person's answer would remain, CultureMonkey withholds the result rather than risk exposing an individual.
- This applies everywhere. The threshold protects every breakdown - by team, location, manager, or custom attribute - so no combination of filters can be used to isolate a single person's response.
The reason this is a security control and not just a courtesy is that it limits data exposure by design. Even a well-intentioned admin cannot accidentally (or deliberately) narrow a filter to unmask one employee, because the platform stops showing the data before that point.
For the full picture of how anonymity is enforced and where the thresholds apply, see How anonymity works.
Access controls limit who can open a report. Anonymity limits what that report can ever reveal about an individual. Together they mean that even a person with legitimate access to results cannot use them to identify a specific respondent in a protected group.
Data residency: US and EU regions
Where your data physically lives matters for privacy regulations like the GDPR. CultureMonkey operates separate regional environments, including a European Union region (served from app.culturemonkey.eu) alongside its primary environment. This lets organizations that need their employee data to remain within the EU choose a region that supports that requirement.
If data residency is a requirement for your organization, confirm the available regions and the specific commitments with your CultureMonkey contact before rollout, so the account is provisioned in the right place from the start. Migrating regions after launch is far more disruptive than choosing correctly up front.
Shared responsibility: what we secure, what you control
Good security in any SaaS platform is a partnership, so it helps to be clear about which side owns what.
CultureMonkey is responsible for the security of the platform itself: tenant isolation, encryption in transit, the underlying infrastructure and its at-rest protections, the authentication system, and enforcing anonymity thresholds.
You are responsible for how you use it:
- Managing who has access. Assign roles carefully, review admin lists regularly, and remove access promptly when people change roles or leave.
- Choosing your survey settings. Whether a survey is anonymous or identified is your call, and it directly affects how much identifiable data exists.
- Protecting exported data. Once you export a report or employee list, that file is under your control and your own data-handling policies apply.
- Governing your identity provider. If you use SSO, the security of your IdP and its offboarding process becomes part of your access story.
Frequently asked questions
Can another company using CultureMonkey ever see our data?
No. Each customer's data lives in its own isolated database schema, and every request is routed to your tenant based on your subdomain. There is no shared table of everyone's responses, so there is no path for one tenant to read another's data.
Is our data encrypted?
Yes for data in transit: every connection uses HTTPS (TLS), forced and hardened with HSTS, covering the web app, the API, and integrations. Stored data is protected at the infrastructure level, and specific sensitive items like passwords are stored only as irreversible bcrypt hashes. For the precise at-rest encryption specifications, request CultureMonkey's security documentation.
Can an admin see who gave a specific answer?
Not in an anonymous survey, and not for any group below the response threshold. Reports are aggregated, and the minimum-response threshold (3 by default) prevents any filter from narrowing results down to an individual. See How anonymity works for the full explanation.
Does CultureMonkey hold specific compliance certifications?
Compliance certifications are handled outside this help article, and this overview does not assert any specific certification. If you need details of CultureMonkey's certifications, audits, or compliance posture, please ask your account contact for the current security and compliance documentation.
Where is our data stored?
CultureMonkey offers regional environments, including a dedicated EU region, so organizations with data-residency requirements can keep employee data in the appropriate location. Confirm the exact region and residency commitments with your account contact before your account is provisioned.
What happens to our data if we leave?
Data handling on account closure, along with retention periods and deletion, is covered in detail in Data privacy, retention, and deletion.
Where to go next
- Understand the privacy layer in depth: How anonymity works
- See exactly who can view results: Who can see survey responses?
- Retention and deletion: Data privacy, retention, and deletion
Your feedback helps us improve the Help Center.