Why self-hosted survey tools for academic research need a different build
A research office or principal investigator who collects survey responses from students or staff is no longer running a general feedback form. The answer to the page question is that LimeSurvey on university infrastructure, configured for ethics and FERPA-style controls, is the usual fit for this work, because it can be hosted inside the institution's network, its data stays under the institution's direct control, and it exports to the statistical packages researchers already use. The platform choice matters less than the configuration, and the platforms section covers the options and their licences in more detail. The rules that govern respondent data differ from a standard build in four ways. First, the ethics approval defines what may be collected, how consent is recorded, and how long identifiable data may be kept, so the survey must match the approved protocol before launch. Second, if the respondents are students, the responses may become education records under the US Family Educational Rights and Privacy Act (FERPA) regulations in 34 CFR Part 99, which means access to identifiable responses must be limited to school officials with a legitimate educational interest and every disclosure must be logged. Third, anonymity is a configuration decision: whether responses are stored with or without tokens, whether IP addresses and timestamps are retained, and whether small cohorts can be re-identified in an export. Fourth, the export path to R, SPSS or Stata is a disclosure point in its own right, so the research office should confirm which fields leave the platform and who can run the exports. Before the build starts, ask the research office and the institutional data protection or records team to agree three things in writing: which identifiable fields the survey may hold, who holds the administrator and export roles, and how the campus single sign-on is mapped to those roles. Confirm the retention period against the protocol, and test the export of a sample dataset with the statistical software the team will use.
Which rules shape a university survey build and what each means for the build
This table maps the legal and accessibility rules most likely to apply to a university survey, and what each one means for hosting, access roles, retention and deletion. Read each row as a design input to confirm with your ethics board and legal counsel before the build is scoped.
| Rule | What it asks for | What it means for the build |
|---|---|---|
| FERPA (34 CFR Part 99) | Applies to institutions receiving federal education funds. Access to student education records must be limited to school officials with legitimate educational interests, and each disclosure must be logged (34 CFR 99.31, 99.32). | Restrict survey roles to named staff with a need to see identifiable records, log exports and disclosures, and confirm whether survey data linked to enrollment counts as education records. |
| Outside contractors as school officials | A vendor or implementation partner may handle records only under direct institutional control and subject to redisclosure limits (34 CFR 99.31(a)(1)(i)(B)). | Put hosting, support access and data handling terms in writing before a partner touches the instance, and limit partner admin rights to the scoped engagement. |
| GLBA Safeguards Rule (16 CFR Part 314) | Title IV institutions agreed to comply. Requires a written information security program and multi-factor authentication for anyone accessing any information system (16 CFR 314.4). | Enforce MFA on all admin and staff logins, keep the survey server inside the written security program, and confirm whether student financial aid data is ever linked to survey responses. |
| COPPA (16 CFR Part 312) | Applies where surveys collect personal information from children under 13. Requires a written security program, annual risk assessments and a written retention policy with a deletion timeframe (312.8, 312.10). | Use a campus lab or pediatric research setup only if minors are surveyed. Set automated deletion dates per study, and avoid collecting identifiers that are not needed. |
| GDPR (Regulation (EU) 2016/679) | Applies to processing personal data of people in the EU, including EU participants in studies run from non-EU institutions in some cases. Requires lawful basis, data minimization, retention limits and respondent rights. | Choose hosting in an EU region or on EU university infrastructure, build deletion and access request workflows, and document where each survey instance and backup is stored. |
| ADA Title II web rule (28 CFR Part 35 Subpart H) | Public universities and colleges are state or local government entities. Web content and mobile apps must meet WCAG 2.1 Level AA. The interim final rule published April 20, 2026 set compliance dates of April 26, 2027 for entities with 50,000 or more people and April 26, 2028 for smaller entities and special districts. | Test survey pages, consent screens and export instructions against WCAG 2.1 AA, and confirm which compliance date applies to your institution with counsel. |
| Ethics board and institutional review | Human subjects protocols set consent language, anonymity claims, storage location and retention for each study. | Map each protocol setting (anonymous link, identified panel, retention period) to a specific survey configuration, and keep the approval reference with the project record. |
How survey data, identities and exports move through the university
Every survey on a self-hosted tool creates several distinct data sets, and each one needs its own owner and rules. Respondent records and consent records hold who was invited and what they agreed to. Linked identifiers, such as student numbers or campus usernames carried in hidden fields or invitation tokens, tie a response to a person. Responses hold the answers, audit logs record who changed the survey and who viewed the data, and exported datasets are copies that leave the server. Before go-live, the research office should map each of these to a location on university infrastructure, a named custodian and a retention period. Where the records include student information, the FERPA framework in 34 CFR Part 99 applies to any institution receiving federal education funds, and the ethics board protocol should state which identifiers are collected and why.
Campus single sign-on governs who can reach the LimeSurvey administration interface, but it does not decide who can see responses. Confirm with the identity team whether SSO is enforced for the admin URL, which roles are mapped from institutional groups, and whether survey owners can grant access to external co-investigators without a university account. Anonymity settings then determine whether a response can be linked back to an identity at all. In LimeSurvey, anonymized responses drop the token that connects a record to an invitation, while identified surveys retain it. Researchers should test this with a dummy survey, check the stored response table directly, and record the result in the data management plan. An anonymous setting that still stores IP addresses or timestamps may remain identifying in a small cohort, so the protocol should list every metadata field the platform keeps.
Exports are where most control is lost. A CSV, an SPSS file or a Stata file produced through the ExportR or ExportSTATAxml plugins, or a plain export, lands on a researcher's laptop or in a cloud drive outside the controlled environment. Each export needs its own storage location, an access list, an encryption standard set by the university, a deletion date and a log entry. Ask the research data office whether analysis workstations are managed devices and whether exports are permitted to sync to consumer cloud storage. For studies that involve children under 13, the COPPA Rule adds a written retention policy with a deletion timeframe for any operator collecting that information. Confirm these obligations with counsel before the first export is generated.
Which open-source survey platforms fit research use and why
For most academic studies, the choice starts with the survey platform's licence, hosting model and export path into statistical software. The cards below cover the main option, the hosting choices that decide where respondent data sits, and the points to confirm before a study goes to an ethics board.
LimeSurvey as the main fit
LimeSurvey is the platform most research offices start with, because it is licensed under GPL v2.0 (or any later GPL version), can be self-hosted on university servers, and supports more than 30 question types. Multilingual instruments can run in more than 80 languages, which matters for cross-national studies with translated consent text. Before committing, check that your institution's database standard matches the supported stack: PHP 8.1.29 or later with MySQL 8.0, PostgreSQL 14, MariaDB 10.3.38 or MSSQL 2019 or later.
Statistical export through ExportR and ExportSTATAxml
LimeSurvey offers the ExportR and ExportSTATAxml plugins for moving responses into analysis tools. Test each export on a pilot dataset before fieldwork: confirm how multiple-choice items, matrix questions and missing-value codes arrive in R or Stata, and whether variable labels survive. SPSS export paths were not confirmed for this page, so ask the vendor and test in your own environment before writing an analysis plan that depends on SPSS.
LimeSurvey Cloud and its regions
LimeSurvey Cloud is an option when the university does not want to run the server itself. Hosting regions include Germany, Finland, the UK, the USA, Canada and Australia, and Germany or Finland are the recommended choices for EU customers. Confirm the contracting entity, the sub-processors and the region in the signed order against your data protection office's requirements, since the region alone does not settle where backups and support access sit.
Subscription fallback and data access
When a LimeSurvey Cloud subscription expires, the account moves to the Free package and keeps access to collected responses. This protects data already gathered, but it does not guarantee the same response limits or admin seats for an ongoing longitudinal study. Ask the vendor what happens to project configuration, invitations and user roles at downgrade, and record the answer in your data management plan.
Where university policy sets the hosting
Whether a LimeSurvey instance on campus or a cloud region is acceptable depends on the university's data classification, its records retention schedule and its information security policy, not on the software alone. Confirm with the research data office where identifiable responses may be stored, who holds administrator rights, and whether the IT department must run the server. This check is what makes the hosting choice defensible at ethics review.
Formbricks for in-product feedback
Formbricks suits in-product feedback better than structured research instruments. It is designed for short app and website surveys triggered by user behavior, which fits usability testing or service feedback embedded in a university portal. For a multi-page validated questionnaire with branching, quotas and detailed export needs, LimeSurvey is usually the stronger starting point. The study design, sample and question logic should decide the platform, not the tool familiarity of the team.
Hosting options for research survey data: university servers, cloud region or vendor cloud
Hosting LimeSurvey on infrastructure the university already runs is the option most ethics boards and data protection officers recognize without further explanation. The survey server, database and file uploads stay inside institutional networks, under the same identity, logging and change processes that cover other research systems. Administrative control usually sits with the central IT or research computing team, and the research group receives project-level survey administration rights.
- Administrator access: Server and database administrators are typically university staff. Confirm whether the research team holds only survey administrator roles, and who can read the database directly.
- Backup responsibility: Backups are usually run by the central service team under its retention schedule. Ask how often backups run, where they are stored, and how a single project's responses can be restored or deleted.
- Ethics board view: Boards generally accept on-campus storage when the data management plan names the server, the custodian and the access controls. Name the physical or logical location in the protocol.
- Upkeep: Patching of the PHP, database and LimeSurvey versions follows the university's change calendar, which may lag the upstream release cycle. Confirm which LimeSurvey release line the service supports.
Before approval, confirm with the IT security office which network zone hosts the instance, how multi-factor authentication and campus SSO are enforced, and whether the service appears in the university's record of approved research systems.
Some universities allow research teams to run LimeSurvey in a cloud account that the institution has contracted and approved. The team gains more control over scaling and maintenance, while the institution keeps contractual, security and data location obligations. The data location is set by the account's region, so the region choice must match the protocol's stated data location.
- Administrator access: Cloud account owners and administrators are usually named by the university. Confirm who holds root or owner rights, who can create database snapshots, and whether vendor staff have any access.
- Backup responsibility: The research or platform team often owns backups inside the account, which makes restore testing and deletion of individual project data a team task. Write the backup schedule and deletion steps into the data management plan.
- Ethics board view: Boards will ask for the region name, the contract or approval that covers the account, and whether any backups or logs leave that region.
- Logs and monitoring: Access logs and audit trails may sit in a separate service. Confirm where they are stored and how long they are kept.
Confirm with the IT security office that the account is covered by the university's cloud approval, that the region is on the approved list, and that encryption keys are managed under institutional policy.
LimeSurvey Cloud is operated by the vendor, which means the vendor holds the platform administration role and the research group works through a hosted account. According to the LimeSurvey pricing page, hosting regions include Germany, Finland, the UK, the USA, Canada and Australia, and Germany or Finland are recommended for EU customers. Choosing a supplied EU region helps with location questions, but it does not remove the need for a contract review and a data processing agreement.
- Administrator access: The vendor operates the platform, so administrator access is shared between the vendor and the account holder. Ask the vendor who can access the database, under what conditions, and how that access is logged.
- Backup responsibility: Backups are run by the vendor. Ask for the backup schedule, the storage location of backups, and the process for deleting a project's responses on request.
- Ethics board view: Boards will want the chosen region named in the protocol, the vendor's contractual terms, and confirmation that no data is copied outside the region. Expect questions about subprocessors.
- Plan limits and fallback: The pricing page lists response limits by plan. When a subscription expires, the account falls back to the Free package and keeps access to collected responses, so plan the funding period and retention accordingly.
Before use, confirm with the IT security office and the data protection officer whether the university allows vendor-hosted research data, what contract terms apply, and whether the vendor's region choice satisfies the institution's data location rule.
How a university survey rollout moves from ethics approval to archive
This sequence takes a university survey from the ethics board's approval to a configured, tested and monitored platform, then to a documented retention, deletion and archive plan. Each phase closes with a record that the research office, data protection officer and IT team can check.
Confirm ethics approval scope and data protection rules
The principal investigator and research office compare the approved protocol with the planned questions, respondent groups, data flows and any student or staff identifiers. The data protection officer confirms which federal or national rules apply, such as FERPA for student education records or the GDPR for EU respondents. The output is a signed requirements record that lists permitted data, permitted recipients and conditions the ethics board attached to the study. The step is done when every question and data field traces back to an approved purpose.
Define roles and anonymity settings
The team maps who may build surveys, view identifiable responses, export data and administer the platform, and assigns each role to a named person. Anonymity settings are chosen next, including whether responses are stored without identifiers, whether tokens link to a participant list, and whether IP addresses or metadata are recorded. The output is an access matrix signed by the research lead and the IT owner. The step is done when a reviewer can see who can reach identifiable data and why.
Set up hosting and campus single sign-on
The platform is deployed on university infrastructure or a provider region the institution has approved, with database and file storage in the same location. Campus single sign-on is connected for staff accounts, and local administrator accounts are restricted and documented. The FERPA rule on access controls expects technological measures that limit each school official to the records needed for their role, so this step should show that the access matrix is enforced in the system and not only on paper. The output is a hosting and identity configuration record. The step is done when test accounts with different roles see only the permitted surveys.
Configure surveys and consent text
Survey logic, question types, language versions and response options are built from the approved instrument. The consent statement is written or reviewed by the ethics board and placed before the first question, with a clear contact point for withdrawal. Export plugins for R, SPSS or Stata are enabled only where the analysis plan requires them. The output is a configuration record listing each survey, its settings, consent version and export options. The step is done when the record matches the approved protocol line by line.
Pilot with a test group and check exports
A small internal test group completes the survey on the production configuration, using test accounts that are later removed. The team checks skip logic, anonymity behavior, consent capture and whether exports open correctly in the statistical package the analysts will use. Any defect is logged with a fix and a retest. The output is a pilot test log that records each test, the result, and who approved the release. The step is done when the research lead and data protection officer both sign the log.
Go live with monitoring and an access log
The survey opens to participants and the platform's access and disclosure records are switched on before the first invitation is sent. The FERPA recordkeeping rule requires a record of each request for and disclosure of identifiable information, so logging should be confirmed before launch rather than assumed. Administrators watch uptime, failed logins and unusual export activity during fieldwork. The output is a launch checklist and a monitoring log. The step is done when the first responses are confirmed to land in the correct survey with the intended anonymity settings.
Close with retention, deletion and archive
When fieldwork ends, the team applies the retention schedule agreed with the ethics board and the records office. Identifiers are removed or separated from responses as the protocol requires, and exports are deleted from working folders once analysis is archived. Legal holds, funder requirements and data sharing terms are checked before any deletion. The output is a retention schedule, a deletion record and an archive package with the consent versions and configuration record. The step is done when the records office confirms the archive is complete and the platform copy is removed on schedule.
How anonymity settings and campus SSO change what a researcher can see
Does anonymous mode stop researchers from linking responses to participants?
Yes, when it is configured correctly, anonymous mode is meant to stop responses from being tied to a named person, but the setting alone does not prove that. Anonymity depends on what the survey collects: an email field, a student ID in a hidden field, a unique link or timestamps and metadata can all re-link a response. Confirm in your LimeSurvey configuration whether the survey stores IP addresses, referrer data or response timestamps, and whether any question asks for information that identifies a student. Your ethics board will usually want the anonymity claim in the approved protocol to match what the platform actually stores, so document both.
When should a study use participant tokens instead of an open link?
Use participant tokens when you need to know who has responded, send reminders or control who can enter the survey, and use open links when responses must not be tied to anyone. Tokens are a linkage tool: each invitation carries a unique code that the platform can match to a participant record. If your protocol promises anonymity, tokens need a separation plan, such as a participant list held by a different office than the response data and a deletion step once reminders end. Confirm with your platform configuration whether token records and response records can be stored or exported separately, and who can see each.
How does campus SSO apply to administrator access versus respondent access?
Campus single sign-on usually governs who can log in to manage surveys, while respondents should normally take surveys without an institutional login. These are separate decisions. Researchers and staff authenticate through the university identity provider, which lets you enforce multi-factor authentication, remove access when staff leave and keep an audit trail tied to institutional accounts. Requiring SSO for respondents, by contrast, identifies participants and undoes many anonymity designs. Confirm whether your LimeSurvey setup supports external authentication for administrators, and whether respondent access can stay open or token-based while admin access uses campus identity.
How do you restrict who can export raw survey data?
Restrict export rights by role, not by trust in individual researchers. Most risk comes from a single account that can download every response with identifiers attached, so define which roles can view responses, which can export, and which can export only aggregated or de-identified data. Keep raw exports with identifiers for named members of the research team who have approved access. Statistical exports to R, SPSS or Stata are a common leak path because files get copied to laptops. Confirm which export formats your platform configuration allows per role, whether plugins such as ExportR or ExportSTATAxml are enabled for everyone or only for specific administrators, and whether exports are logged.
How do you handle small cohorts that could be re-identified?
Small groups are the main re-identification risk in academic surveys, even when names are removed. A question about a rare program, a small department or a narrow age band can identify a respondent when combined with other answers. Set a minimum cell size before publishing any breakdown, merge or suppress categories that fall below it, and avoid reporting cross-tabulations that isolate one person. Decide this during protocol design, not after collection. Confirm with your data protection office how small-cell thresholds are set for your discipline and funder, and check whether the platform lets you hide or restrict results by subgroup.
Who should be responsible for configuring anonymity and access settings?
The research lead should own the design decisions, while the institution's IT or platform team should own the configuration and evidence. Anonymity, token use and export rights are protocol decisions that the ethics board reviews, so the principal investigator must sign off on them. The platform team then applies the settings, records them and keeps the configuration under change control. A partner can implement and document this for a fixed scope, but the institution still decides who receives access and approves each role. Ask any implementation partner to show the written permission matrix before go-live.
Which access controls should be documented for an ethics review?
Document the controls in the same terms your ethics board and data protection office use: who can see identifiable data, how anonymity is achieved, how long records are kept and how access is removed. Include the identity source for admin logins, the role matrix for viewing and exporting, the token handling process and the deletion point for identifiers. Keep the configuration export and change log alongside the protocol. Confirm with your institution's research ethics office which format it expects, since requirements differ by country and board.
What does it cost to set up campus SSO and role-based export controls?
Costs are mostly staff time: the identity team connects the platform to campus SSO, the platform team configures roles and logging, and the research office reviews the permission matrix. LimeSurvey Community Edition is free to download and self-host, so software licensing is not the main line item, but infrastructure, hosting, support and any implementation work are. One-time costs include integration, testing and documentation. Recurring costs include identity maintenance, upgrades and access reviews. Ask any quote to separate integration, configuration, documentation and ongoing support, and to state which parts depend on your identity provider.
Evidence ethics boards and auditors ask for and which component produces it
This table maps the records ethics boards, data protection officers and institutional auditors typically request to the component that generates them. Read each row as a question to answer before go-live, and check that the named owner can produce the evidence on demand. DeployOpen prepares these records and controls for review, but it does not issue audit reports, attestations or certifications, which remain the role of independent auditors and the relevant institutional offices.
| Evidence | What it shows | Produced by |
|---|---|---|
| Access logs and role records | Who opened survey data, when, and under which project role, including admin changes | Survey platform audit logs plus the campus identity provider |
| Disclosure records (34 CFR 99.32 style) | Each external disclosure of identifiable data, the recipient and the legitimate interest, kept as long as the data is kept | Documented export procedure, data sharing agreement register and export logs |
| Retention schedule and deletion log | Retention periods per project and proof that responses were deleted on schedule, including any child data under 16 CFR 312.10 style rules | Retention policy document plus scheduled deletion jobs and their run records |
| Written security program and annual risk assessment | Named coordinator, documented safeguards and a dated annual review of risks to respondent data | Institutional information security office, reviewed against the hosting design |
| MFA evidence from campus SSO | Multi-factor authentication enforced for staff and researchers who can reach respondent data | Campus SSO and identity provider policy reports, confirmed for the survey application |
| Data location documentation | Where responses are stored and backed up, and which campus systems or subprocessors touch them | Infrastructure diagram, hosting contract and the platform's configured storage and backup locations |
What stays with the research office after go-live
After go-live, the research office owns the LimeSurvey instance in practice, even if a partner built it. Name one accountable instance owner and a deputy, and write down which team runs the web server, PHP runtime, database and backups. Confirm that the database engine version on the server is still supported under the LimeSurvey system requirements before every upgrade window. Release updates are not optional housekeeping: the older 6.17.19 release reached end of support on August 31, 2026, so any instance still on that line has no supported security fixes and should be moved to a supported release, with the current stable line being 7.6.0 at the time of writing. Check the LimeSurvey community downloads page before each planned window, and test the upgrade on a copy of the database first.
Participant data requests need a named owner and a written procedure. When a participant asks to see, correct or delete responses tied to a consent record, the research office must trace the response across the survey, any exported files on shared drives, and any statistical datasets built from it. Decide in advance who can run those searches, how the request is logged, and how the ethics board or data protection officer is involved. Set an internal target that is well inside the statutory and ethics-approval timeframes your jurisdiction applies, and confirm that target against your own policy rather than assuming one. Deletion also needs to reach backups under your retention schedule, so document how and when backups roll off.
Access review should happen at the start of each academic term and whenever a researcher leaves a project. Pull the list of LimeSurvey administrators and survey owners, compare it against the current project roster from the institution's identity system, and remove accounts that no longer need them. Review which accounts can export raw responses, since export rights carry most of the disclosure risk. Keep the review record with the project's ethics file so an auditor or ethics reviewer can see who had access and when it ended. Ask your implementation partner to hand over a documented access matrix at go-live so this review has a baseline to work from.
What do research offices ask before building a self-hosted survey tool?
How much effort does a self-hosted survey build take, and what drives it?
The effort depends mostly on how many studies, faculties and survey types the platform must serve, how much integration sits around it, and how much evidence the ethics and IT offices will ask for. A single department running a few anonymous questionnaires needs a small, well-defined installation. A central service for many research groups needs multi-tenant roles, backup and restore testing, campus SSO, export pipelines to R, SPSS or Stata, and documented retention rules, which adds work at each stage. LimeSurvey is licensed under GPL v2.0 and can be downloaded and self-hosted free of license fees, so most of the cost is one-time setup, hosting, and recurring operations. Ask any partner for a fixed-scope quote that lists each of these pieces separately.
Can our research staff set up and run LimeSurvey themselves?
A capable IT team can install LimeSurvey, but the harder work is operational and governance-related: patching, backups, access control, log retention and documenting how each study's data is handled. LimeSurvey Community Edition 7.6.0 is the latest stable release, and the older 6.17.19 release reached end of support on August 31, 2026, so someone must own version upgrades on a fixed schedule. Research offices should confirm whether they have staff with time for this work after go-live, not only during installation. Staff who run it internally should still document the configuration so that a change in personnel does not leave the platform unmaintained.
What does a self-hosted survey project need from the IT and ethics offices?
IT must provide hosting, PHP and database versions that LimeSurvey supports, identity integration, network controls, backups and monitoring. LimeSurvey requires PHP 8.1.29 or later with mbstring and PDO drivers, and a supported database such as MySQL 8.0, PostgreSQL 14, MariaDB 10.3.38 or MSSQL 2019 or later. The ethics board and data protection office need the data flow, consent text, anonymity settings, retention period and deletion method for each study. Where the university is a FERPA-covered institution and survey responses include student education records, the registrar or privacy office must confirm the school official and access control position. Confirm these requirements in writing before the build starts.
How long does a rollout take, and what changes the timeline?
The timeline depends on the number of studies to migrate, the depth of campus SSO integration, the number of approval cycles through ethics and IT, and whether a pilot runs before wider access. Procurement of hosting and any database or storage changes can add time that the research team does not control. A rollout that starts with one faculty and a small set of approved survey templates is usually easier to approve than one that opens to the whole institution at once. Ask any implementation partner for a written schedule with dependencies, approval gates and a named set of deliverables.
Is LimeSurvey Cloud acceptable for research data under ethics rules?
It can be, but it depends on the ethics approval, the data protection assessment and the contract terms. LimeSurvey Cloud offers hosting regions including Germany, Finland, the UK, the USA, Canada and Australia, and the vendor recommends Germany or Finland for EU customers. Subscriptions are tiered by responses per month or year and by admin users, and when a subscription expires the account falls back to the Free package while keeping access to collected responses. Research offices should check whether the approved protocol names a processor, where data is stored, who can access it, and how deletion is evidenced. If the ethics board requires control over the server, self-hosting is the alternative to test against the protocol.
How are exports to R, SPSS and Stata handled in a self-hosted setup?
LimeSurvey supports export through plugins including ExportR and ExportSTATAxml, and standard exports can feed SPSS as well. The export step should be part of the design, not an afterthought, because variable names, value labels, missing value codes and multiple-choice encoding must match what the analysis scripts expect. The research office should decide whether exports carry identifiers at all, and whether the anonymity settings remove them before a file leaves the platform. Export files are copies of personal data, so their storage location, access list and deletion date belong in the data management plan. Test each export format with a sample study before the first real data collection.
Do we need a partner for ongoing support after the platform goes live?
Not always, but most research offices need someone accountable for upgrades, security fixes, backups and access changes after the first study. Internal teams can cover this if they have the time and skills, and the work is documented. A partner is useful when the institution lacks that capacity, needs a fixed-scope handover, or wants recurring testing and support through a retainer. DeployOpen plans, implements, integrates, hardens, backs up, upgrades, documents and supports self-hosted open-source platforms inside the client's own infrastructure, and ongoing support is available as a retainer. Ask any partner to state in writing what is covered after go-live and what is billed separately.
Which compliance evidence should a research office keep from day one?
Keep a record of the study design, consent text, the data flow diagram, the list of users with their roles, the retention schedule and the deletion log. Under FERPA, institutions must record requests for access to and disclosures of personally identifiable information from education records, and that record must be kept for as long as the records are. The GDPR also expects a record of processing and evidence that retention limits are applied. DeployOpen prepares systems, controls and evidence for compliance assessments, but it does not issue audit reports or certifications, and independent auditors make those judgments. Confirm with your data protection officer which evidence the institution needs before building.
How DeployOpen scopes and supports a university survey deployment
DeployOpen plans, implements, customizes, integrates, hardens, documents and supports self-hosted survey platforms inside the institution's own infrastructure, including university data centers and approved cloud accounts. Engagements start with a written scope that fixes the deliverables for research survey hosting, identity and access, and data handling before any build work begins.
How we scope
- Map each research project, ethics approval and data protection condition to specific hosting and access requirements.
- Confirm which LimeSurvey edition, server stack and hosting location fit the institution's infrastructure and data rules.
- Agree in writing the campus SSO integration, export paths to R, SPSS or Stata, and anonymity settings in scope.
How we build
- Install and harden LimeSurvey on university servers, with the database, PHP and web server configured to institutional standards.
- Configure roles so researchers see only their own surveys, and record access decisions as part of the build.
- Test response anonymity, export accuracy and SSO login against a set of agreed test surveys before release.
How we hand over
- Deliver runbooks covering backups, upgrades, access reviews and deletion of responses at project close.
- Document the configuration, data flows and access controls so the research office and data protection officer can review them.
- Train named administrators and research support staff on creating surveys, managing access and running exports.
How we support
- Offer ongoing support, upgrades and continuous testing as a retainer after go-live, scoped in writing.
- Plan platform upgrades around the supported LimeSurvey release line and confirm end-of-support dates with the vendor.
- Prepare the system and evidence needed for institutional reviews, while independent auditors and certification bodies make the assessment decisions.
