Hi @SushantBista,
So we’ve circled back to our legal counsel and the pointed out that in the Forge DPA ( https://dac-static.atlassian.com/platform/forge/resources/Forge-Data-Processing-Addendum.pdf?_v=1.5800.273 ) 1.2.a:
Where Atlassian processes End User Personal Data on behalf of Developer in connection with the Services, Atlassian will process such End User Personal Data as a processor or Sub-processor on behalf of Developer (who, in turn, processes such End User Personal Data as a controller or processor respectively) and this DPA will apply accordingly. A description of such processing is set out in Annex 1(B), Part A of Exhibit A to this DPA.
Will Atlassian update the Forge DPA to update this reflect that the platform is taking the instructions from the customers and not from partner? (Which if done - then it would make the Forge platform a processor of the customer and not us - we would be co-processors of the customer).
As far as
- Pinning location: Forge Hosted Compute will be provisioned and operational in all Atlassian supported locations to ensure acceptable performance (when Forge Hosted Storage is multi-location enabled). As with Jira and Confluence data residency, data-in-transit will not be pinned to any particular location.
Again - please reconsider this part. As we have the customer relationship (this is specifically called out in the Forge DPA and Developer terms) - we need to control where the data processing (including if we would rather be dead in the water). We have several large enterprise companies that if we can’t guarantee where the data is processed and stored then we won’t get them as companies.
This isn’t “nice to have” -we need to be able to control where our customer’s data is processed and stored at all times. Without that we can’t be gdpr compliant and anyone using Forge will have issues managing compliance requests/requirements from large enterprise customers.
I really hope that these items can be resolved, because not having to build out a Data Residency solution would be great, but these are serious obstacles for us.
6 Likes
Thanks for the comments. Looks like I missed the discussion close date by a few days but it looks like the community got some good use from the extra time. @SushantBista assures me he is working with legal to get some input and will have answers in the resolution coming in about 2 weeks.
1 Like
Per @SushantBista’s request, we’re adding 1 more week to the resolution time for this RFC. Please expect resolution around 17 November 2023.
Hi everyone,
Thanks for sharing your valuable feedback and suggestions with us.
Based on your inputs:
- We are looking into providing an audit trail or logs that can be accessed by developers to know what, when, and who certain requests regarding migrations has been made by the customer. This can include information that a customer has requested a realm migration for their Forge app/host product. We will reach out to developers if we need further feedback on this.
- Customers will be able to proactively review apps that are moving with the product in admin.atlassian.com before submitting their move request.
- To provide more clarity during manifest declarations, we will be updating
in-scope EUD to inScopeEUD, as well as adding a new operation value to be used for external permissions.
In regards to the feedback around GDPR:
- We have described our position on this topic in this comment. Atlassian will continue to act as your processor (or sub-processor) the same way we do currently, and we will only take the actions described for data residency if you instruct us to do so by using Forge Hosted Storage. After considering this information and consulting with your own legal counsel, if you would like to leverage this feature, by enabling Forge Hosted Storage in your app you will be providing Atlassian with your instructions to provide data residency as described in this RFC. On the other hand, if you decide that you would not like for Atlassian to provide data residency in this way, you can elect not to use Forge Hosted Storage. This feature is purely optional, and as shown in the examples in our original post (and detailed further in RFC-8), your app can leverage remote storage instead. We will be providing notice to developers in advance to understand our implementation and its limitations. We’re also working on detailed developer documentation to be published when we start to roll out this feature for use.
- After data residency is released, Compute will continue to function the way it does today, globally. As a provider of global services, Atlassian may process personal data globally in order to maximize reliability and performance, as well as to facilitate security and fraud prevention. This is allowed by the GDPR provided certain conditions are met, which Atlassian meets and describes in more detail in the Forge DPA and Data Transfer Impact Assessment.
Thanks again!