1

GDPR classifies data into Non-personal, Personal and Sensitive personal. Sensitive personal is further broken down to Genetic and biometric, Racial and ethnical, Religion and Philosophical etc.

Coming to implement a new Active Directory I want to present my stakeholders with the different options that they have, with GDPR in mind.

Reading the Microsoft white paper I cannot see mapping of attributes to the GDPR classifications, or a bottom line of how to implement any of the 3 approaches.

I would ideally like to see something along these lines:

  • to class as non-personal: 1. use employee ID in userPrincipalName and sAMAccountName; 2. only use corporate mobile phone in homePhone/otherPhone etc.; 3. use office address in streetAddress, targetAddress etc.
  • avoid these to class as sensitive: 1. biometrics (unless stored on the device such as Windows Hello); 2. distribution lists for religion communities (e.g. prayer room, even if multi-faith)

There are of course extension attributes which will have to be considered on case by case basis.

Has anyone been through this process and can share from their work?

Improve this question
2
  • 1
    There is nothing special about AD when it comes to GDPR. General principles such as data minimization, lawful basis for processing and a risk-based approach to what data you store, they all applies as usual. It's probably better to start with what you want to use the AD for, and see if any of the data you want to store causes undue problems. The rest you secure to an appropriate risk level (here comes the "talk to a lawyer" bit).
    – Geir Emblemsvag
    Commented Sep 18, 2019 at 12:19
  • Thanks @GeirEmblemsvag I appreciate same challenges apply to other directory services and even other databases. As AD dominates the enterprise market, I thought that a similar exercise at a more practical level (i.e. attributes) must have been done before. Also completely agree with the 'talk to a lawyer' bit, of course no liability is sought who'd be so generous as to share their work
    – aquaman
    Commented Sep 18, 2019 at 12:30

1 Answer 1

Reset to default
1

Exactly as Geir E. said in the comment, have data minimization in mind. Don't use personal data unless it is explicitly needed for something. The whole AD part can be completely non-personal and there is no reason not to do so.

For user names you can use many alternatives not implying the real name of a person, like employee ID or a derivation of department/team/job scope or anything like that and employee ID.

As employee IDs are more and more often used in practice, doing so will actually simplify the whole employee-management in the end, for most situations.

Employee IDs can be used in AD just are they are widely used in work time counting systems, HR systems, ERP systems and so forth.

You you definitely can classify AD as non-personal, even if you currently use something personal. Renaming AD accounts has minimal implications and does not affect functionality overall except for the part when the user must login with its new ID.

In our company case, since you requested if people have been through this process, we use employee ID for AD, document encryption system login, security system login, ERP. the only name-based thing remaining are the e-mails, which are completely unrelated to AD.

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .