How We Think about Compliance at OpenFn

BEFORE READING ON, please note that the information provided below should not be considered legal advice. You should work with a lawyer or professional counsel to ensure that you’re adhering to the laws and regulations that mayP apply to you. That said, we hope that this will prove useful and urge you to read our related sections about Trust and our External Service Providers, as well as our Privacy Policy and the Terms and Conditions for the OpenFn SaaS product.

The GDPR in a Nutshell

We follow the lead set by the landmark GDPR. While nobody likes the popups, the GDPR is a tremendous piece of multi-national legislation that’s aimed at protecting us (that’s you, our customers, and us, as we use websites and services regulated by the GDPR as well). We not only adhere to the letter of the law, but strive to embody the spirit of the GDPR. Sanity.io, fellow software-as-a-service providers, offer a beautiful articulation of this spirit:

1. Collect as little as necessary, keep it for as short as necessary, and share it with as few as necessary.
2. Be transparent about what it will be used for, explain it in clear and simple terms, and only use it for the stated purpose.
3. Allow the individual to choose what to share, to retrieve all of their data, to correct it, and to permanently delete it.
4. Keep it secure, and notify the individual and the authorities as soon as possible in the case of a security breach or data leak.

By working with these basic principles in mind, Open Function Group orients its compliance strategy first practically, and then drills down to ensure compliance with individual—and more technical—regulations. Here, we explain exactly how each of the central concepts of the GDPR (from the section above) applies to OpenFn:

1. We don’t use your data to do anything but deliver our service to you and expand the number of organizations or governments we can serve by understanding platform usage at a high-level. Beyond that, no information that isn’t essential to this offering is required from our users and we select all of our external service providers very carefully.
2. Here’s what information we collect:

• We collect limited personal information (your name and email) so we can communicate more effectively with you.
• We collect limited company information (organization website and name) so we can better understand which organizations are using OpenFn—we’re primarily serving the non-profit, government, and social sector.
• We collect credit card information via a secure payment processor so that we can bill you for your usage.
• We collect limited amounts of browsing data to understand (in an anonymous way) who’s using our website and how—including what pages they visit and how long they spend on each page.
• We safely store your project data so you can use the service itself. Be sure to read the section below on your role as a data controller to understand the implications of this:
  • We store your Inputs (inbound events) and run logs so that you can verify the status of individual transactions and reprocess data. On free plans this information is kept for 90 days, and our paid plans come with longer retention options. You can ask to shorten your data retention at any time.
  • We store your credential data so that your jobs can interact with services which require authentication. These credentials can only be accessed by you, and are loaded into your private runtime for job execution. You can delete these credentials at any time and they will be purged from the system.
  • The other things that you create and store on OpenFn (jobs, triggers, authentication methods, etc.) are kept as long as your account is active, but can be removed either through the interface or by request.
• Both full data exports and complete account purges can be requested at any time in writing, and we plan to introduce a safe and automated way to achieve these objectives through the interface.
• While we haven’t had a security issue to date, we have internal policies governing how we audit our systems, protect client data, and how we will respond in the event of a security breach. In the event of a breach, the authorities and all customers will be notified within 72 hours.

That’s the gist of our policy stance as the “data controller”. For the sake of full-transparency, here is a list of every single third-party provider we interact with while handling your data and why. Read on to understand how, by using OpenFn, you’re also taking on “data controller” role, with OpenFn as the “data processor”.

Data Controllers vs. Processors

Article 4 of the GDPR defines a data controller as “the natural or legal person, public authority, agency or other body which, alone or jointly with others, determines the purposes and means of the processing of personal data”. The data processor is a “natural or legal person, public authority, agency or other body which processes personal data on behalf of the controller”. Put simply, data controllers are legally responsible for data and order certain things to be done with it. Processors are (in most cases) services or companies that carry out tasks with data based on the instructions of the controller.

This is crucial to understand: When you use OpenFn to process some information related to your patients, your students, or your community development programs, you are the data controller in the eyes of the GDPR and OpenFn is the processor. We are, of course, acting as a controller for different data when we gather customer information and make decisions on how to use and store that data. (The first section of this document outlines our policies as a data controller.) So, what should you consider as a data controller? You should absolutely talk to your lawyers and ensure that you’re not using OpenFn in any way that’s in violation of the GDPR, but for a cliff-notes version, make sure to understand our position as a controller in section X, and keep these additional things in mind:

1. You’re using OpenFn to connect to, receive or extract data from, and load data into lots of different applications. The first thing you’ll want to do is make sure you’re only connecting OpenFn with applications that you’ve vetted and can maintain GDPR compliance with.
2. The next step is to limit the amount of data that you’re pushing or pulling into OpenFn, ensuring that you only use and process what’s absolutely necessary. In this case, think of yourselves the way we do, with respect to the GDPR: “Collect as little as necessary, keep it for as short as necessary, and share it with as few as necessary.”
3. When you’re done with OpenFn, make sure to delete your account. While we’ll automatically purge old activity data, leaving a job turned “on” might mean that even if your project is on the free usage tier, OpenFn could continue to connect to and process information from your various connected applications—only as you’ve directed it to, of course.

By acting as a data controller and deciding how potentially sensitive information is handled carries with it a real legal responsibility. Open Function Group recommends that you work with a lawyer to ensure that your organization is fully compliant with the GDPR. You can read the full regulation here.

Data Storage on OpenFn

OpenFn is a middleware provider rather than a data storage system. We move information from system A to system B, and integrations can be configured to be compliant with GDPR, HIPAA, and other policies. To make auditing and reprocessing easy, OpenFn temporarily stores message data and run history, but we’re not the single source of truth nor the final resting point for these data. When organizations choose to use our hosted OpenFn platform at OpenFn.org, no data processed by OpenFn is stored locally and our platform runs on the Google Cloud Platform (GCP). Read more about GCP and our external services.

For organizations with data residency concerns, Open Function Group also offers local and in-country cloud deployment options for the OpenFn platform so that organizations have complete control over where any data is stored. Learn more about deployment options or see OpenFn Documentation for more on data storage.

To facilitate integration monitoring and troubleshooting, OpenFn temporarily stores message data and run logs for 90 days by default. This retention period can be shortened or turned off altogether if desired, and both full data exports and complete account purges can be requested at any time in writing. If desired, users may also enquire about disabling this feature entirely with support from OFG to ensure that OpenFn never keeps data (once processed) from connected systems. We strive for transparency and professionalism at OpenFn. If anything here is unclear, if you have any questions, or if you’d simply like to talk to us about the GDPR or other hosting options, please don’t hesitate to contact us by emailing security@openfn.org.

Visit our Trust & Security page to learn more about OpenFn security.