Snap4City: GDPR compliance and requirements

×

Warning message

  • You can't delete this newsletter because it has not been sent to all its subscribers.
  • You can't delete this newsletter because it has not been sent to all its subscribers.

This content has been extracted from the IEEE Access article: 

The demonstration that a platform is GDPR-compliant is a very complex task, and there is lack of official tools for the verifications. On the web and market there are a number of checklists that can be adopted for the verification that a data management process is GDPR-compliant and only a few that may help the developers to test if their Web solution is GDPR-compliant. It should be noted that, some of the GDPR aspects may be evident from the user interface, UI, and thus they can be verified by external testers, while others (such as encryption, security level, etc.) can only be tested by code inspection and/or performing the penetration test (pentest) as described in Section VII-B. Interesting proposals have been suggested as a partial checklist on [60] and [61]. The list reported in Table 3 reports the approach adopted for verification of GDPR compliance of Snap4City. In particular, it takes into account the UI aspects, source code access and demonstrations, as it was requested by Select4City to assess the platform.  

    Moreover, in Table 3, each major feature to be compliant with GDPR has been related to the proposed requirements of Section III. The detailed verification report would likely encompass some hundreds of pages and thus could not be accommodated to the space constraints of this article.

The set of GDPR features is not strongly related to the application domain of the smart city platform in terms of mobility, energy, home, etc., while it is mainly related to the usage of the platform, so that it refers to the applications. In all of the smart city domains mentioned, the user may be involved or not. An application on mobility for managing traffic without providing personalized services would not need to collect personal data; neither would it need to have citizens registered on the platform. The same can be stated for energy: the reporting of building energy consumption in an aggregated manner is not personal data. Therefore, the mapping of GDPR aspects vs domains would be very difficult to be realized without describing the applications. In Snap4City, the applications may all involve final users, in any domain. This implies that personal data have to be treated as described in the paper, disregarding the application domain. It is also very restrictive to think that the application would be domain-oriented for the data. For example, parking predictions are based on historical data of parking but also on traffic and environmental data, and events of people.  This is the strong point of Big Data.

 

 

GDPR Compliance Verification Feature

Verif.

Reqs.

Signed consent

UI

R8

User profile management and control

UI

R13

Data Type private as default

UI

R8

Rights to access per element

UI

R9

Rights to transfer per element

UI

R10

Rights to erase per element and total

UI

R13

Rights to revoke/change per Data Type

UI

R10

An interface for Right management for Data Type

UI

R9

Clear Terms of Use and Privacy Policy

UI

--

Auditing Tools for Data Type

UI

R14

Publish as Anonymous

UI

R9

Encrypt personal users’ data

Code

R12

Secure Authentication and Authorization

Code

R3

Data protection by Design

Code

R17

Secure connection

Code

R6

Security Control, data breach control, anonymization, etc.

PEN Test

R15, R16, R18

TABLE 3: CRITERIA FOR GDPR COMPLIANCE VERIFICATION FEATURES VS VERIFICATION APPROACH (VERIF.) AND MAIN REQUIREMENTS OF SECTION II (REQS.)

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

[60] Siemens MidSphere, https://new.siemens.com/global/en/products/software/mindsphere.html, accessed on: Jan. 20, 2020

[61]https://www.privacypolicies.com/blog/gdpr-compliance-apps/, accessed on: Jan. 20, 2020