The documentation of data processing activities and "Technical and Organisational Measures" is a requirement under the GDPR (General Data Protection Regulation).
As many other organisations, at details we are required to maintain a record of our processing activities, covering areas such as processing purposes, data sharing and retention.
As an [https://en.wikipedia.org/wiki/Application_service_provider|Application Service Provider] we do this on the basis of the Shared Responsibility Model - as applied by other service providers.
For more information on this concept, please read the AWS resources about Shared Responsibility Model and The Shared Responsibility Model and GDPR.
As you might know the GDPR applies to both 'controllers' and 'processors'.
A controller determines the purposes and means of processing personal data.
A processor is responsible for securing the underlying infrastructure that supports the cloud and the services provided to process personal data on behalf of a controller.
In regards to most personal data processing within the details application incl. related links and Apps we would be the processor and the GDPR places specific legal obligations on us. And as you might guess - as a company trying to provide the best service possible to our clients - protecting the application infrastructure is our number one priority and we invest heavily and continuously in appropriate technical and organisational measures to make details safe and secure.
As however for most workflows you are a controller, it means you are not relieved of your obligations just because a processor like details is involved instead ''you remain responsible for any personal data you put into the cloud!''
In other words it remains your responsibility what password you choose, what information you collect from business partners, artists and promoters and how you set data access restrictions for users within the settings of the details application.
So the GDPR places obligations on you, too, including your very own documentation obligations.
The GDPR applies to processing carried out by organisations operating within the EU.
It also applies to organisations outside the EU that offer goods or services to individuals in the EU.
Here is an overview of sections, we refer to as the
Technical and Organisational Measures at DETAILS
1. Confidentiality (Article 32 Paragraph 1 Point b GDPR)
Physical Access Control
No unauthorised access to Data Processing Facilities:
At details this is ensured by our hosting service AWS in section 1.2.1 Physical Access Controls of their AWS GDPR Data Processing Addendum.
Electronic Access Control
No unauthorised use of the Data Processing and Data Storage Systems:
At details this is ensured by our hosting service AWS in their Security Whitepaper. Within the Shared Responsibility Model AWS ensures that there is no unauthorised access to our Data Processing and Data Storage Systems other than our technical team.
AWS also provides full encryption of all data carriers and storage media.
Internal Access Control
No unauthorised Reading, Copying, Changes or Deletions of Data within the system:
details provides a need-based rights authorisation concept in the USER SETTINGS section of the application, accessible only by client users with administration rights and our support team. The USER SETTINGS section is secured with admin-log-in access control to avoid any unauthorised changes.
The permissions for user rights of access are however set by the client, i.e. the controller which make user access settings for individual users the responsibility of the client as well as the security of their passwords. In the light of the GDPR we want to highlight that our clients may also administer access control to contact data export options within the Module Settings of our USER SETTINGS
In addition details provides permanent logging of system access events and user actions within the SETTINGS and the rest of the application.
The isolated Processing of Data, which may be collected for differing purposes:
At details all clients are working on distinct and secured separate databases.
No client or third party will have access to our clients' data - except on the clients prior explicit consent.
Examples for details features that involve shared data on prior and explicit consent are:
*iCal links shared by clients with artists and third parties for calendar subscriptions
*RSS feeds shared by clients with third parties for booking calendar information
*Booking OnlineApp links shared by clients with artists and third parties for Online Itineraries
*Booking Questionaires and Online Request Forms shared by clients with promoters for Online Communication
*Booking Agreements shared by clients with promoters for Online Agreement
*Transfer of sales and royalty information between details clients ("details-to-details")
*Links to Royalty Statements shared by clients with artists and third parties for Online Reporting
*Transfer of shipping information send by clients from details to logistic companies
Note that details does process collective data of event locations across clients - such as location names, addresses, postal codes, cities and capacities, which are however not containing any personal information and therefore don't fall under the regulations of the GDPR.
In regards to multiple client support details provides separate isolated accesses to our clients databases for our technical & support team, each secured with separate users and passwords.
Pseudonymization (Article 32 Paragraph 1 Point a GDPR; Article 25 Paragraph 1 GDPR)
The processing of personal data in such a method/way, that the data cannot be associated with a specific Data Subject without the assistance of additional Information, provided that this additional information is stored separately, and is subject to appropriate technical and organisational measures.
At details we relate data and tables with IDs, e.g.: user_ids, contact_ids, artist_ids. That way data cannot be associated with a person, unless client has granted user access to the respective contact information witthin the User Settings.
2. Integrity (Article 32 Paragraph 1 Point b GDPR)
Data Transfer Control
No unauthorised Reading, Copying, Changes or Deletions of Data with electronic transfer or transport:
Since 2017 all communication with the details service is encrypted with SSL (HTTPS).
For additional security we encourage the use of Virtual Private Networks (VPN) to access the details application.
Data Entry Control
Verification, whether and by whom personal data is entered into a Data Processing System, is changed or deleted:
At details all our clients' and support team's actions are logged permanently. To comply with the Data Entry Control requirement we specifically log data about the client and user identification, access time, authorizations, actions and IP addresses. In other words, we store metadata about which users are accessing which client database at what time, and what section of the application was worked on with which command.
3. Availability and Resilience (Article 32 Paragraph 1 Point b GDPR)
Prevention of accidental or wilful destruction or loss:
At details we implemented nightly snapshot backups provided by our hosting partner AWS
Uninterruptible Power Supply (UPS), virus protection, firewall, reporting procedures and contingency planning are also provided by AWS as part of the Shared Responsibility Model.
Rapid Recovery (Article 32 Paragraph 1 Point c GDPR) (Article 32 Paragraph 1 Point c GDPR);
Rapid Recovery is also provided by AWS as part of the Shared Responsibility Model.
4. Procedures for regular testing, assessment and evaluation (Article 32 Paragraph 1 Point d GDPR; Article 25 Paragraph 1 GDPR)
Data Protection Management
Incident Response Management
Data Protection by Design and Default (Article 25 Paragraph 2 GDPR)
As mentioned at the top of this article protecting the application and its infrastructure is our number one priority and we invest heavily and continuously to make details safe and secure as we go. To comply with GDPR we discuss Data Protection, Privacy and Incident Response matters with all new feature developments and continuous evaluations of existing workflows.
One example for Data Protection by design and default is how we create shared links for our Online App for Booking: First every new booking artists receives a random access key by default. Also by default we de-select all sensible personal information such as artist fees, promoter name or address.
Within this process the user, i.e. the controller selects what personal information he wants to share and selects options accordingly.
Order or Contract Control
No third party data processing as per Article 28 GDPR without corresponding instructions from the Client:
At details we have a very limited number of strictly controlled Service Providers.
While we integrate with those Service Providers, such as AWS, Google Maps, FlightStats, most of them do not process personal data and don't fall under the regulations of the GDPR. Whenever they do, we make sure to have clear contractual data protection arrangements and follow-up checks.
The client billing at details is provided by service provider ADYEN, which is processing a full pseudonymized token with no personal information at all.