Last updated: Jun 19 2018

Episerver Forms

This provides instructions for Episerver Forms specifically on:

  • what developers should have in mind when developing a site, and
  • what partners/customers should do when a data subject asks for their PII data.

Collecting data

  • If you configure Episerver Forms to:
    • not Allow anonymous submissions
    • not Allow multiple submissions from the same IP/cookie

      Then Episerver Forms collects the Data Subject's user name (of the currently authenticated user on the website) and the browser IP address to perform those features. You should inform the Data Subject about this, using the Form description or Forms confirmation message, before the Data Subject submits the form.

  • Any page that uses Episerver Forms to request input of PII data should be using HTTPS protocol, TLS 1.2 or later.
  • If you use the Hidden visitor profiling feature, Episerver Forms collects data from Data Subject's browser request. You should inform the Data Subject about it.
  • You should inform the Data Subject about how the user's data is used and to what purpose. Put that information in the form description, or use a Rich text element, to inform and summarize at the last step, before the data subject submits the form.

Asking for consent

If you are using Episerver Forms, you are probably collecting PII, and as with all other PII data, you should ensure that sensitive data is appropriately protected, and that consent is captured along with the PII.

When creating forms, you need to take the following issues into consideration:

  • If you use features described in the Collecting Data section, Episerver Forms might collect data. You can turn this off in each form setting.
  • Get consent (if necessary) and consider the following:
    • State clearly the purpose of the data collection in the forms description.
    • Use a check box element to ask for consent.
    • Build a customized form field in Episerver for a consent check box to allow the editors easily manage the consent type and message.
    • Form elements which collect PII data should not be mandatory. Make the consent optional for different types of PII data independently (that is, visitors should be able to consent to the collection of their email address but not their phone number, for example).
    • Link to your privacy policy or other document that states clearly why you are collecting the PII data, for how long and how visitors can withdraw their consent.

  • If you need to change a form currently in use, make a copy and leave the historical form intact, to ensure submissions and consent reflect the current form. Alternatively, add a “Hidden predefined value”, which includes the full consent text, so the consent is stored with the submission.
  • Feature to check the “DNT” header on the request will be implement soon in built-in FormElement. The DNT functionality will be overridable, to make it possible for partners to build their own “Do not track” implementation.
  • Introduce an appropriate retention policy, for example, delete partially completed form submissions within 30 days and completed form submissions when they are no longer useful.

Storing data

  • Episerver Forms stores its data submissions in the DDS (same as the CMS database). The data that is stored might be PII data, and is thus consider as PII data. 
    • Historically, data is stored for a long time, but an ILM (Information Lifecycle Management - Data retentions) feature is planned.
    • Partially filled-in submissions are deleted regularly. 
  • If you use forms to collect PII, it is recommended that you encrypt the form submission data and restrict access to the data, see Encrypting form submission data and Restricting access to data.
  • On-premise installations require encryption of your database instance TDE and encryption at rest.
  • You might not use Episerver as the final destination for form submissions. You can use forms as the ingress point, to redirect the submissions to other endpoints (CRM, Marketing Automation, etc) by using Webhook or the Marketing Automation Integration connector. In this case, submissions (or PII) are stored at another place.

Using data

  • The data submissions should be accessed and used carefully. See Restricting access to data.
    • Developers can process form submissions via the Forms Service API. Developers should consider excluding PII data before processing, and do not show DataSubmission in other places.
    • Editors can view form submissions via the edit view.
    • Editors can export submission data to a file in JSON, XML, or CSV format. The exported data should be considered PII data, and therefore not be stored in some other unsafe store. Restrict the permissions to this feature carefully.
  • Episerver Forms submission storage should not be considered as a long term or permanent storage.
    • Having it as a temporary buffer is an acceptable solution.
    • You should configure the ILM feature (Data Retention) when it is available to clear the storage periodically.
    • No editing feature is planned to modify submitted value.

Fetching data

Data collected by forms are usually point-in-time changes such as signing up, requesting information, or reporting address changes. Such data should be deleted once the visitor has been responded to, or once the data has been recorded at the destination. If you do need to find form submissions from a specific individual, recent versions of Episerver Forms (Forms 4.14.0 and later) have a built-in search capability, which can be used to export submissions.

  • Data Submissions cannot be accessed via the Forms Service API by default. To allow developers to read the data, it must have been explicitly configured (for each form).
  • After configuration, developers should be able to fetch most types of data using the API.

Deleting data

  • It is recommended to use the upcoming ILM feature to delete data after 30 days.
  • Partners are able to delete most types of data.
    • Developers can use the Episerver Forms API.
    • Editors can use the View form submissions feature in the CMS edit view.
    • A more advanced search user interface will be provided to help editors locate and delete data.
  • There is no backup of the form submissions. When you delete it, it is gone from the CMS database. However, there might be backups of the CMS database.
  • If data submissions are sent to other third-party products (like Marketing Automation Integration systems, or other systems via Webhook), Episerver Forms cannot control the data.

Comments