Customize Consent Preferences

We use cookies to help you navigate efficiently and perform certain functions. You will find detailed information about all cookies under each consent category below.

The cookies that are categorized as "Necessary" are stored on your browser as they are essential for enabling the basic functionalities of the site. ... 

Always Active

Necessary cookies are required to enable the basic features of this site, such as providing secure log-in or adjusting your consent preferences. These cookies do not store any personally identifiable data.

No cookies to display.

Functional cookies help perform certain functionalities like sharing the content of the website on social media platforms, collecting feedback, and other third-party features.

No cookies to display.

Analytical cookies are used to understand how visitors interact with the website. These cookies help provide information on metrics such as the number of visitors, bounce rate, traffic source, etc.

No cookies to display.

Performance cookies are used to understand and analyze the key performance indexes of the website which helps in delivering a better user experience for the visitors.

No cookies to display.

Advertisement cookies are used to provide visitors with customized advertisements based on the pages you visited previously and to analyze the effectiveness of the ad campaigns.

No cookies to display.

Categories
Articles

Privacy Riskiness for Access Management

On a privacy course I teach for system and network managers I suggest a scale of “privacy riskiness”, the idea there being that if you can achieve an objective using information from lower down the scale then you run less risk of upsetting your users and/or being challenged under privacy law. That scale is very much a rule of thumb, derived by a kind of reverse engineering from various bits of European and UK telecommunications law by assuming that the more conditions a law places on a particular type of information, the more privacy invasive it is.

A recent discussion on access management suggested that a similar rule of thumb for that application might be useful, so here it is, with very much the same caveat that it is derived by reverse engineering from multiple sources of varying authority. Those sources, and the reason I have interpreted them as I have, are in the notes below the table:

Type Example Notes Legally
0 Attributes that do not identify a unique user eduPersonScopedAffiliation 1 Non-Personal Data
1 Indirect identifiers designed for privacy eduPersonTargetedID 1,2,3 Personal Data
2 Indirect identifiers not designed for privacy IP Address 1,2,3
3 Direct identifiers Name, Address 1,2
4 E-mail address & fax number 1,2,4
5 Location information Mobile phone cell 1,5
6 Sensitive personal data Health, race, religion, etc. 1 Sensitive Personal Data

Notes

1. The European Data Protection Directive (DPD) only defines personal data (classes 1-5, DPD Article 2) and sensitive personal data (class 6, Article 8); since it doesn’t mention non-personal data I have put that in class 0.

2. The DPD (Article 2) mentions both information that can itself identify an individual (classes 3&4, sometimes referred to as “direct identifiers”) and information that is unique to an individual but where additional information is required to actually identify the individual (classes 1&2, sometimes called “indirect identifiers”). The DPD doesn’t distinguish between those types, but the Article 29 Working Party’s Opinion on the Concept of Personal Data does, and suggests that in some cases (e.g. Example 17) indirect identifiers may represent less of a privacy risk than direct identifiers. Case law across Europe differs on whether IP addreses (the only indirect identifier to be mentioned in court cases, as far as I know) are personal data or not, but this does not affect their position in the riskiness scale.

3. The Article 29 Working Party Opinion also recognises the difference between indirect identifiers that deliberately make it hard to make the link (e.g. using “cryptographic, irreversible hashing”, p.20) and those that do not.

4. The e-Privacy Directive (Article 13) awards additional protection to e-mail and fax addresses by requiring that consent be obtained before these can be used for direct marketing; for postal addresses the law allows an opt-out regime where marketing can be sent until the recipient objects.

5. The e-Privacy Directive (Article 9) requires prior consent, and the ability to temporarily opt-out, of processing of location data. Since these requirements are specified in greater detail than for e-mail addresses, I have put them in a (slightly) more privacy-invasive class.

By Andrew Cormack

I'm Chief Regulatory Advisor at Jisc, responsible for keeping an eye out for places where our ideas, services and products might raise regulatory issues. My aim is to fix either the product or service, or the regulation, before there's a painful bump!

Leave a Reply

Your email address will not be published. Required fields are marked *