Safety & security

Research data is sensitive. Client names, contact details, opinions people didn’t expect to share publicly. This page explains how Curio Schools handles that, without the sales pitch.

1. Workspace isolation

Your account is a separate workspace. Other customers cannot see your data.

Every survey, question, response, and quota belongs to one workspace. When your team is logged in, they only reach data inside your company’s workspace.

Credentials that power anonymous survey-taking stay on the server. They never appear in the browser, so respondents can’t inspect or copy them.

If a client asks whether their data sits next to another client’s data, the answer is no.

2. Respondent sessions

Anonymous respondents don’t get accounts. They get a protected session.

When someone opens a survey, Curio Schools creates a session with a token in an httpOnly cookie (page scripts can’t read it). Submitting or editing answers requires that session. A guessed or forwarded link alone isn’t enough to change someone else’s response.

Draft preview stays inside your workspace. Preview does not create real responses or move quotas.

Respondent uploads (e.g. photos) go to private storage with size and type limits, not a public URL by default.

3. Access control and team permissions

Roles limit who can change or delete what.

Company admin: workspace settings, team, and billing actions on your plan. Builder: create and edit surveys; can be limited to studies they own. Viewer: read-only where enabled.

Platform administration (global settings, marketing site, etc.) is separate and handled by Curio Schools operators, not customer roles.

A junior researcher can be scoped so they can’t delete a client’s study.

4. PII handling and exports

Flag sensitive questions and control what leaves the platform in a file.

Mark questions as PII in the builder. On export, include or mask PII; masked values appear redacted in the file.

CSV and Excel exports sanitize cells that could be read as spreadsheet formulas, which reduces risk when someone opens the file in Excel.

Exports are only for authorized workspace users. There is no public export link.

Useful when you need to share results without sending raw emails or phone numbers.

5. Deletion and retention

Remove data when a project ends, not just hide it.

Delete one response: remove a single respondent’s answers (with confirmation). Clear all responses: wipe every answer for a survey and reset response count and sample-size counters (with confirmation). Delete a survey: permanently remove the study, questions, responses, quotas, and share links (typed confirmation required).

Survey deletion is immediate. There is no delayed purge that never runs.

6. Abuse protection and availability

Public surveys are on the internet; we throttle obvious abuse.

The respond API rate-limits starts, navigation, and uploads per IP. Invalid or excessive traffic gets a “slow down” response instead of overloading your study.

For high-risk or high-visibility fieldwork, consider edge protection (CDN or WAF) in front of your deployment. Ask us if you want help thinking that through.

7. Encryption and infrastructure

Encrypted in transit; sensitive secrets encrypted at rest in the app.

All web traffic uses HTTPS. Database and file storage run on Supabase (managed Postgres and storage).

Integration credentials (e.g. SMS provider keys) are encrypted before they’re stored, not kept as plain text in the database.

Server-only secrets never ship in the public site or respondent app.

If you have a security questionnaire or need a walkthrough before a client signs off, contact us. We’ll answer from what’s actually built, not from a generic checklist.