Fly.io is a US company, but our customers (and our employees, and our servers) are all over the world. This means we have to be up on all matter of legal/regulatory/compliance standards in order to advise our customers on how to make best use of the Fly.io platform. One newer compliance standard is the EU’s Digital Operational Resilience Act (“DORA”). DORA applies to EU financial entities and their suppliers so, if that’s not you, you can probably sit this one out.
The goal of DORA is to strengthen the security and reliability of European financial entities such as banks, insurance companies and investment firms. To do this, the act lays out process, oversight, testing, and contractual elements that must be addressed by financial entities and their Information and Communication Technology (“ICT”) providers. There’s a lot to the act but really only the third-party ICT risk provisions apply to Fly.io.
An important note: this is not legal or compliance advice, as this only considers the Fly.io side of things. Your compliance mileage will vary.
DORA requires much of the provisions that apply to third parties to be spelled out in contracts, likely one-off, between the financial entity and the provider. The requirements are more-or-less sensible though, as with all things contractual, the devil is in the details. But we’re always happy to discuss these sorts of things, so hit us up if you have more questions.
What DORA requires and how they apply to Fly.io
- Rights and obligations of the customer and Fly.io shall be clearly allocated and set out in writing
- AKA our Terms of Service, which can be referenced or imported
- The contract shall include the service level agreements
- Our SLA can probably be referenced or imported as well
- A clear and complete description of all functions and services to be provided by Fly.io, indicating whether subcontracting is permitted and, when that is the case, the conditions applying to such subcontracting
- Any agreement would almost certainly document the service being provided, and adding language around subcontracting should be straightforward
- The locations, namely the regions or countries, where the services are to be provided and where data is to be processed, including the storage location, and the requirement for Fly.io to notify the financial entity in advance if it envisages changing such locations
- The regions where applications run are customer-configured in Fly.toml but the full list of available regions is here Regions · Fly Docs (plus USA for backup storage). So an agreement would likely incorporate the point-in-time list snapshot. Additionally, as we’ll never change a customer’s region (only the customer would), the notification requirement isn’t a problem.
- Provisions on availability, authenticity, integrity and confidentiality in relation to the protection of data, including personal data
- Importing our DPA into the agreement would suffice
- Provisions on ensuring access, recovery and return in an easily accessible format of data in the event Fly.io goes under or in the event of the termination of the contractual arrangements
- Customers are in full control of their data so they can pull it at any time without needing Fly.io participation
- Service level descriptions
- Prose that can likely be pulled from the SLA or ToS
- The obligation of Fly.io to provide assistance to the customer at no cost or at a pre-arranged cost, if we experience an incident that affects the customer
- This is a bit open-ended as “assistance” can mean many things. However, generally, we’re happy to assist with all reasonable IR/DR requests already.
- The obligation of the Fly.io to cooperate with the authorities and the resolution authorities of the financial entity, including persons appointed by them
- Similar to the above, we assume we’ll be on deck to assist, within reason, if something goes wrong
- Termination rights and related minimum notice periods
- Already covered under the ToS but can be revised and extended to suit.
- The conditions for the participation of Fly.io to participate in the customer’s security awareness programs
- There no conditions where that would be necessary (our staff wouldn’t work day-to-day alongside customer staff) so easy to document the “no such condition” condition
Not too bad, right?
By the way, there’s a fun thing when it comes to talking about DORA: it’s so new that even though the act went into effect in January of 2023, it doesn’t actually apply until January of 2025. Which means folks are still figuring out what DORA compliance looks like, and who knows what interpretations may surface in 2025?