How to use this survey tool requirements checklist
A team that must collect surveys or feedback forms on infrastructure it controls needs a defensible way to compare LimeSurvey, Formbricks and other self-hosted options, and this checklist turns each requirement into a verifiable test. Every item should be phrased so that a proof of concept can pass or fail it, such as whether a respondent record can be exported without the admin account, or whether a specific SSO provider can enforce login for administrators. Vague wishes like "secure" or "GDPR friendly" do not survive a comparison, so rewrite them as a test before scoring any platform. The checklist is grouped by functional, security, integration, operations and compliance needs. Functional items cover question types, multilingual delivery and export formats. Security items cover hosting, encryption, identity and access roles. Integration items cover webhooks, APIs and where data flows once it leaves the survey tool. Operations items cover upgrades, backups, supported versions and the support terms that apply after go-live. Compliance items cover retention settings, deletion and the documentation your data protection officer will ask for. Your own legal, privacy and data owners set the thresholds for each item, such as how long responses may be kept or what counts as an identifiable answer. Those decisions belong to them, not to the implementation team. Edition differences need particular care. Formbricks, for example, gates SSO, teams and access roles, audit logs and several other features behind an Enterprise license, so confirm each feature you need against the written license terms and the edition you plan to run, not against marketing summaries. DeployOpen plans, implements, hardens and supports self-hosted platforms, and it prepares systems and evidence for compliance assessments, but it does not issue audit reports, attestations or certifications. Independent auditors and certification bodies make those determinations, so treat any checklist result as readiness evidence for them, not as proof of compliance.
Functional must-haves: which question types, logic and response limits the tool needs
This table lists the functional requirements a survey or form tool must meet, why each one matters for your use case, and a test you can run before choosing LimeSurvey, Formbricks or another self-hosted option. Use the verification step as a scripted trial with your own question set, and treat any row you cannot confirm as an open question for the vendor.
| Requirement | Why it matters | Verification step |
|---|---|---|
| Question types | LimeSurvey supports more than 30 question types, but your instrument may need matrix, ranking or scale items that the tool handles differently. | Build your real questionnaire in a test instance and confirm every item type renders and stores correctly. |
| Multilingual surveys | LimeSurvey supports surveys in more than 80 languages, which matters for public or cross-border instruments with translation review. | Publish one survey in each required language and check text, right-to-left layout and stored translations. |
| Conditional logic | Branching decides which respondents see which questions, and errors here skew results and can expose questions to the wrong people. | Create a sample form with at least three branches and confirm skipped items are excluded from the export. |
| File upload | Upload fields bring storage, malware and retention obligations that a text-only form does not. | Submit a test file, confirm where it is stored on your server and confirm it is deleted when the response is deleted. |
| Quotas and response caps | Quotas control sample composition in research and panels, and Formbricks lists quota management as an Enterprise feature. | Set a quota of five responses on a test segment and confirm the tool closes it at the limit. |
| Website, link and email delivery | Formbricks supports website, app, link and email-embedded surveys, and each channel needs different consent and tracking handling. | Publish one survey through each channel you plan to use and confirm the entry point and tracking parameters work. |
| Response export formats | Analysts need exports that open in their statistics tools, and LimeSurvey offers plugins such as ExportR and ExportSTATAxml. | Export a test dataset to CSV and to any statistical format you need, then open it in the analysis software your team uses. |
| Response volume limits | LimeSurvey Cloud plans are counted per month or per year, and Formbricks Cloud plans are counted per month, so the unit changes cost and planning. | Confirm the counting unit for your planned volume in writing and calculate peak month, not average, before you choose a plan. |
| Self-hosted volume ceiling | Community editions on self-hosted installs are governed by your own capacity, so response volume becomes a sizing question rather than a plan limit. | Ask the vendor for a load test profile for your expected concurrent respondents and confirm your database and PHP or container sizing. |
Community or enterprise edition: which features change the fit
LimeSurvey Community Edition is licensed under GPL v2.0 with the option to use any later GPL version, and it is free to download and self-host. Survey data is stored on the server you choose, which makes it the most direct route to keeping responses inside your own infrastructure. The trade-off is that you own the full operating model: PHP and database versions, patching, backups, identity integration and upgrades.
- Runtime requirements: The current stable line requires PHP 8.1.29 or later with mbstring and PDO drivers, plus a supported database such as MySQL 8.0, PostgreSQL 14, MariaDB 10.3.38 or MSSQL 2019 or later.
- Version lifecycle: The 6.17.19 release reached end of support on August 31, 2026, so confirm which branch your team will run before you plan upgrades.
- Feature scope: The published feature set includes more than 30 question types, multilingual surveys in more than 80 languages and plugins such as ExportR and ExportSTATAxml.
- Operational cost: Your internal staff or an implementation partner carries patching, backups, monitoring and hardening, which recur for the life of the tool.
Confirm with LimeSurvey in writing which features, support terms and plugins apply to the Community Edition you plan to run, and whether any identity or audit features depend on a paid tier.
LimeSurvey Cloud is the hosted version of the product, sold as subscription tiers with limits on responses and admin users. It removes server operations from your team, but the survey data then sits with the provider in a chosen region. Each tier limits how many responses you can collect and how many administrators can work in the account, so volume and team size are the first checks.
- Published tiers: As read in October 2026, Basic lists 1,000 responses per month and 1 admin user, Expert lists 10,000 responses per year and 3 admins, and Business lists 50,000 responses per year and 5 to 10 admins. Corporate is quoted individually.
- Hosting regions: Germany, Finland, the UK, the USA, Canada and Australia are offered, with Germany or Finland recommended for EU customers.
- Lapse behavior: If a subscription expires, the account falls back to the Free package and keeps access to collected responses.
- Checkout currency: Pricing is listed in euros.
Confirm the current tier limits, data processing terms, sub-processors and whether SSO or audit logging is included in any tier before you rely on the cloud option for regulated data.
The Formbricks core application is licensed under AGPLv3, and the self-hosted Community Edition can be run with Docker without a subscription. It includes unlimited surveys, responses and users, full API access, all SDKs, advanced logic, multi-language surveys, file upload, webhooks and a Helm chart for cluster hosting. The main limit is that the Community Edition supports one workspace.
- Included features: Website, app, link and email-embedded surveys, plus advanced logic, multi-language UI and file upload, are in the Community Edition.
- Workspace limit: The Community Edition is limited to one workspace, so separate business units may need separate instances or a paid license.
- Fork obligations: Privately kept forks must be released under AGPLv3 unless covered by an Enterprise license.
- Integrations: Formbricks integrates with Slack, Notion, Zapier, n8n and other tools, and webhooks can send responses to your own stack.
- Version: Formbricks 6.0.2 was published on October 1, 2026.
Confirm the workspace limit, fork terms and API coverage in writing with Formbricks before you design multi-team or multi-brand rollouts.
The Enterprise license unlocks code in the enterprise module, which ships in the Docker images and is activated with an Enterprise License Key. The features that change most governance designs are OIDC and SAML SSO, teams and access roles, contact management and segments, quota management and audit logs. It also covers whitelabel email follow-ups and removing the Powered by Formbricks badge.
- Identity: OIDC and SAML SSO need the Enterprise license, so without it you rely on local accounts for administrator and respondent-management access.
- Access control: Teams and access roles require the license, which affects how you separate survey owners, analysts and administrators.
- Audit and quotas: Audit logs and quota management also need the license, and both matter for evidence collection and sampling control.
- Segments: Contact management and segments are paid features, which affects in-app targeting and the handling of personal contact data.
- Operational consequence: License keys, renewal terms and the upgrade path must be added to your change calendar, and an unlicensed build can block access to these features.
Confirm the current Enterprise feature list, license terms and renewal conditions in writing with Formbricks, and ask how the license interacts with Docker or Helm upgrades.
Hosting and data residency: where respondent data must sit
Hosting decisions set the ground rules for everything else on a survey checklist, from who can read responses to which law applies. Start by writing down where the database, uploads and backups must sit, then check each self-hosted option against that answer.
Database and file storage location
Respondent answers live in the database, and uploaded files live in the application's file storage. Both must sit inside the infrastructure your data rules cover, including any region, data center or air-gapped network. Ask the team to name the exact host, the storage volume and who holds administrator access to each. A self-hosted install moves this question into your own infrastructure, so it stops being a vendor question.
LimeSurvey database engine support
LimeSurvey runs on MySQL 8.0, PostgreSQL 14, MariaDB 10.3.38, or MSSQL 2019 or later. Choose the engine your database team already patches, backs up and monitors, rather than adding a new one for a single tool. Confirm the engine version against the current LimeSurvey release notes before you build, since minimum versions change between releases.
PHP runtime requirements
LimeSurvey requires PHP 8.1.29 or later with the mbstring and PDO drivers enabled. Your hosting team must confirm that the PHP build, extensions and security patch level match your server standard, because an outdated PHP runtime is a common reason a self-hosted survey server fails a security review. Ask who owns PHP patching and how quickly it is applied.
Container and cluster hosting for Formbricks
Formbricks can be self-hosted with Docker without a subscription, and it provides a Helm chart for cluster hosting. Decide which path your platform team supports, then confirm that the chosen image source, secrets handling and network policies fit your container standard. Enterprise code ships in the same Docker images, so review which features your deployment unlocks before go-live.
Backup location and retention copies
Backups copy every response, so they inherit the same residency and access rules as the live system. Confirm where backup copies are written, how long they are kept, whether they are encrypted, and whether they can be restored into a separate environment for testing. A survey that deletes responses from the live database but keeps them in an unmanaged backup has not met a deletion request.
Cloud edition data location
If you use a hosted edition instead, the data location belongs to the vendor. LimeSurvey Cloud lists hosting regions including Germany, Finland, the UK, the USA, Canada and Australia, and Formbricks Cloud's Hobby plan is hosted in Frankfurt. Confirm the region for your plan with the vendor in writing, check whether backups and support access sit in the same region, and treat these locations as vendor facts to verify, not as guarantees.
Privacy and retention: what the tool must let you control
The privacy requirements for a self-hosted survey tool are about control: whether the platform can carry out the retention, deletion, anonymity and consent decisions your organization has already made. The legal basis for collecting responses, the retention periods and the consent wording come from your counsel and data protection officer, not from the software. The checklist therefore asks a narrower question for each item: can the tool implement this decision, and who can change it later?
Start with the response mode. Confirm whether the tool can run anonymous responses in which no respondent identifier is stored, and separately whether it can run identified responses with a stored contact or token. Ask how IP addresses and other metadata are captured and whether that capture can be switched off per survey, since collecting them by default may conflict with a minimization decision. For each setting, test it on a sample survey and inspect what lands in the response table and in exports, because interface labels do not always match stored fields.
Next, check the lifecycle controls. You need configurable retention, a way to delete individual responses and whole surveys, and a deletion path that also covers backups and exports created by staff. Consent text should be stored with the response or with a versioned record of the wording shown, so you can show later which version a respondent saw. Responding to an access or erasure request depends on being able to export one person's data and remove it completely. Finally, confirm that your hosting and admin model keeps the vendor, if there is one, from reading answers, which is a question about who holds the database credentials and encryption keys, covered in more depth in the sibling EU data sovereignty and GDPR topics.
Integration requirements: sending responses to the systems that act on them
Every integration moves respondent data out of the survey platform and into another system that may store, forward or act on it. Each card below names a common route, what leaves the platform, who receives it, and whether the transfer changes your data protection position. Map each one to a data flow before approving it.
Webhooks to downstream systems
Webhooks push a payload to an endpoint you control each time a response is created or updated. The payload is the main risk: it can contain full answers, free text and identifiers. Check which events trigger a call, which fields are included, whether the receiving endpoint is inside your network, and whether delivery retries store copies of the payload outside your hosting boundary. Formbricks includes webhooks in its Community Edition, so the receiving side is where most of the review belongs.
Full API for surveys and responses
An API lets other systems read responses and create or update surveys programmatically. Access is granted by API keys or tokens, so the question is who holds them, what scope they carry, and whether they can export every respondent record. Ask whether the API can be restricted to read-only, whether keys can be rotated without downtime, and whether API calls are written to an audit trail. Formbricks lists full API access in its Community Edition; confirm the equivalent in LimeSurvey for your version.
Statistical export with ExportR and ExportSTATAxml
LimeSurvey plugins ExportR and ExportSTATAxml produce files for analysis in R and Stata. The export leaves the survey server as a file on a researcher's workstation, which moves responses outside the controlled hosting environment. Confirm which fields are exported, whether identifiers or token codes are included, where the files are stored, and who may download them. For research or HR use, anonymized exports may be required by your own policy, and the export settings should reflect that.
Connectors to collaboration and automation tools
Formbricks lists connectors to Slack, Notion, Zapier and n8n. Each connector sends response content to a third-party service, often a SaaS provider outside your hosting, and that provider then applies its own retention and access rules. Before enabling one, record which survey fields are forwarded, which workspace or account receives them, and who in the company can see the channel. A connector that posts free-text answers to a shared channel can expose sensitive content to far more people than the survey was designed for.
Single sign-on to the company directory
Single sign-on lets staff who build or review surveys authenticate with the company directory rather than local passwords. It moves identity data, such as names, email addresses and group memberships, between your directory and the survey platform, but not respondent answers. Check whether the platform supports OIDC or SAML, whether group membership maps to survey roles, and whether accounts are removed when staff leave. In Formbricks, OIDC and SAML SSO require the Enterprise license, so include that cost in the comparison.
Operations and support: what to check after go-live
This table lists the operational requirements a team should confirm before and after a self-hosted LimeSurvey or Formbricks deployment goes live, with a practical way to verify each one. Read it as a sign-off list: every row needs a written answer from the vendor, the implementation partner, or your own test results.
| Requirement | What to confirm | How to verify |
|---|---|---|
| Upgrade path and release cadence | Which versions are current, how often releases ship, and whether security patches are backported to older branches | Check the LimeSurvey community downloads page and Formbricks GitHub releases, then record the current version and the date of your last upgrade |
| Backup and restore tests | Database, uploaded files and configuration are backed up on a schedule you set, with a documented retention period | Run a restore drill into a test environment and confirm that surveys, responses and user accounts come back intact |
| Monitoring | Uptime, response latency, database health, disk use and failed email or webhook deliveries are visible to the operations team | Trigger a controlled test failure and confirm an alert reaches the on-call person within the window you agreed in writing |
| Staging environment | A non-production copy runs the same version and plugins as production, so upgrades and survey changes are tested first | Compare version numbers and plugin lists between staging and production before each change window |
| Documented runbooks | Steps exist for install, upgrade, rollback, certificate renewal, key rotation, restore and incident response | Ask an engineer who did not write the runbook to follow it in staging and note any gaps |
| Support hours and escalation | Support coverage, response targets, severity definitions and the escalation path are stated in writing | Review the contract or support policy and get any response times in writing; do not rely on verbal commitments |
| Vendor end-of-support dates | Published dates for each release line, and a plan for moving before a line stops receiving fixes | Check the vendor's published support dates, such as LimeSurvey's end-of-support date for 6.17.19, and add them to your change calendar |
| Plugin and integration maintenance | Each plugin, webhook and connector has an owner, a version, and a test that runs after upgrades | Re-run integration tests after each upgrade and confirm that data still reaches the connected tools |
How to run a proof of concept that tests these requirements
This sequence turns the requirements checklist into a tested decision: each candidate edition is installed in a non-production environment, put through the same scripted survey, checked against its written license and feature list, and scored against the must-haves. The scored result becomes the basis for a fixed-scope statement of work.
Define the must-have list with named owners
Turn the checklist into a numbered list of must-have requirements, each with one owner. Legal owns the lawful basis, consent text and retention rules, security owns hosting, encryption and access roles, and the business owner defines the survey types, question logic and reporting views the team needs. Each requirement should state how it will be tested. The step is done when every must-have has an owner, a test method and a sign-off from the owner, and the list is frozen before any installation begins.
Build a test instance in a non-production environment
Install the candidate edition in an environment that matches the intended production hosting, such as the same cloud account, region or internal network segment, but holds no real respondent data. Record the software version, database engine and container or runtime configuration, and confirm the platform's stated system requirements against your environment. Where a self-hosted option is compared with a vendor-hosted option, include the hosted account as a separate test target. The step is done when the instance is reachable through the intended identity path and the configuration is documented in a build record.
Run a scripted test survey across all must-haves
Write one test script that every candidate runs unchanged. It should cover conditional logic and branching, multi-language content and right-to-left handling if relevant, SSO login with role mapping, file upload, data export to the formats your analysts use, and a full deletion of a test respondent including backups where the team expects them to be purged. Testers record pass or fail with a screenshot or export file as evidence. The step is done when every script item has a recorded result and any unexpected behavior is logged as a defect with a reproduction path.
Check the written license and feature list for each edition
Compare the test results with the license text and the published feature list for the exact edition under evaluation. Some capabilities, such as SSO, team roles, audit logs or whitelabel branding, may sit in a paid or enterprise tier even when the core code is open source. Confirm what the license permits for internal use, modification and hosting for third parties, and record any obligation to publish changes. Ask the vendor in writing to confirm any feature that the public documentation does not clearly state. The step is done when each must-have is mapped to a license tier and a written source, and any gap that needs a paid license is marked for legal review.
Score each option pass or fail and record the gaps
Score each candidate against the frozen must-have list using pass, fail or conditional, where conditional means a pass only after a named configuration step or a paid license. Owners review the scores for their own requirements, and any fail on a legal or security must-have blocks that option until it is resolved or formally accepted by the owner. Write the gaps as specific, testable items so they can be priced and scheduled. The step is done when a signed scorecard exists, each fail or conditional has a stated owner and resolution path, and the shortlist is agreed.
Use the scorecard as the basis for the statement of work
Carry the scorecard into the fixed-scope statement of work. Each conditional item becomes a deliverable with acceptance criteria taken from the test script, so the implementation partner and the internal team agree on what done means before work starts. Gaps that depend on a paid license are listed as a dependency with the owner responsible for buying it. Confirm that the scope, deliverables and timeline are written and agreed before work begins, since DeployOpen works to fixed scopes agreed in writing. The step is done when the statement of work references the scorecard, the test script and the license decisions.
What buyers ask before choosing a self-hosted survey tool
What work does a self-hosted survey tool need in-house?
Your team needs to run the application, its database, backups, updates, access control and the network paths the survey server uses. Someone must own the server or container platform, the database, the mail sending path for invitations, and the decision on where respondent data is stored and for how long. Survey design, question logic and reporting usually stay with the research, HR or marketing owner, who should not need to manage infrastructure. Before you commit, list each of these tasks and name the person or team who will carry it, because gaps in ownership are the most common reason self-hosted survey projects stall after go-live.
Can we run a self-hosted survey tool without outside help?
Yes, if your team already runs web applications with a database and can keep them patched. LimeSurvey Community Edition is free to download and self-host, and Formbricks can be self-hosted with Docker without a subscription, so the software itself carries no license fee for these editions. The open questions are whether you have capacity for hosting, security hardening, backups and upgrades, and whether you need enterprise features such as SSO or audit logs that Formbricks reserves for its Enterprise license. An implementation partner is useful when the first deployment must meet a specific compliance or data residency requirement, or when internal staff cannot commit to ongoing maintenance.
What drives the effort of a self-hosted survey deployment up?
Four factors move the effort most: identity integration, integrations with other systems, data residency rules, and the volume of surveys and languages. Single sign-on through OIDC or SAML needs identity provider setup and testing, and in Formbricks it requires the Enterprise license. Each connection to a CRM, data warehouse or messaging tool needs mapping, error handling and a test plan. Data residency may require choosing a region, a private network and documented sub-processors. Many surveys in many languages add translation workflow, branding and testing. A small, single-language deployment with local accounts is far simpler, and the checklist should record which of these factors apply to you.
How long does a proof of concept for a survey tool take?
This page does not give a duration for a proof of concept, because it depends on scope, the hosting environment and how many integrations you test. Ask any implementation partner for a written estimate that lists the environment to be built, the functions to be tested, the integrations included and the people needed from your side. A useful proof of concept should cover one real survey flow, one identity test, one data export and one restore test. If a proposal does not name these items, ask for them before comparing timelines.
What does the work need from our internal owners?
Internal owners need to make decisions and provide access, not do the build. A security or infrastructure owner approves hosting, network paths, secrets handling and backup targets. An identity owner provides SSO configuration and group mapping. A privacy or legal owner confirms the data categories, retention periods and respondent notices. A business owner, such as the research lead, HR partner or product manager, signs off survey templates and reporting needs. Agree on who approves each decision and how quickly, because delayed approvals usually extend the schedule more than technical work does.
What should a quote for a survey tool deployment include?
A quote should follow from a written scope and list each deliverable separately: environment build, installation, configuration, integrations, identity setup, testing, documentation, training and handover. It should state what is one-time and what recurs, such as hosting, support and upgrades, and what is excluded. Ask for the assumptions behind the price, including the number of surveys, languages, integrations and responses expected, and the process for changes. DeployOpen does not publish a price list, and most engagements are fixed scope, so the written scope is what the quote is based on. For vendor-published subscriptions, compare the figures you can verify: LimeSurvey Cloud lists Basic at 1,000 responses per month, and Formbricks Cloud lists Pro at $74 per month with 2,000 responses, both as published on the vendors' pricing pages in October 2026.
How DeployOpen scopes and delivers survey tool selection and implementation
DeployOpen plans, implements, customizes, integrates, hardens, documents and supports self-hosted open-source platforms inside the client's own infrastructure. For survey tool requirements, we turn a checklist into a written scope that names the platform, hosting location, identity model and integrations before any build work starts.
How we scope
- Confirm which functional must-haves the checklist covers, such as question types, languages, logic and export formats, against LimeSurvey or Formbricks.
- Document hosting location, data residency and retention requirements for each survey population before selecting an edition.
- Agree in writing which identity, integration and evidence deliverables are in scope, since most engagements are fixed-scope.
How we build
- Deploy the chosen survey platform into your cloud account, data center or air-gapped network, with the database and edition you have confirmed.
- Configure SSO, access roles, retention settings and integrations, and test each requirement from the checklist against a documented result.
- Harden the deployment and record configuration decisions so the checklist can be re-run when you upgrade or change editions.
How we hand over
- Deliver the completed requirements checklist with a pass, fail or open status for every item, plus the configuration and network documentation behind it.
- Provide runbooks for backup, restore, upgrades and access reviews, written for your own operations staff.
- Hand over the evidence set your auditors or data protection officer asked for, prepared for their review. DeployOpen does not issue audit reports or certifications.
How we support
- Offer ongoing support, version upgrades and continuous security testing as a retainer after go-live, scoped in writing.
- Re-check the checklist when a platform release changes licensing, supported versions or enterprise-only features that your requirements depend on.
- Review integration changes and new survey populations, such as a new country or department, and update the scope before work begins.
