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.

Why this data needs to live in one governed place

It's fair for IT to ask why a research team can't just use the inbox, spreadsheets, and shared drives it already has. The answer is that participant data isn't a static archive, it actively drives the work. It's who you recruit, who you follow up with, the segments you target, and the evidence behind every product decision. Spreading it across personal inboxes and ad-hoc folders is exactly how it ends up ungoverned: no access controls, no audit trail, and no way to honor a deletion request when it comes.

A dedicated, properly secured research platform isn't a wider attack surface than the status quo, it's a narrower one. It replaces a dozen uncontrolled copies with a single system where permissions, retention, and logging actually apply, and where access can be switched off the moment someone leaves. That's the case to make when IT asks why the tool, and the integration behind it, is worth approving.

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? 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?

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

These can quickly become dealbreakers during the review process. How users login and what they can do an access almost always needs to align with your internal access protocol. An employee who is unable to export a list of customers from your CSM, shouldn't be able to do so in your research platform.

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.

4. Compliance, in plain language

At least one of these terms will come up in your security review. Here's what to know so you know what questions to ask. 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.

Restrict participant identity with PII masking

Some platforms let you mask participant identities from the people reviewing results, so personal details stay visible only to the team members who genuinely need them. 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, 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.