On the Visual Studio App Center team, our engineers are completely aligned with the General Data Protection Regulation (GDPR), which gives consumers better and more explicit control of data – especially their personal data.

For those of you who are less familiar with the GDPR, it is a European regulation designed to give consumers greater control over their data. One way the regulation establishes that control is through a set of Data Subject Rights (DSRs), where the consumer is a data subject and those honoring rights are either data controllers responding directly to the data subject or data processors who support the data controller in responding to data subjects. The relationship could be similar to the controller customer acting as the landlord and the processor is the company the landlord hires to keep everything running and secure in the building.

Microsoft is primarily a data processor for data processed in App Center, although in a limited capacity it also functions also as data controller. Therefore, our team had two actors to satisfy when the GDPR was enacted: App Center customers wishing to exercise their rights as data subjects, and App Center customers as data controllers needing to honor their customer’s rights as data subjects

Requirements

DSRs include a wide variety of rights, and we needed to support these through functionality that made sense to our customers. These included the right to access (including viewing and getting a copy), and to delete just to name a few. We needed a way for customers to submit DSR requests and for us to track fulfillment; in the case of delete, anonymously. And whatever system we built, it would need to support not just first party code but also third-party services and software that our developers count on, such as HockeyApp.

Challenges

Since we practice a lean approach, prior to GDPR communication between the services centered around account lifecycle and portal continuity concerns. We needed a new system that would accept and distribute DSR requests to each service making up App Center.

In addition to distributing requests, our new system would also have to be able to replay requests in the unlikely event of a catastrophic failure and restoration from backup. Since we are required to execute DSR requests to be forgotten within thirty days, that meant aligning retention timeframes for both requests and all back up data.

And all of this was just for App Center and HockeyApp customers as data subjects. We still had to help our customers meet the GDPR obligations they had with their customers.

Solution

Given the requirements of the GDPR and the particular challenges App Center faced, the team designed and built a DSR request orchestration system surfaced with a RESTful API. The orchestrator:

1. 1. Accepts DSR requests

1. 2. Maintains a list of services participating in orchestration

1. 3. Identifies the core contextual data associated with said services

1. 4. Distributes request messages to all services

1. 5. Tracks execution by participating services

1. 6. Raises alerts when failures are detected

1. 7. Replays request messages when required

1. 8. Scales to accept new participating services

9. Listens and responds to Microsoft-wide MSA and AAD account closure messages

The team also went to lengths to identify gaps in our existing APIs where we felt we needed to provide customers with more control over their customer’s data. We filled in these gaps, added methods to adjust data retention, and provided documentation for how to mitigate GDPR risk while using App Center.

Future

Moving forward we aim to tune and improve our GDPR API as well as to improve customer control over data. To the latter point, we expect that features like identity (allowing customers to attach identity information to calls) will help, but we also look to you for suggestions. If you could change anything about App Center’s approach to GDPR, what would it be?