User research for compliance software: a complete guide for product and UX teams
How to conduct user research for compliance software. Covers screening compliance officers, handling sensitive audit data in sessions, research methods for GRC tools, and recruiting across compliance verticals.
Compliance software users do not tolerate friction the way other B2B users do. A compliance officer using your GRC platform is not browsing or exploring. They are racing a regulatory deadline, documenting an audit finding, or flagging a policy violation before it becomes a legal liability.
When your tool slows them down, the consequence is not a bad review. It is a missed filing, a regulatory penalty, or an audit finding that escalates because the software made the workflow harder than it needed to be.
That makes user research for compliance software fundamentally different from other B2B product research. Your participants work with sensitive regulatory data they cannot share freely. Their workflows are shaped by external requirements (SOX, HIPAA, GDPR, ISO 27001) that your product must reflect precisely. And the gap between “what the software does” and “what compliance officers actually need” is often invisible without direct observation, because compliance teams build elaborate workarounds rather than complain.
This guide covers how product and UX teams conduct effective user research for compliance software, from choosing the right methods to screening participants who actually do compliance work daily.
Key takeaways
- Compliance software users are constrained by regulatory requirements that dictate their workflows. Research must explore how users navigate those constraints, not just how they interact with your UI
- Sensitive data handling is non-negotiable. Use mock audit data, anonymized scenarios, and isolated test environments in every research session
- Screen participants by compliance tasks and tool usage, not job titles. “Compliance officer” spans dozens of specialties across industries with vastly different daily workflows
- Segment research by compliance vertical (fintech, healthcare, infosec, AML/KYC). Mixing verticals in a single study produces insights that apply to none of them
- Usability testing with realistic compliance scenarios is the highest-value method because it reveals how regulatory pressure changes user behavior in ways interviews alone cannot surface
What makes compliance software research different from other B2B research?
Four factors distinguish compliance software research from standard B2B user research.
1. Workflows are externally defined. In most B2B software, users have flexibility in how they complete tasks. Compliance officers do not. Their workflows are dictated by regulatory frameworks (SOX Section 404, HIPAA Privacy Rule, GDPR Article 30). Your research must understand the regulation driving the behavior, not just the behavior itself.
2. Users work with sensitive data they cannot share. Audit findings, regulatory correspondence, internal investigation records, and risk assessments are confidential. Participants cannot screen-share their real dashboards or walk you through actual compliance cases. Every research session needs mock data and anonymized scenarios.
3. Error tolerance is zero. A compliance officer who misfiles a report, misses a deadline, or miscategorizes a risk faces personal liability in some jurisdictions. This changes how users interact with software. They double-check everything, avoid shortcuts, and resist unfamiliar interfaces. Your research must account for this risk-averse behavior pattern.
4. The buying decision is disconnected from daily use. Compliance software is typically purchased by CISOs, CFOs, or legal leadership. The daily users are compliance analysts, auditors, and GRC managers who had no say in the purchase. Research must cover both audiences but never conflate their needs.
Which research methods work best for compliance software?
The best compliance software research programs match methods to the regulatory context, not just the product phase.
| Method | Best for | Compliance considerations |
|---|---|---|
| User interviews | Understanding compliance workflows, pain points, and regulatory pressures | Ask about processes and frameworks, never about specific findings or open investigations |
| Usability testing | Validating task flows for audit prep, risk assessment, policy management | Use mock compliance data. Create realistic but fictional regulatory scenarios |
| Contextual inquiry | Observing real compliance workflows and workaround patterns | Requires organizational NDA. Observer must not view actual audit evidence or investigation records |
| Surveys | Benchmarking satisfaction, measuring feature priority across compliance teams | Keep short (under 5 minutes). Distribute through compliance communities, not cold email |
| Card sorting | Organizing compliance task taxonomies, regulatory framework navigation | Works well for restructuring how regulations and controls are categorized in the UI |
| Prototype testing | Testing new compliance dashboards, reporting interfaces, alert systems | Test with compliance-realistic scenarios (audit deadlines, control failures, escalation paths) |
Usability testing with compliance scenarios is the workhorse. It reveals behaviors that interviews miss, like how compliance officers create manual workarounds for tasks the software technically supports, or how they export data to spreadsheets because the built-in reporting does not match the format their regulator expects.
Qualitative methods are essential in discovery because compliance pain points are often invisible in analytics. A drop-off at step 3 of an audit workflow might look like a UX issue, but the real problem is that the software asks for data in a different order than the regulatory form requires.
How to handle sensitive compliance data in research sessions
Compliance professionals work with data that is legally protected, audit-sensitive, or subject to regulatory privilege. Your research protocol must make it impossible for participants to accidentally share protected information.
Safeguards for every session
| Safeguard | What it does | When to implement |
|---|---|---|
| Mock data requirement | All tasks use fictional companies, audit findings, and regulatory scenarios | During prototype and task design |
| NDA with confidentiality acknowledgment | Legally binds researcher to confidentiality regarding any compliance information | Before recruitment begins |
| Pre-session briefing | Remind participants to avoid sharing real audit data, investigation details, or regulatory correspondence | Start of every session |
| Isolated test environment | Prototypes do not connect to real GRC platforms or compliance databases | During usability testing |
| Recording consent with scope limits | Consent form specifies what will be recorded and who will access it | Before session recording begins |
| Data purging protocol | Delete any accidentally captured sensitive compliance information immediately | During and after sessions |
Creating realistic mock compliance scenarios
Generic test scenarios (“Complete this form”) fail in compliance research because they strip away the regulatory context that drives user behavior. Build scenarios that reflect real compliance pressure:
- Audit preparation. “Your company’s SOC 2 Type II audit begins in 3 weeks. You need to verify that 47 controls have current evidence attached. Walk me through how you would prioritize and complete this task.”
- Incident response. “A data breach has been reported affecting customer PII. You need to document the incident, assess regulatory notification requirements, and escalate to legal. Show me your process.”
- Policy update. “GDPR guidance has changed and 12 of your data processing agreements need updating. How do you identify which agreements are affected and track the updates?”
- Risk assessment. “Your quarterly risk assessment is due. You need to evaluate 5 new vendors against your organization’s risk framework. Walk me through your evaluation process.”
These scenarios produce richer data because participants engage with the task the way they would with real compliance work, rather than clicking through a generic prototype.
How to screen compliance officer participants
Screening for compliance research requires more precision than standard B2B participant recruitment. “Compliance officer” is not a single role. It spans regulatory compliance analysts, internal auditors, GRC managers, AML investigators, privacy officers, and information security compliance leads, each with different daily workflows and tool needs.
Screening criteria framework
Must-have criteria (disqualify if not met):
- Currently employed in a compliance, audit, or GRC role (not retired, not students, not adjacent roles like general legal counsel)
- Uses compliance or GRC software as part of their daily work (not just aware of it)
- Handles at least one of: audit preparation, regulatory reporting, policy management, risk assessment, or compliance monitoring
- Minimum 2 years in a compliance-specific role
Segmentation criteria (use to group participants, not to disqualify):
- Industry vertical (financial services, healthcare, technology, manufacturing)
- Company size (SMB, mid-market, enterprise)
- Regulatory frameworks managed (SOX, HIPAA, GDPR, PCI DSS, ISO 27001, SOC 2)
- Role seniority (analyst, manager, director, CISO/CCO)
- Current compliance tools used (Vanta, Drata, AuditBoard, ServiceNow GRC, LogicManager, manual/spreadsheet-based)
Screener questions that work
Keep screeners to 5-8 questions. Compliance professionals are busy and will abandon anything longer.
Behavioral questions (high filtering value):
- Which compliance or GRC tools do you use at least weekly? (Open text. Filters out non-practitioners)
- Describe a typical compliance task you complete at least once a month. (Open text. Articulation check: genuine practitioners give specific, detailed answers referencing real workflows and frameworks)
- Which regulatory frameworks do you actively manage compliance for? (Multi-select: SOX, HIPAA, GDPR, PCI DSS, ISO 27001, SOC 2, AML/BSA, CCPA, NIST, Other)
- How do you currently track audit evidence and control status? (Open text. Reveals tool maturity and whether they match your target user)
- What is the most time-consuming part of your compliance workflow? (Open text. Double-checks relevance and provides early research insight)
Demographic questions (low filtering value, save for the end):
- What is your current job title? (Open text)
- How many years have you worked in a compliance-specific role? (Range: 1-2, 3-5, 6-10, 10+)
- How large is your company? (Range: 1-50, 51-500, 501-5000, 5000+)
Red flags in screener responses
- Vague answers to workflow questions (“I help with compliance stuff”)
- Cannot name a specific regulatory framework they manage
- Lists compliance tools but cannot describe how they use them
- Job title includes “compliance” but actual work is general IT, HR, or operations
- Responses under 10 words to open-text questions
For more guidance on writing effective screeners, see our guide on how to write a screener survey.
How to segment compliance research by vertical
Compliance work varies dramatically by industry. A fintech compliance analyst managing AML transaction monitoring has almost nothing in common with a healthcare compliance officer handling HIPAA privacy reviews. Mixing them in a single study wastes both their time and yours.
Compliance vertical segmentation
| Vertical | Primary regulations | Key workflows | Research angle |
|---|---|---|---|
| Financial services | SOX, AML/BSA, PCI DSS, FINRA, CFPB | Transaction monitoring, suspicious activity reporting, financial reporting controls | ”Walk me through how you investigate a flagged transaction” |
| Healthcare | HIPAA, HITECH, FDA compliance, state health privacy laws | Privacy impact assessments, breach notification, BAA management, PHI access logging | ”How do you track and document PHI access across your systems?” |
| Technology/SaaS | SOC 2, ISO 27001, GDPR, CCPA | Vendor risk management, security control monitoring, data processing agreement tracking | ”Show me how you prepare evidence for your SOC 2 audit” |
| Manufacturing | ISO 9001, OSHA, EPA, import/export compliance | Quality management, environmental compliance, supply chain regulatory tracking | ”How do you document and track corrective actions after a quality finding?” |
| AML/KYC (cross-industry) | BSA, FATF, EU Anti-Money Laundering Directives | Customer due diligence, enhanced due diligence, suspicious activity filing | ”Walk me through your CDD process for a high-risk customer” |
Rule: Never mix more than 2 related verticals in a single study. Financial services and AML/KYC can be combined when the research is about shared workflows (like transaction monitoring). Healthcare and technology can be combined for studies focused on data privacy tooling. Otherwise, segment.
Common pain points compliance software research reveals
Research across compliance verticals consistently surfaces patterns that product teams miss without direct user observation.
Shadow workflows are everywhere. Compliance officers routinely export data from GRC platforms into spreadsheets to create the reports their regulators actually want. The software technically has reporting, but it does not match the format, structure, or level of detail the regulator requires. Research reveals these gaps; analytics alone does not.
Audit preparation dominates the user experience. Most compliance software is designed around steady-state monitoring, but users experience it primarily through the lens of audit preparation. The 4-6 weeks before an audit drive 60-70% of platform usage. If your product does not optimize for audit prep workflows, you are optimizing for the wrong use case.
Alert fatigue kills adoption. Compliance platforms that generate too many alerts, especially false positives, train users to ignore them entirely. Research with compliance officers reveals the threshold at which alerts become noise and how users develop mental filters that your product needs to support rather than fight.
Trust in automation is conditional. Compliance officers will trust automated evidence collection for low-risk controls but insist on manual verification for high-risk or audit-critical controls. Research helps product teams understand where automation is welcomed and where it creates anxiety.
Integration gaps force context switching. Compliance officers typically work across 4-7 tools (GRC platform, ticketing system, document management, email, spreadsheets, regulatory databases, internal wikis). Research reveals which integrations would eliminate the most painful context switches, rather than guessing based on feature requests.
How to recruit compliance professionals for research
Compliance professionals are a hard-to-reach population for research. They are time-constrained, cautious about sharing work details, and skeptical of unfamiliar processes.
Where to find compliance participants
- LinkedIn targeting. Search by title (Compliance Officer, GRC Analyst, Internal Auditor, Compliance Manager, Chief Compliance Officer) and filter by industry
- Professional associations. Society of Corporate Compliance and Ethics (SCCE), ISACA, IIA (Institute of Internal Auditors), ACAMS (for AML specialists)
- CleverX verified B2B panels. Pre-screened professionals with role verification, filtered by industry and regulatory framework expertise
- Compliance conferences and webinar attendee lists. GRC Summit, SCCE Compliance Institute, ISACA conferences
- Customer referrals. If you have existing compliance customers, ask them to refer peers at other organizations
Incentive benchmarks
| Segment | Rate range | Best incentive type |
|---|---|---|
| Compliance analysts (1-3 years) | $100-150/hr | Cash or gift card |
| Compliance managers (4-8 years) | $150-250/hr | Cash, professional development credit, or benchmark report |
| Directors and VPs of compliance | $250-400/hr | Advisory board membership, benchmark report, or peer networking opportunity |
| CISO/CCO level | $350-500/hr | Advisory board, early product access, or charitable donation |
Schedule sessions flexibly. Compliance officers have unpredictable schedules driven by audit timelines, regulatory deadlines, and incident response. Offer 30-45 minute sessions with easy rescheduling. Send reminders 48 hours and 24 hours before the session, plus a 2-hour text reminder.
For general participant recruitment strategies that apply across contexts, see our recruitment guide. For advanced sourcing strategies for specialized audiences, see our guide on recruiting niche research participants.
Frequently asked questions
Can you use real compliance data in usability testing?
No. Always use mock data. Real compliance data (audit findings, investigation records, regulatory correspondence) is confidential and may be legally privileged. Create realistic but fictional scenarios that reflect the structure and complexity of real compliance work without using actual regulatory data.
How many participants do you need for compliance software research?
Five to eight participants per compliance vertical per round. If you are researching a cross-vertical feature (like dashboard design), recruit 3-4 participants from each of your target verticals. Run multiple rounds as the product evolves rather than one large study.
Should you recruit compliance software buyers or daily users?
Both, but separately. Buyers (CISOs, CCOs, CFOs) evaluate based on vendor risk posture, integration capabilities, and total cost. Daily users (compliance analysts, auditors) evaluate based on workflow efficiency, reporting quality, and alert management. Research that mixes them conflates strategic needs with operational needs.
How is compliance software research different from fintech UX research?
Fintech UX research focuses on end-user trust, payment flows, and financial product adoption. Compliance software research focuses on regulatory workflows, audit preparation, and evidence management. There is overlap when researching compliance features within fintech products (AML monitoring, KYC flows), but the user personas and research questions are fundamentally different.
What compliance frameworks should the researcher understand before conducting studies?
You do not need to be a compliance expert, but you should understand the basics of whichever frameworks your participants manage (SOX, HIPAA, SOC 2, GDPR, PCI DSS). Spend 2-3 hours reading the framework overview before your first session. This lets you ask informed follow-up questions and recognize when participants reference specific regulatory requirements.