The UX research security and governance guide

1. Why research data is a security problem

Research tools quietly hold some of the most sensitive data your company owns. Look at what's actually sitting in a typical research platform:

• Customer names, email addresses, and job titles
• Recorded video and audio of real people
• Screen recordings that can capture anything on a participant's screen
• Verbatim opinions, sometimes about competitors, sometimes about your own company's failures
• Incentive payment records, which means financial and tax data

Any one of these would trigger a security review on its own. A research platform holds all of them in one place, which is exactly why IT and legal care so much about which tool you pick.

There's a second reason researchers underestimate this. The data isn't just yours. It belongs to the participants who trusted you with it. If a participant tells you something candid in an interview and that recording leaks, or gets used in a way they didn't agree to, that's a breach of their trust and very possibly a breach of law. Getting security right is part of doing research ethically, not just a box IT makes you tick.

So the goal here isn't to turn you into a security engineer. It's to help you choose a tool that won't blow up in the review, and to give you the language to defend that choice.

2. The questions to ask before you trial anything

The best time to ask a vendor about security is before you start a trial, not after. Asking up front does two things: it filters out tools that will never pass your review, and it gets you written answers to hand to IT later. There are five areas worth covering.

Data ownership and portability. Do you own everything you put in, including recordings and transcripts? Can you export and delete all of it on demand? And do they use your data to train AI models? You want a clear no, or at least an opt-out.

Authentication and access. Do they support SSO via your identity provider, how granular do the permissions get, and can you restrict who exports or downloads recordings?

Compliance and certifications. Are they SOC 2 Type II certified, and will they share the actual report under NDA? Are they GDPR compliant and willing to sign a DPA? Where is your data physically stored?

Sub-processors. Who else touches your data (hosting, AI, transcription, payments) and where are they based? This is the part security teams dig into hardest.

Incident handling. What's their breach notification timeline, and do they run regular penetration tests?

If a vendor can't answer most of these, or gets cagey about the SOC 2 report, treat that as the answer.

3. Authentication and access control

This is where most research tools quietly fail at scale. A tool can be perfectly secure in theory and still be a problem if everyone logs in with a shared password and every user can see every study.

Single sign-on (SSO)

SSO lets people log in through your company's identity provider instead of a separate username and password. It matters for security because when someone leaves the company, IT switches off their access in one place and they instantly lose access to your research data too. Without SSO, an ex-employee's login can sit active for months. Most security teams now treat SSO as a hard requirement, so check it's supported on a plan you'd actually buy, not locked behind a custom enterprise tier you can't reach.

Role-based permissions

The question to ask is how granular the controls get. Can you say 'this contractor can see this one study but nothing else'? Can you stop most of the company from viewing raw recordings while still letting them read the polished insights? A repository where everyone sees everything is a leak waiting to happen, especially once PMs, designers, and execs all have logins.

Export and download controls

The riskiest moment for research data is when it leaves the platform. Once a recording is downloaded to someone's laptop, you've lost control of it. Look for the ability to restrict who can export or download, so sensitive recordings stay inside the tool where your permissions and audit trail still apply.

A good test: ask the vendor to show you how they'd set up access for a temporary contractor who should only touch one project. If that's hard or impossible, scaling the tool across your org will be painful.

4. Compliance, in plain language

These terms come up in every security review. Here's what they actually mean, so you can read a vendor's answers and know whether they're real. Tap each one to expand.

You don't need to memorize these. You need to recognize them when IT raises them, and know which ones actually apply to your situation so you're not chasing certifications you'll never use.

5. Participant PII and privacy

Personally identifiable information (PII) is anything that identifies a real person: name, email, face on a recording, voice. Research is full of it, and most teams handle it more loosely than they'd admit.

The core risk is over-exposure. You run a study, and suddenly the recording, with the participant's face and full name, is visible to forty stakeholders who have no reason to know who that person is. The participant never agreed to that. It's a privacy problem and, in regulated industries, a compliance one.

Collect only what you need

If a study doesn't need participants' real names attached to their answers, don't attach them. Less PII in the tool means less to protect.

Separate the insight from the identity

The thing stakeholders usually need is the finding, not the person. Look for tools that let you share insights, highlights, and themes without exposing the underlying participant identity.

Use concealed-identity or blind studies for sensitive work

Some platforms can run a study where participant identities are masked from the people reviewing results. This matters a lot in finance, healthcare, and any research touching a vulnerable group, or any time you're researching your own employees and anonymity is the whole point. If your research regularly touches sensitive topics, this should be near the top of your requirements list.

Get consent that matches reality

Make sure participants actually agree to how their data will be used and shared, including recording and storage. A good tool makes consent part of the flow instead of something you bolt on.

Privacy isn't only a legal safeguard. It's what makes participants honest with you. People share more when they trust the data won't be used against them.

6. Audit trails and data retention

Two less glamorous topics that security teams always ask about, and that you'll be glad to have answers for.

Audit trails

An audit trail is a record of who did what: who viewed a recording, who exported an insight, who shared a study externally. You want this for two reasons. First, if something does leak, you can trace it. Second, just knowing actions are logged changes behavior, so people are more careful with sensitive data. Ask whether the platform logs access and exports, and whether admins can review that log.

Data retention

This is about how long data sticks around and what happens when it should go. Old recordings you've forgotten about are pure risk: they hold PII, they serve no purpose, and they're still a liability if breached. Good tools let you set retention rules, so data is automatically deleted after a set period, and make it easy to delete specific participants' data on request (which GDPR may require). Ask what the default retention is, whether you can configure it, and how participant deletion requests are handled.

Neither of these will be the headline of your tool decision. But when IT asks 'can you tell me who accessed this recording and how long we keep it,' having a clean answer is the difference between a fast approval and a stalled one.

7. Getting through procurement

You've chosen a tool and it's passed the security review. Procurement is the last stretch, and a little prep saves weeks.

Before the review, get the vendor questionnaire answered in writing, the SOC 2 Type II report into IT's hands, and the DPA in front of legal. Confirm SSO is available on the plan you actually intend to buy, not a tier above it. Raise anything industry-specific, like a HIPAA BAA or ISO 27001, early, because those take the longest to clear.

During negotiation, confirm SSO and admin controls are included rather than a paid add-on you'll discover later, that the contract covers the team size you're growing into, and what happens to your data when the contract ends. Check the renewal terms while you're at it.

One thing worth remembering on cost: the cheapest tool on paper is often the most expensive once you add the three or four other tools it forces you to buy to fill its gaps. Compare the full job, recruiting participants, running studies, and storing insights, not the line-item price of one piece of it.