https://wso2.com/solutions/regulatory-compliance/gdpr/ The EU General Data Protection Regulation (GDPR) has many identity architects uniquely positioned to help their organizations to comply with the ruling. Effective from 25th May 2018, the regulation 2016/679 of the European parliament and of the council, replaces the Data Protection Directive 95/46/EC and is designed to harmonize data privacy laws across Europe. It aims to protect and empower all EU residents' data privacy and to reshape the way organizations across the region approach data privacy. GDPR is also quite prominent due to the heavy penalties introduced for violators — which could be as much as 4% of the annual global turnover or €20 million (whichever is greater). In this webinar we will discuss all technical aspects of the regulation and what steps you as an identity architect can take to ensure that your security strategy is primed for GDPR.

1. General Data Protection Regulation (GDPR)
for Identity Architects
Asanka Abeysinghe, Vice President, Solutions Architecture
Prabath Siriwardena, Senior Director, Security Architecture

2. GDPR OVERVIEW

3. 3
WHAT IS GDPR?
• The EU General Data Protection Regulation (GDPR) is the regulation
2016/679 of the European parliament and of the council, which replaces the
Data Protection Directive 95/46/EC.
• Enforceable from 25th May 2018

4. 4
SIX KEY PRINCIPLES
• Personal data must be processed lawfully, fairly and transparently.
• Personal data can only be collected for specified, explicit and legitimate
purposes.
• Personal data must be adequate, relevant and limited to what is necessary
for processing.
• Personal data must be accurate and kept up to date.
• Personal data must be kept in a form such that the data subject can be
identified only as long as is necessary for processing.
• Personal data must be processed in a manner that ensures its security.

5. 5
WHOSE DATA ARE PROTECTED?
• Individuals based in the EU, wherever in the world their data ends up being
held or used.
• It also applies to anyone else's (even non EU residents) personal data if it is
handled from the EU.
• Not about citizens!
• Time of stay of the user in the EU?
– GDPR does not specifically talk about this.
– Time of data processing (not decisive)
– Time of data collection (decisive)

6. 6
WHICH DATA ARE PROTECTED?
• Processing of any personal data, is protected under GDPR.

7. 7
PERSONAL DATA
• Any information that could be used to identify the data subject is personal
data, and this information can be in any format. This can encompass
photographs, correspondence, physical media and so on.
• One can be identified, directly or indirectly, in particular by reference to an
identifier such as a name, an identification number, location data, an online
identifier or to one or more factors specific to the physical, physiological,
genetic, mental, economic, cultural or social identity of that natural person.
• The regulation is not applicable to the personal data of a deceased person.

8. 8
PERSONAL DATA (SPECIAL CATEGORIES)
• Personal data revealing racial or ethnic origin, political opinions, religious
or philosophical beliefs, or trade union memberships.
• Data concerning health or an individual’s sex life or sexual orientation, as
well as genetic data and biometric data .

9. 9
WHAT FALLS UNDER PROCESSING?
• Any operation or set of operations that is performed on personal data,
whether or not by automated means.
• Collecting, recording, organizing, structuring, storing and erasing of data.

10. 10
WHAT BUSINESSES WILL GET IMPACTED?
• Any business inside or outside EU, which offers goods and services to data
subjects in EU.
• Any business inside EU which offers goods and services to anyone in the
world.
• Under the European Economic Area (EEA) Agreement, the Regulation
applies throughout the EEA as well as in the 28 Member States of the EU.
• For example an Australian company does not necessarily address its goods
or services to individuals in England or Scotland, just because their website
is available in English.
• To fall under GDPR, any company outside EU, must intend to address
European consumers.

11. 11
DATA CONTROLLER
• The entity which determines the purposes and means of the processing of
personal data.
• These will usually be the ‘public-facing’ entities that data subjects supply
their information to.
• For instance, a hospital might have an online form for entering health
information; even if the online form is provided by a third party, the hospital
(which will determine what the data is processed for) will be the data
controller.
• If the data processing involve high-risk the controller has to carry out a data
protection impact assessment (DPIA) on the impact of the corresponding
processing activities.

12. 12
DATA PROCESSOR
• The entity which processes personal data on behalf of the controller.
• In many cases, the data controller and the data processor will be the same
entity.
• In the previous example, the organisation that provides the online form will
be a data processor because the act of collecting data is included within the
definition of ‘processing’.
• A single data controller may have several data processors.
• Not a third party. A third party is some other party, other than the data
subject, controller or the processor.

13. 13
SUPERVISORY AUTHORITY
• Each member state will have its own supervisory authority.
• Upon request by the supervisory authority, both the controller and the
processor are obliged to demonstrate their compliance with GDPR.
• Accepts complaints from the data subjects.
• Plays a key role during the data protection impact assessment (DPIA),
provides advice to the controller on a case-by-case basis.
• During the DPIA if the controller finds a high risk item, the supervisory
authority needs to be consulted.
• The controller has to notify the supervisory authority in case of a personal
data breach in less than 72 hrs after becoming aware of it.
• The processor does not have an obligation to notify a data breach to the
supervisory authority, but to the controller.

14. 14
DATA PROTECTION OFFICER
• Motivated by the German Data Protection Law - where DPOs have proven to
be successful for more than 30 years.
• Both the controller and processor can have a designated data protection
officer.
• A data protection officer can provide his/her services to multiple data
controllers/processors.
• The data protection officer is the glue between the controller/processor and
the supervisory authority.
• Provides advices to the controller/processor and their employees on data
protection obligations.

15. 15
REPRESENTATIVES BY NON-EU ENTITIES
• Entities do not have an establishment in EU, but still fall under GDPR, have
to appoint a representative in the EU.
• This representative acts as the point of contact between the non-EU
controller/processor and the supervisory authority.
• Does not applicable for the companies which do occasional processing of
personal data, no large scale processing on special categories of personal
data and unlikely to result in a risk to the rights and freedom of individuals.

16. 16
GDPR ORGANIZATIONAL STRUCTURE

17. DATA SUBJECT’S RIGHTS

18. 18
• The data subject must be informed of the existence of any processing
operations on its personal data.
• The controller must provide minimum information on processing to the
data subject.
• During the data collection, the controller has to provide its identity and
contact details
– Also where applicable the contact details of the data protection officer.
• The controller must share the purpose and legal basis for data collection
and processing.
THE RIGHT TO ACCESS / BE INFORMED (1/2)

19. 19
THE RIGHT TO ACCESS / BE INFORMED (2/2)
• The controller must share the details of the recipients of the personal data.
• Need to specify the intention of the controller (if any) to transfer data to a
third country.
• The period for which the personal data is stored.
• The information about the data subject’s rights.
– The right to withdraw a given consent
– The right to lodge a complaint with the supervisory authority
• The controller is obliged to respond to a request by the data subject within 1
month of receipt of the request.

20. 20
THE RIGHT TO RECTIFICATION
• The data subject has the right to rectify processing of incomplete personal
data .
• The right to rectification helps to correct or prevent negative effects on the
rights and freedom of data subjects.

21. 21
THE RIGHT TO ERASURE
• Ground for erasure
– The personal data are no longer necessary in relation to the purpose for
which they were processed.
– The data subject withdraws consent on which the processing is based,
and there is no other legal ground for the processing.
– The personal data has been unlawfully processed
– The personal data has to be erased for compliance with a legal
obligation under EU or EU member state law.
• The data subject has the right to demand from the controller the erasure of
personal data.

22. 22
THE RIGHT TO ERASURE
• Erasing data means, it should not be possible to restore the data without
excessive efforts.
• Examples:
– Search engines which index personal data
– Social networking sites

23. 23
THE RIGHT TO RESTRICTION OF PROCESSING
• Grounds for restriction of processing
– The accuracy of data is contested by the data subject.
– Processing is unlawful, and the data subject opposes the erasure of its
personal data and requests the restriction of their use instead.
– Controller does not require the data for the purpose the data was
collected - but the data subject requires them for defence of legal
claims.
– Data subject objects for data processing

24. 24
THE RIGHT TO DATA PORTABILITY
• Provides the possibility to transmit data subject’s personal data from one
controller to another.
• In this regard, the legislator primarily targeted the operators of social
networks.
• Strengthen the competition among service providers.
• Any data that has been generated by the controller as part of processing,
such as by a personalization or recommendation process is not covered by
the right to data portability.

25. IAM DESIGN PRINCIPLES
AND
BEST PRACTICES

26. 26
DECOUPLE PERSONAL DATA FROM
TRANSACTIONAL/BUSINESS DATA
• Personal data can be the data provided by the subject or the raw data
provided to the controller by other means.
• Limit the personal data stored under IAM system - and let other business
applications store business specific data.
• For example IAM system should not worry about following data.
– If it’s a bank, the transaction history of the data subject or the credit
history.
– Data related to background checks about employees.
– Performance ratings
– Buying patterns
• Decouple biometrics from other personal data.

27. 27
IMMUTABLE PRIVATE IDENTIFIERS / MUTABLE
PUBLIC IDENTIFIERS
• Use an immutable private identifier (pseudonym) to identify a user.
• Never use personal data in audit logs - rather the pseudonym.
• Capture and record all the analytics against the pseudonym.

28. 28
DECLARE AND GET THE USER CONSENT FOR THE
IAM COOKIE POLICY
• Use cookies only to manage user sessions and identify user preferences.
• Explain the user the usage of cookies - and the options to reset.
• Do not save any data in cookies, even encrypted.
• Do not track the behavior of anonymous users via cookies.
• Upon registration - or during the login process get the user’s consent to the
cookie policy.

29. 29
DECLARE AND GET THE USER CONSENT FOR THE
IAM PRIVACY POLICY
• Explain briefly how personal data are maintained - and the security policy.
• Specify explicitly if personal data are exported to a non-EU country for
processing.

30. 30
PSEUDONYMISED SYSTEM IDENTIFIERS
• Never push IP addresses / device ids to audit logs or analytics systems.
• Create pseudonyms for all system identifiers and maintain a mapping table.

31. 31
COLLECT ONLY THE MINIMAL REQUIRED DATA
• During the user onboarding process collect only the required minimal set of
personal data - with the user consent.
• Do not collect data for the future anticipated use.
• Keep the ability collect more personal data as and when needed.
• Have an expiration policy for each attribute - by default keep no expiry.

32. 32
SHARE PERSONAL DATA WITH USER CONSENT
• Irrespective of the identity federation protocol in use - never share personal
without user consent.
• In non-federation scenarios, when releasing personal data to other
applications via APIs, make sure those applications have recorded the user
consent.
• Let the business applications manage their own consent on how the
personal data are processed at the application level.
• Maintain user consent by attribute by application - with an expiry.
• The IAM system can offload the consent management from each application
- and provide an API to record consent centrally against those.

33. 33
SELF CARE PORTAL
• Provide a portal, where users can login and export their personal data.
– IAM system should only worry about giving an option to export the
personal data it collected from the user.
– IAM system can decide, in addition to the above what other personal
data available to export.
• The portal should provide consent management facility.
– Users can view, update and revoke a consent already provided.
• The portal should have an option execute data subject rights to
– Request to rectify any issues with the personal data.
– Request to restrict processing of personal data.
– Request to delete the account

34. 34
USER OFFBOARDING
• Delete the user personal data.
• Remove the mappings to all pseudonyms to the corresponding user.
• The above will make all the audit logs and analytics anonymous - which is
safe under GDPR.
• Notify all the upstream applications, where the corresponding user’s
personal data already being shared.

35. 35
PRIVACY BY DESIGN ~ PRIVACY BY DEFAULT
• Make sure TLS 1.2 is used to protect all the data in transit with cipher suites
supporting perfect forward secrecy.
• Protect the data at rest for integrity and confidentiality.
• Rely on open standards.
• Follow the best practices defined by Financial APIs working group under
OpenID Foundation to secure APIs.
• Use message level encryption for bearer tokens - while sharing personal
data.
• Follow digital identity guidelines defined in NIST SP 800-63.
• Enable MFA for user login - a must for administrators.

36. ARCHITECTURE GUIDELINES

37. 37
ARCHITECTURE CONSIDERATIONS
• Build an architecture to;
– collect data { transaction | analytics }
– control the usage of data { transaction | analytics }
– store and manage the data { transaction | analytics }

38. 38
GATEWAY PATTERN
• Route your incoming and outgoing traffic
through a set of ‘Gateways’
– API Gateway
– B2B Gateway
– File Gateway
– …..
• Enforce quality of services at the Gateway
– Security
– Analytics
– Governance (mainly data and
runtime governance)

39. 39
APIs
• Single source to access the data and
business processes
• Internal and external APIs
• Ability to expose different kind of
APIs
– Business, application and data
– Usage and analytics

40. 40
STANDARDIZE BUSINESS OBJECTS
• Message/event payloads using schemas
• Classify data
• References to look-up data (registry)
• Enforce usage policies
• Include GDPR headers/fields if required (mandate it)
• Annotate (info for pre/post-process of data)
• Version
• Introduce using APIs

41. 41
ANALYTICS
• Usage data
• Activity logs
• Dashboards for various stakeholders
( including DPO )

42. 42
GOVERNANCE
• Policy bases execution ( not only security policies )
• Workflows
• Observability & surveillance

43. 43
GENERAL (architecture) GUIDELINES
• Iterative architecture
– Segment architecture
• Reuse existing technologies
• Continuous-*
• Use open standards
• Open interoperability
• Event-driven
• Use patterns, templates
more info: https://www.slideshare.net/secret/4rRq0k7fqRkTxs

44. 44
REFERENCE ARCHITECTURE - generic
Analytics
Continuous-*
Security &
Access Management
API / Service discovery
Dev toolsDevops tools
Service router
API Gateway
Core
Microservices
Data
Container(s)
Delivery channels Digital Products
Messaging Channels Integration
MicroservicesExisting Services
Other
Gateways

45. 4545
Continuous-*
Security &
Access Management
API / Service discovery
Dev toolsDevops tools
Service router
API Gateway
Core
Microservices
Data
Container(s)
Delivery channels Digital Products
Messaging Channels Integration
MicroservicesExisting Services
Analytics
Analytics
Analytics
Analytics
Analytics
RUNTIME

46. 46
COMPONENT ARCHITECTURE

47. 47
OPEN TECHNOLOGY http://wso2.com
Build internal and
external developer
ecosystems with an
API marketplace.
Manage identity,
security, and
privacy across
your digital
business.
Make mobile and IoT
devices integral to
your digital business.
Create real-time, intelligent,
actionable business insights
and data products.
Platform enable your digital
business with “micro-services”
and “micro-integrations”.

48. 48
UPCOMING WEBINAR

49. wso2.com
49