Key Components of the gtID# Solution

Creating a gtID# as a unique identifier for all Tech Constituents addresses two major concerns; eliminating errors and redundancies caused my multiple identifiers across systems/applications, and reducing the risk of identity theft for the Tech community.

Key components of the proposed gtID# solution include:

• Generating a unique identifier for every individual who enters into a relationship with Georgia Tech – faculty, staff, students, consultants, contractors, affiliates, etc. This unique identifier will remain with that individual throughout their “lifetime” at Georgia Tech. For instance an individual may start out as a student, return a few years later as a consultant, decide to return to complete his/her Doctorate Degree, and return again years later as a faculty member. Regardless of the association/relationship an individual has with Georgia Tech, he/she will always have/use the same gtID#.
  
  
• Students are assigned a gtID#, which is the student identifier, when his/her application is received. When accepted, the student will use the gtID# number as his/her student identifier for all administrative transactions, activities and services provided by Georgia Tech. (If a student has a previous history with Georgia Tech they will continue to use the gtID# already assigned.)
  
  
• Faculty, staff, and all other Georgia Tech constituents (such as consultants, contractors, temps, visiting scholars, researchers, alumni, Athletic Association and Foundation affiliates, retirees, intensive English participants, ATDC affiliates, SAC program affiliates, spouses, family members, etc.) will be assigned a gtID# upon request from authorized campus administrators.
  
  
• Georgia Tech Administrators must be authorized to access the gtID# Request application. The established security administration process for accessing production systems will be followed.
  
  
• Authorized administrators in each unit will request a gtID# for any individual as appropriate. The assignment of a gtID# constitutes authorization that this individual is entitled to the services appropriate for their title if faculty or staff, or to the type of relationship they have such as visiting scholar. Once the gtID# is assigned the individual can start utilizing appropriate services. This new process will really be beneficial for certain groups such as new faculty. They will be able to activate computer and email accounts, access library resources, and other services such as parking before his/her first real work day.
  
  
• The BuzzCard Center will process all non-student gtID# requests. Banner will be the master repository for all gtID# records. Current BuzzCard holders will not need to have their BuzzCard reissued. All BuzzCards issued after March 1, 2003 will have the gtID# printed on the front of the card.
  
  
• Peoplesoft HRMS will capture gtID# for each employee, keeping specific data elements in sync with Banner.
  
  
• The Data Warehouse will contain the gtID# and restrict use of SSN except where required for federal, state, or officially sanctioned reporting purposes.
  
  
• All campus departments using SSNs as the key identifiers in internal applications should make the appropriate changes to systems and applications by March 1, 2003.
  
  
• All business processes that currently request or use SSNs should review all forms to ensure the request is appropriate, necessary, and in compliance with the Privacy Act of 1974. If SSNs are collected the appropriate disclosure statements must be communicated appropriately.
  
  
• A Social Security Number Policy for the Institute will be established limiting the collection, use, and distribution of social security numbers.
  
  
• All future in-house or third party software cannot be developed or purchased that uses SSN as the key identifier.