The idea is to propose features that would help us address EU GDPR regulations. I also think it could help (at least me) some background, resumed documents on the topic.
There is a mapping of GDPR-requirements with ISO-27k controls at http://www.iso27001security.com/ISO27k_GDPR_mapping_release_1.pdf
As expected it’s quite difficult and doesn’t make a lot of sense (some requirements in GDPR just map to lots of ISO controls because of the rather high level specifications of GDPR).
We plan to expand our Asset Flows (Asset Management / Data Asset Analysis) feature that allows you to describe what controls, people, third parties are involved in the handling of data over its lifecycle. This is one of many other features we can include!
The aim of this particular feature is to:
- perform an Impact Assessment (Rec.84, 90-94; Art.35) and the controller responsability to implement controls, review them,etc (Rec.83; Art.32)
- this could be used to submit a report to the EDPB (Rec.84, 90-94; Art.35)
- report in detail all legal aspects of each data asset you own, also warn when fields are incomplete (meaning the analysis is incomplete and therefore potentially illegal)[/details]
On the index show as a table on top of each asset analysis this data that comes from the Asset Management / Asset Identification the following fields:
- description
- liabilities
- If GDPR settings are on or off (keep reading)
- include on the “management” button the “Reviews” for this asset, this data comes from Asset Management / Asset Identification
On each stage add.ctp (edit form), include the following below controls:
- “Policies” where the user can select policies (all types of policies in one single drop down, multiple select)
On the current “stages” index, include missing columns
- “Policies” on the right of the column “Controls”
- Display the “Description” field on the right of “Projects” (this field is an input on for form but is not displayed on the output table)
- change the layout of the data so you can display multiple controls, policies, etc with their status, same as we have in the Compliance Management / compliance analysis module.
- Enable advance filters to be able to find, report, etc data.
All the following input fields will be OPTIONAL (there will be an “GPDR Settings” button under “Manage”, if activated with a checkbox tabs will be used to input this data
- Tab: Role
- Who is the processor, who is the controller representative (one or more system user). If they are not the same, then let the user define what Agreement exists in between them Rec.81; Art.28(1)-(3)
** Controllers must have a privacy and ethics policy (Rec.74; Art.24)
** If a controller asks a processor to do stuff, there must be a legal binding document - Rec.81; Art.28(1)-(3) - Data Representative (Rec.80; Art.4(17), 27 - which seems to be needed only if the crontroler is not EU based) that basically is a user account in eramba
- “Data Owner” role where we can select one or more user accounts. this role (and the liabilities one) could be useful for workflows later.
- DPO role (Rec.97; Art.37)
- Tab: Geographies
- Enable a checkbox and description if “Data crosses EU borders” (within the corporation or outside). Some countries will be whitelisted by the EU (Rec.103-107; Art.44, 45)
- This could enable additional fields on the data flow stage “Transfer” (validating where to is going)
- The EU has list of OK third party countries (Adequacy Decision) - Rec.103-107; Art.44, 45
- Binding Corporate Rules (BCR) a mechanism for conducting lawful Cross-Border Data Transfers within a corporate group - Rec.108, 110; Art.4(20) 46(2)(b), 47
- You must specify under which category transfer of data to third party countries this is applicable: BCR, Code of Conduct (Rec.108; Art.40, 41, 46(2)(e)), Certifications (Rec.108; Art.42, 43, 46(2)(f)), Ad Hoc Clauses (Rec.108; Art.46(3)(a), (4), 63), Administrative Arrangements (Rec.108; Art.46(3)(b), (4), 63), DPA Clauses (Rec.108-109; Art.46(2)(d), 64(1)(d), 57(1)(j), (r), 93(2)), Model Clauses (Rec.81, 108-109; Art.28(6)-(8), 46(2)(c), 57(1)(j), (r), 93(2)), Subject Consent (Rec.111; Art.49(1)(a), (3)), Contract in between Subject & Controller Rec.111 Art.49(1)(b), (3), Controller and Third Party (Rec.111; Art.49(1)(c), (3)), Public Interest (Rec.111-112; Art.49(1)(d), (4)), Legal Claims (Rec.111; Art.49(1)(e)), Vital Interests (Rec.111-112; Art.49(1)(f)), Public Data (Rec.111; Art.49(1)(g), (2)), Government Needs (Rec.111; Art.49(5)),
- Tab: Data Classification
- “Personal Data” (Art.4(1))
- “Sensitive Data” (Rec.10, 34, 35, 51; Art.9(1))
- Criminal Offences (Rec. 19, 50, 73, 80, 91, 97; Art.10)
- Pseudonymous (Rec.26, 28-29, 75, 78, 156; Art.4(5), 6(4)(e), 25(1), 32(1)(a), 40(2)(d), 89(1))
- Data concerning health Rec. 35, 53-54; Art.4(15), etc.
- Tab: Data protection principles
- what retention characteristics applies for this data Rec.39; Art.5(1)(e) and if the data can be identified and deleted upon request. Checklist that conforms if data will be stored for statistical reasons Rec.39; Art.5(1)(e)
- What mechanism are in place to trigger “right to be forgotten”
- enabling GDPR eramba will force the creation of controls for each stage to address security on each phase of the data. Rec.29, 71, 156; Art.5(1)(f), 24(1), 25(1)-(2), 28, 39, 32
- Tab: Lawful base to collect data
- User consent (Rec.32, 42, 43; Art.6(1)(a))
** How consent records are stored and available to the regulators if needed Rec.42; Art.7(1) and how they can be removed if the subject wishes to do so Rec.42, 65; Art.7(3) - Contractual agreement (Rec.44; Art.6(1)(b))
- Legal (Rec.45; Art.6(1)(c))
- Vital (Rec.46; Art.6(1)(d))
- Public interest, meaning government stuff (Rec.45; Art.6(1)(e)),
- Legitimate interest … no idea how to describe this one Rec.47, 48; Art.6(1)(f)
- Other legitimate interest introduced by the member state Rec.40; Art.6(2)
- Criminal stuff Art.10, 23(1)(j)
- Input fields that describe why the data is needed - Rec.50; Art.5(1)(b) , Rec.39; Art.5(1)(c)
- If data needs to be kept up to date, what process is used to do that - Rec.39; Art.5(1)(d)
- Input fields from our Policy module to choose appropriate documents for:
- consent (Rec.32; Art.4(11), 6(1)(a), 7 - the text shown to the person that owns the personal data)
- Privacy (Rec.78; Art.25)
- Incident Policy what policy will be used to declare and handle incidents related to this asset (Rec.73, 85-88; Art.33)
- Allow to download a PDF that summarises all (under “Manage”)
Incident Module
You can link an incident to a Data Asset, not juts a risk. this would allow users to link incidents to Data Assets and warn when there is a relationship - Art.4(12) / Rec.73, 86-88; Art.34
@sejr you had an idea to include notifications, can you frame them in the context of this feature?
Everyone - just add replies to this post, if we see they could be brought in as features i’ll update this post with them.
1 Like
We have completed the review of the spreadsheet that describes each item of the directive, we made sure that for each item we evaluate:
1- if the item could be managed with a software feature
2- if the item is a statement where software cant do much, for example “the penalty for infringement is 20m”
This exercise should provide all functional requirements for this feature, which we have documented on the post above. We’ll now think how to put that in design and usability terms to start building the software. We plan to have this completed once we finish workflows and clean the backlog (as you have seen we have accumulated many smaller things).
The spreadsheet is incredibly useful to understand whats coming up -we’ll also document all in theory documents.
1 Like
Felt like this fits better here than the other, more recent GDPR discussion post. Thought this type of data flow diagram might is a great idea and way to visualize data flows: https://www.linkedin.com/pulse/gdpr-data-flow-mapping-approach-tim?trk=v-feed&lipi=urn%3Ali%3Apage%3Ad_flagship3_feed%3ByGlQ45Un4znYk%2BqDc5dDPw%3D%3D
2 Likes
Agreed - and we are going that direction.
We are starting to complete the feature, we are doing tests and trying to improve details of usability. We think its going well and NEXT WEEK (the last week of August) we’ll make release.
We do expect modifications as all of you start using this feature and provide suggestions , ideas, Etc. Is really quite complicated to “show” information since there is a lot of data … each analysis has many many fields so we are testing a new UX where filters and counters are used to display items (otherwise if we would show them all on the index they will never load as there are a million and a half queries)
I’m not able to upload the PDF but i leave you a screen shot of how it looks
We just completed a review once again of every item from the law to make sure is covered by eramba where possible.
By the end of this week we hope (not plan) to finish this feature and release it.