Educause Security Discussion mailing list archives

Re: Email address/account practices for college employees that change positions


From: "Pfaff, Anthony W" <anthony.pfaff () UCDENVER EDU>
Date: Mon, 2 Nov 2015 18:47:37 +0000

This is a conversation CU Denver | Anschutz is starting to broach as well.  Our current practice in cases where the 
transfer is to another position within CU Denver | Anschutz is to allow the individual to keep access to all email, 
while blocking access to some other sensitive IT resources until specifically requested to do otherwise.

Two reasons I can currently think of to keep this practice are:

1)      A number of emails exchanged between an employee and their campus might not specifically pertain to job duties 
(e.g., benefits, retirement, communication with Ombuds, etc.).  Having an employee parse manually through a user’s 
account to remove only sensitive emails would be quite cumbersome and fairly intrusive.

2)      What looks like a “department change” can often be a false alarm.  An individual getting a promotion might move 
to a higher-level administrative organization within the same part of the org tree, and while they are technically 
changing departments, their responsibilities may instead be growing, while encompassing their previous ones.

It was previously discussed to actually assign individuals multiple email addresses to get around these issues, but 
this was not adopted given the same concerns Mark mentioned.  To actually handle the concerns brought up, some of our 
departments have adopted the approach Frank brings up, where they have a generic account for specific business 
processes.  We are also fully in the cloud with Office 365 at the moment, and Microsoft has provided licenses to us 
which give access to their rights management and mobile data management suites.  We are currently investigating the use 
of their rights management and mobile data management solutions to possibly revoke permissions or actually delete 
sensitive email messages from devices.

Anthony Pfaff | Lead IdM Software Engineer
Middleware and Identity Management
303-315-0057 | anthony.pfaff () ucdenver edu<mailto:anthony.pfaff () ucdenver edu>
[oit_h_clr]

From: The EDUCAUSE Security Constituent Group Listserv [mailto:SECURITY () LISTSERV EDUCAUSE EDU] On Behalf Of Jones, 
Mark B
Sent: Monday, November 02, 2015 11:42 AM
To: SECURITY () LISTSERV EDUCAUSE EDU
Subject: Re: [SECURITY] Email address/account practices for college employees that change positions

The affiliations a person can have with our institution can be very complex.  We have had people who were concurrently 
a ‘student’, a ‘employee’, and a ‘resident’.  We regularly have people who transition from ‘student’ to ‘resident’ to 
‘faculty’.  We have ‘employees’ who are concurrently in all other roles and transition to and from all other roles.  We 
have people who deal with all manner of sensitive information including personal health information.

For the last fifteen years we have given all of these people, in all of these situations, only one email address.  If 
we have ever had any issue, relating to a person retaining access to their mail after an affiliation change, I’ve never 
heard about it.  My advice is to keep it simple.  One person, one address.

From: The EDUCAUSE Security Constituent Group Listserv [mailto:SECURITY () LISTSERV EDUCAUSE EDU] On Behalf Of Katie 
Newth
Sent: Monday, November 02, 2015 12:17 PM
To: SECURITY () LISTSERV EDUCAUSE EDU<mailto:SECURITY () LISTSERV EDUCAUSE EDU>
Subject: [SECURITY] Email address/account practices for college employees that change positions

Hello everyone.

We are in the process of working through procedures on handling different scenarios of employee transfers within the 
institution.

Some concerns we have heard include:

  1.  Employee keeping or losing access to sensitive docs within their current email account if they move to position 
across campus with no need to access those documents (we are okay with cleaning out their email accounts and moving old 
emails to another location)
  2.  Future incoming emails from individuals that may not know the person moved positions - concerns around: the fact 
that they should no longer have access to contents of email (such as reports or other information not pertinent to new 
position), the email may not get forwarded to old department for replacement person to handle (once a year reports, 
etc.)

What do you all practice in terms of email address for a staff position that is moving from one department to another, 
especially those moving from a sensitive position to a less sensitive position (i.e. HR)?  Do you allow them to keep 
the same email address (ours is currently firstname.lastname@emaildomain<mailto:firstname.lastname@emaildomain>) or do 
you change it?    How about those individuals that may be a staff member and a PT faculty member?  If they are no 
longer in a staff role, do you make them change email addresses as well when they no longer should have access to that 
information going forward?  If you do change it, do you feel it causes a drop in employee morale when they no longer 
fit the normal naming scheme?

Also, if you have both short term and long term solutions, we would love to hear those as well, especially short term 
solutions.  We have some ideas around long term which include adding additional domains to separate some of this, but 
at this time we are under one domain and it would be a large project that would require buy-in.

Thanks for your feedback!

Katie Newth
Information Security Analyst
Aims Community College
5401 W. 20th Street
Greeley, CO 80634
970.339.6395 (Office)
katie.newth () aims 
edu<https://urldefense.proofpoint.com/v2/url?u=http-3A__katie.newth-40aims.edukatie.newth-40aims.edu&d=BQMFaQ&c=6vgNTiRn9_pqCD9hKx9JgXN1VapJQ8JVoF8oWH1AgfQ&r=jgMu8DNgV_dycz0rYwkNbEQq36F0BI5_Zpblz7C5LhM&m=eUy0kckjp8X6QnXAeL16nOA_ri_s1EBi13sdgFmiXuo&s=mVQnkz10IPzG14W9MdN1R8lB1oXPM511ZYdfPTpKjCo&e=>


IT staff will never ask you for your username and password.
Always decline to provide the information and report such
attempts to the help desk (x6380).


Current thread: