← Blog posts

Capture form submissions safely

By Steven Singh on 03-10-2022

Most of us interact with digital forms frequently. Many of us even daily. Some forms are functionally driven (such as searching in Google) whereas other have the purpose of capturing relevant data about us. This could be anything from login screens to checkout flows or simple contact forms. A lot of forms have, however, been stripped away from websites over the past years - especially from companies that work globally and need to adhere to Data Subject Right across multiple regions. It simply becomes too complex.

Providing a secure platform for capturing form submissions is at the core of our offering. We want to give you peace of mind. Here is how.

Protect the data

First of all, we protect the data by default. All information that you collect about a Data Subject is by default:

  1. Encrypted in transit. This means that it's sent securely between the end user and our platform via SSL.
  2. Encrypted at rest. This means that we encrypt the data if and while we store information about the the Data Subject on our platform. You can chose to have data stored without encryption but that is your decision - not ours.
Further than that, your submission data is not stored in one gigantic database together with the data from our other clients. We store your data in a dedicated bucket that only you have access to.

To go even further, we even offer that you can differentiate which users are able to decrypt and thereby view data submissions. In other words, some users may not be able to see submission at all, some users may be able to view parts of the data that isn't encrypted whereas some super users may be able to view all submission data. This gives you the control over your data!

Process the data as you wish

Okay, so data is stored securely. But we also want to make sure that data is treated in certain ways after being captured. In GDPR there are several important topics to consider in relation to form data:

  1. Do you even need to store the data in the platform. If you need to trigger a flow in a back office system, why even store the data persistently on our platform.
  2. If you store the data, when is it anonymized? In Collect.DEV you can specify when data is anonymized. Just like data encryption, you can select which fields should be anonymized to keep non-traceable data available (for example you could anonymize name fields but leave a country field be).
  3. You can control when data is automatically deleted. You don't have to delete the data but we certainly offer you mechanisms to automatically clean up your captured PII. This doesn't mean that you lose statistical trace of how frequently a form has been used - it simply means that we will remove the actual submission and replace it with a statistical representation.
  4. According to GDPR, Data Subjects also have the right to be forgotten or right to access their data. We therefore offer you the ability to find information captured for a data subject and either, anonymize, delete our download this information.
In total, this gives you a platform that treats Data Subject information with respect.

In Collect.DEV, we organize forms in projects and these projects can control Anonymization and Deletion rules. But the project can also control the storage location. This is because some countries and regions require you to process and store personal identifiable information about their citizens in a certain location. For example, you can create a project that is relevant to EU. Now when you embed the form on your site, it will submit data within EU, process data within EU and store your captured submission data inside EU. A clone of the same form (not a copy) may be used in a project where data is fully handled in the US.

But do you even need to store the data? Our principle is that data storage is a choice. You may capture data, send it off to your back office systems and from then on the data is on statistically represented in our platform. We don't force you to keep the data to trace when and how frequently a form is used. Further, if you have email or slack notifications, we don't actually share any of the submitted data - only that some data was submitted. This is, again, to minimize the risk of PII being stored in inadequate systems or being shared with wrong individuals.

But we recognize that this is probably not even enough. Therefore we have also made it possible for you to capture data without it ever passing through our platform. Many form builder tools struggle to deal with Sensitive data and end up suggesting private cloud deployments for such scenarios. Differently, we allow you to plug in your own submission handler (we call it a Form Handler). You can use our SDKs to build an Azure Function, AWS Lambda or likewise that will receive the PII. You can then process the data as you wish without the data ever touching us. The SDK will then allow you to signal us that a form was processed - but only for statistical purposes.

And that's it. It's fairly simple but also slightly complex. :-)