Local development data

Hi Ryan ,

Yes, we have production users' data stored in our local environment as well as dev.islg. Please note that there is no any staging environment for ISLG at DEVIT. Please suggest.

Thank you for confirming Anil .

Morgan perhaps you could bring this up with the lawyer for GDPR? It would only apply to EU citizens, but it would likely be easier to permanently delete all real user data from the local machines. 

Ryan

Hi @Anil,

To clarify your response above. Are you saying that data is being downloaded and stored on non-Carbon60 servers? If so, we'll need to alter this practice so that no user data is ever removed from the Carbon60 servers, and ensure all data currently on non-Carbon60 servers is permanently destroyed.

Thanks,

Morgan

Hi Ryan ,

Could you also confirm with Carbon60 that all the ISLG data stored on their servers is located in Canada, and it's specific location.

Thanks,

Morgan 

Hello Morgan ,

Data from Carbon60 server will never be removed. We will delete all production users data from non-carbon60 server (e.g. from our local environment). 

We are assuming that we only require to delete users data from non-carbon 60 servers but not other data e.g. Subject Navigator, Jurisprudence Citator, Article Citator etc. We need these data in our local environment for development purpose. Please suggest.

Hi Anil . That's correct that it's only user data in your local environment that must be deleted. 

Ryan

Hi Ryan and Anil ,

I'm still uncomfortable with the current situation. What happens when development needs to be done on parts of the application related to user data? How would the team perform the work if they can't download the data to their local environment?

Morgan

In addition to my comment above, I should clarify the GDPR requirements. According to the regulations, cross-board data transfers (i.e., transfers of users' personal data - names, emails, etc.) can only occur outside the EU if the country is an Adequate Jurisdiction. At this point only the following countries are Adequate Jurisdictions:

This means that no user data can ever be transferred from the Carbon60 servers under any circumstances.

Anil , please confirm that you'll be able to effectively service the platform given these constraints. If that's not the case, we'll need to come up with a alternative arrangement. For example, would it be possible for you to perform development work by remoting into the Carbon60 servers, rather than downloading data to your local environment?

Thanks,

Morgan

Hi Morgan ,

For user related issues we can use Carbon60 server for development work but it usually takes more development time than local connection. For non user tasks we can use our local SQL database. Please suggest. 

Hi Anil ,

Understood. I suppose that will work; however, I'm worried that there will be instances where the lines get blurred, particularly when development work needs to be performed on the Notepad Feature. 

Going forward, please proceed as follows:

Will this work for you?

Also, is there a way to make your development work on the Carbon60 server more efficient? For example, do you need us to make any changes to the current setup of the hosting environment?

Thanks,

Morgan

Hi all,

When working on user-related development we could use mock user data as well locally, but if it's a task related to a specific user then it'll have to be on the server.

Ryan

If we can guarantee that no user data is downloaded from the server, I'm fine with that solution. As long as producing the mock user data is more efficient that performing the development work on the server itself.

Morgan

Hi Anil ,

Continuing our discussion above, it's imperative that we implement the following before May 25th:

Further to Ryan's suggestion above, if we can come up with a workable solution where mock data is used to work on aspects of the site that involve user data, I would be willing to consider it, but I would need absolute assurance that the development team would never inadvertently download user data.

Thanks,

Morgan 

Hi Morgan and Ryan ,

Yes, for any new development mock data would be good option instead of working on Carbon60 server. For any production user related issue, we will use Carbon60 server. 

Ok. Sounds good Anil . Please consult with Ryan on how you'll implement this new protocol with mock data. I suggest having a call with him this week if possible.

Thanks,

Morgan 

Hi Ryan ,

Please let me know if you are available for the call tomorrow(Friday). 

Hi Anil . I'm available Friday at 9:15am EDT if that works for you?

Thanks Ryan ,

Will be available tomorrow at 9.15.

Great. Thanks Anil and Ryan . Look forward to hearing what you come up with during your call tomorrow.

Morgan 

Hi Morgan ,

Anil and I discussed this on a call Friday morning and Anil let me know what they've accomplished:

Thanks!

Ryan

Hi Ryan ,

Thank you for the update. The protocol you've outlined above sounds good. However, I had a call with our data privacy lawyers on Friday, and we may have to take additional steps. Apparently even viewing user data (without downloading data) is sufficient to be deemed a processor under the GDPR. Therefore, even if Anil, Harsh or someone else in India views user data on the admin site, it is sufficient to be deemed a cross border data transfer.

I will need to work with the lawyers further to finalize what further adjustments we need to make to our protocols GDPR compliant. Note that this will likely require amendments to our MSAs with both DevIT and Industrial to incorporate GDPR compliant modal clauses. Stephen and Devaang , I'll follow-up with you both soon with the proposed amendments to the MSAs.

Also, Ryan and Anil , I assume the protocol you discussed also includes making the necessary updates to our subscriber management systems, archiving systems, and making Notepad bookmark data inaccessible and encrypted (see tasks above).

Thanks,

Morgan