Security and Compliance Requirements for Market Research Software

Market research software can hold far more sensitive information than a standard project management tool. Respondent names, email addresses, demographic profiles, survey responses, device details, incentive records, client data, and study history may all be stored in one platform. That is why every Security and Compliance Requirement should be considered from the start, covering how data is collected, accessed, stored, shared, and protected throughout the research process.

That makes market research data security a product requirement, not just an IT task.

The financial risk is also significant. IBM’s 2026 Cost of a Data Breach Report puts the global average breach cost at $4.99 million, up 12% from the previous year. Verizon’s 2026 DBIR also shows why software architecture matters: exploitation of vulnerabilities accounted for 42% of initial access in the breaches it analyzed, while third parties were involved in 68% of breaches.

For research companies, the goal is therefore wider than preventing unauthorized access. The platform also needs to control what data is collected, who can use it, how long it stays in the system, how consent is recorded, how data moves between suppliers, and what happens when a participant asks for their information to be removed.

This guide covers the security and compliance requirements research teams should consider when building, buying, or replacing market research software.

Why Market Research Software Needs Different Security Controls

Market research systems often combine several types of data in one place:

• Respondent contact information
• Demographic and behavioral profiles
• Survey responses
• Panel membership and participation history
• Incentive and payment records
• Device and fraud-prevention data
• Client project information
• Supplier information
• Research reports and exports
• Consent and communication preferences

Some projects may also collect health information or other sensitive categories of personal data.

Under GDPR, special-category data includes information concerning health, racial or ethnic origin, political opinions, religious beliefs, biometric data used for identification, and several other protected categories. Processing these categories requires additional legal justification and safeguards.

The software therefore has to protect both respondent privacy and commercial research data.

A simple login page and encrypted database are not enough.

Security and Compliance Are Related, but They Are Not the Same

Security is about protecting systems and data from unauthorized access, loss, misuse, alteration, and disruption.

Compliance is about meeting the rules that apply to how that information is collected and managed.

A platform can have strong technical security and still create compliance problems.

For example, a database may be encrypted but still hold respondent information for longer than necessary. An admin account may use multi-factor authentication, but the system may have no way to record when a participant withdrew consent.

The opposite is also true. A privacy notice does not protect a database from stolen credentials.

Good market research compliance needs both.

Core Security Requirements for Market Research Software

1. Collect Only the Data You Actually Need

Security starts before the data reaches the database.

Every additional field increases the amount of information that has to be protected.

GDPR includes data minimization and storage limitation among its core principles. California privacy rules also require covered businesses to limit collection, use, and retention to purposes that are reasonably expected, compatible with disclosed purposes, or specifically agreed to by the consumer.

For research software, this means separating:

Required profile data
Information needed to qualify or segment respondents.

Optional profile data
Information that may help future studies but is not necessary for every participant.

Study-specific data
Sensitive information collected only when a particular research project requires it.

Avoid collecting fields simply because they might be useful later.

2. Build Consent and Privacy Controls Into the Product

Consent should not exist only in an email or PDF stored outside the research platform.

Where consent is the legal basis being used, the system should be able to record:

• What the participant agreed to
• When they agreed
• Which version of the privacy notice or consent text they saw
• The source of registration
• Communication preferences
• Changes to consent
• Withdrawal date
• Account deletion requests

GDPR defines consent as freely given, specific, informed, and unambiguous. It also requires organizations to be transparent about who is collecting data and why.

This becomes especially important in panel platforms where the same respondent may participate in studies for several years.

If your team runs an owned panel, our guide to panel management software features explains how consent, participant history, fraud controls, and panel management should work together.

3. Encrypt Data in Transit and at Rest

Personal information should be protected while stored and while moving between systems.

GDPR Article 32 specifically identifies pseudonymisation and encryption among the technical measures that may be appropriate based on risk.

At a practical software level, review:

• TLS for browser and API traffic
• Database encryption
• Encrypted backups
• Secure object storage
• Key-management practices
• Encryption for exported files where appropriate
• Secret and API-key storage

Encryption reduces exposure if data is intercepted or storage is accessed improperly. It does not replace access controls, retention policies, or monitoring. The UK Information Commissioner’s Office makes the same distinction: encryption can reduce risk but does not remove it completely.

4. Use Role-Based Access Instead of Shared Admin Accounts

Not everyone using a research platform needs access to every respondent or project.

A project manager may need to see quotas and completes but not payment information. A panel manager may need participant profiles but not client invoices. A supplier may need access only to the studies assigned to that supplier.

The system should support role-based access control such as:

Multi-factor authentication should be available for privileged and administrative accounts.

Verizon’s 2025 DBIR found compromised credentials were the initial access vector in 22% of the breaches it reviewed.

The practical lesson is simple: one stolen password should not provide unrestricted access to the entire research operation.

5. Keep Client and Project Data Properly Separated

Research agencies often manage several clients inside the same platform.

The software must make sure one client cannot see another client’s:

• Respondents
• Study data
• Quotations
• Survey links
• Suppliers
• Reports
• Attachments
• Invoices

For SaaS or white-label products, tenant separation should be considered at database, application, API, file-storage, and reporting levels.

Do not assume that hiding a menu item is the same as restricting access.

Authorization should be enforced on the server whenever data is requested.

6. Secure Every API and Integration

Modern research software rarely works alone.

It may connect with:

• Survey engines
• Panel and sample suppliers
• Buyer APIs
• Reward platforms
• Payment providers
• CRM systems
• Accounting tools
• Fraud-detection services
• Reporting platforms

Every integration creates another place where data enters or leaves the system.

This deserves close attention because Verizon’s 2026 DBIR reports third-party involvement in 68% of analyzed breaches.

For every integration, check:

• Authentication method
• API permissions
• Key rotation
• Webhook verification
• Rate limits
• Logging
• Data fields being transferred
• Where the receiving company stores the data
• Data deletion responsibilities
• Contractual security requirements

Our guide to market research software integrations explains how panels, APIs, rewards, survey tools, CRM systems, and reporting tools commonly connect inside a research platform.

7. Maintain Audit Logs

When something goes wrong, the first question is often:

Who accessed or changed this data?

The system should keep an audit trail for important activity, including:

• Logins
• Failed login attempts
• Permission changes
• Respondent exports
• Profile edits
• Consent changes
• Project changes
• API activity
• Reward adjustments
• Account deletion
• Administrative actions

Audit logs should record the user, action, timestamp, and relevant object or record.

Sensitive logs should also be protected from unauthorized changes.

This helps with incident investigation, client audits, internal reviews, and compliance reporting.

8. Define Retention and Deletion Rules

Many platforms are good at collecting data and poor at removing it.

That creates unnecessary risk.

A research system should allow different retention periods for different data types.

For example:

GDPR requires personal data to be kept in identifiable form no longer than necessary for its purpose.

California consumers also have rights relating to access and deletion, subject to statutory exceptions.

Your software should therefore support deletion workflows instead of requiring an engineer to manually remove records from multiple databases.

9. Protect Data Exports

CSV and Excel exports are often one of the easiest ways for controlled platform data to become uncontrolled data.

Once a respondent list is downloaded, software-level permissions no longer protect it.

Useful controls include:

• Restricting export permissions
• Recording who exported data
• Exporting only required fields
• Masking selected identifiers
• Time-limited download links
• Encrypting sensitive files
• Automatic expiry of generated exports
• Approval workflows for high-risk datasets

For sensitive research, consider whether users actually need raw respondent identifiers at all.

Pseudonymized IDs may be enough for analysis or reconciliation.

10. Build Backups and Recovery Into the Platform

Security also means keeping legitimate users able to access their data.

ISO/IEC 27001 describes information security in terms of protecting confidentiality, integrity, and availability.

Your platform should have documented backup and recovery processes.

Important questions include:

• How frequently are backups taken?
• Are backups encrypted?
• Are copies stored separately from production?
• How long are backups retained?
• How quickly can service be restored?
• Is restoration actually tested?
• Can deleted data remain inside backups, and for how long?

A backup that has never been restored in testing is an assumption, not a recovery plan.

11. Have an Incident Response Process

No security program can promise that a breach will never happen.

The platform and the organization need a clear response process.

At minimum, define:

Detect → Contain → Investigate → Assess → Notify → Recover → Review

GDPR Article 33 generally requires controllers to notify the relevant supervisory authority of a qualifying personal-data breach within 72 hours after becoming aware of it, unless the breach is unlikely to create a risk to individuals’ rights and freedoms.

The software should make it possible to determine:

• Which users were affected
• Which records were accessed
• When the event occurred
• Which systems were involved
• Which integrations received the data
• What actions were taken afterward

This is another reason good logging matters.

Which Compliance Frameworks Matter?

Not every framework applies to every research company.

The right requirements depend on geography, industry, client contracts, and the type of information your platform processes.

ISO 20252 establishes service requirements specifically for market, opinion, social research and insights organizations.

The ICC/ESOMAR International Code is a global professional standard for market, opinion and social research and data analytics.

ISO/IEC 27001, by comparison, focuses on an organization’s information security management system rather than research methodology.

SOC 2 is also often misunderstood. It is an attestation examination based on AICPA Trust Services Criteria, not a privacy law. Those criteria cover security and may also cover availability, processing integrity, confidentiality, and privacy.

When Does HIPAA Apply to Market Research Software?

Healthcare research deserves separate attention.

Not every healthcare survey automatically falls under HIPAA.

HIPAA applies when the parties and data fall within its scope, such as when a covered entity or business associate creates, receives, maintains, or transmits electronic protected health information.

Where HIPAA applies, the Security Rule requires reasonable and appropriate administrative, physical, and technical safeguards to protect ePHI.

A healthcare research platform may therefore require additional controls around:

• Access permissions
• Authentication
• Audit activity
• Secure data transfer
• Storage
• Vendor agreements
• Incident management
• Separation of PHI from general research data

Do not market software as “HIPAA compliant” based only on technical features. Compliance also depends on how the organization operates the software and whether the required contracts and processes are in place.

Privacy by Design Should Start Before Development

Privacy should not be added after the application is already built.

GDPR Article 25 requires data protection by design and by default, while current ICO guidance says privacy and data-protection practices should be considered throughout the design of systems, services, products, and processes.

For custom market research software development, this means answering privacy questions during requirements planning:

What information is really required?

Who needs access to each field?

Which data should be pseudonymized?

What leaves the platform through an API?

When should records expire?

How will participants exercise their rights?

Deciding these questions before development is much easier than rebuilding the data model later.

Security Requirements for Panel Management Software

Panel systems deserve extra attention because respondent records may remain active for years rather than for one study.

Good panel management software development should support:

• Consent records
• Communication preferences
• Role-based access
• Profile history
• Verification
• Duplicate detection
• Data-quality flags
• Controlled exports
• Panelist deletion or deactivation
• Audit logs
• Secure reward integrations

Security also matters during platform replacement.

A panel management software migration may involve moving profile data, consent records, reward balances, communication preferences, quality flags, and survey histories between systems.

That transfer should be treated as a controlled data-migration project, not simply a database copy.

Security Requirements for Research Project Management Platforms

A market research project management software platform creates a different security problem.

It may contain commercial data such as:

• Client briefs
• Pricing
• Supplier bids
• Project margins
• Respondent IDs
• Survey links
• Invoices
• Quality-rejection data
• Reports

Client and supplier permissions should therefore be separated carefully.

A supplier should not gain access to client financial information simply because both use the same project.

Likewise, a client portal should expose only approved project information.

A Practical Security Checklist for Market Research Software

Before launching or buying a platform, verify the following:

Data

• Data inventory is documented
• Sensitive fields are classified
• Unnecessary data collection is removed
• Retention periods are defined
• Deletion and anonymization workflows exist

Identity and Access

• Role-based permissions are available
• MFA is available for privileged users
• Client and supplier access is separated
• Dormant accounts can be disabled
• Password and session policies are documented

Infrastructure

• Data is encrypted in transit
• Sensitive stored data is encrypted where appropriate
• Backups are protected
• Restore procedures are tested
• Vulnerabilities and dependencies are patched

APIs and Vendors

• API credentials are stored securely
• Permissions use least privilege
• Webhooks are authenticated
• Third-party data flows are documented
• Vendor security responsibilities are defined

Privacy

• Consent or other applicable lawful basis is recorded
• Privacy notices are versioned
• Access/deletion workflows are supported
• Opt-outs are respected across connected systems
• Data exports are controlled

Monitoring

• Important user actions are logged
• Export activity is recorded
• Failed access attempts can be reviewed
• Security alerts reach the correct team
• An incident-response process exists

Questions to Ask a Market Research Software Vendor

A polished product demo does not tell you how securely the platform handles data.

Ask the vendor to show you:

• How do you separate data between clients?
• Can we create custom user roles and permissions?
• Is MFA supported?
• Where is our data hosted?
• How are backups protected and tested?
• How are API keys and secrets stored?
• Can we see an audit log of respondent exports?
• How do you handle participant deletion requests?
• Can consent history be exported?
• What happens to our data when the contract ends?
• Which subprocessors can access our data?
• How quickly are security vulnerabilities patched?
• What security or compliance reports can you provide?
• How are incidents communicated to customers?
• Can you demonstrate the controls instead of only describing them?

The last question is important.

Security claims should be testable.

Where OnGraph Fits

OnGraph develops market research platforms around the actual workflows research companies need to protect.

Its current research solutions include panel management, project management, survey workflows, integrations, fraud controls, rewards, dashboards, and custom research systems.

For companies building a new platform, security requirements can be included in the architecture from the beginning. Existing products can also be reviewed for gaps around authentication, permissions, APIs, data storage, consent, exports, and audit activity.

The right implementation will depend on the clients you serve, the countries where respondents are located, and the types of research data your software processes.

The Bottom Line

Security and compliance should be part of the market research software design, not a checklist completed after development.

Start with the data.

Understand what you collect, why you need it, who should see it, where it moves, and when it should be deleted.

Then build the technical controls around those answers.

For most research platforms, that means strong access control, encryption, secure integrations, audit logs, controlled exports, retention rules, backups, and an incident-response process.

Compliance frameworks then add the specific requirements your business needs to meet.