Social Security Number Data

Issue Description:
The University has mandated eliminating collection and use of SSN as a primary identifier except where a legitimate business need exists. The SISS Office must secure the data, making it unavailable to all but the small number of users across functional areas whose business practices require access to SSN data.

When Dr. Trask issued the Social Security Number policy in September 2003, SISS had over 1300 users able to view the SSN. Of those users, approximately 150 had the ability to update that data. Our solution reduces to fewer than 100 the number of users having any access to the full social security number.

Our first step in securing the SSN via the application relied on newly-delivered security functionality in PeopleSoft. DDA (Demographic Data Access) security allowed us to mask all but the last 4 digits of the SSN on certain pages, and we applied that security immediately to search results throughout the system.

This left us the remaining tasks of:

  1. Establishing a SISS-specific policy for reasonable use while following the intent of the university mandate;
  2. Completing the job of securing the application, not just in the search results but in the Bio/Demo data pages as well;
  3. Analyzing incoming and outgoing data for SSN occurrence and if present, determining whether there is a “compelling need.”

Reasonable Use:
Social security numbers will continue to be collected by Admissions offices for the benefit of Financial Aid users and for the purpose of matching records to incoming data from sources including but not limited to: electronic and paper applications, academic testing agencies, recruiting services.

Some users in Admissions, Financial Aid, Student Financials and Student Records will have the ability to view and update the SSN. Some will have the ability to report against SSN data. Some specific reports requiring SSN have been identified to be: Pell, NSLDS, National Student Clearinghouse, 1042S, 1098T, and most student loan reporting going out to lenders.

For the sake of establishing a starting point as well as standardizing the process of assigning this security, the SISS security administrator will reduce the number of users with “SSN view/update security” down to the 93 who currently have correction rights to the Bio/Demographic data. The rationale is that these users are already in a position of trust. We’re also going to work with those departments to determine whether any additional reduction in those numbers can be accomplished.

For reporting, we are segregating all tables containing SSN into a distinct group for which security can be assigned on a case-by-case basis. We are communicating the University policy to departments and prompting them to begin the process of removing SSN data from reports.

Table access will be much more tightly controlled than page access because a user could produce a report with thousands of social security numbers along with supporting personal data. This poses a greater risk to the confidentiality of SSN data than someone who can access the data one record at a time.

We propose limiting table access to key users in the central and SISS offices, with a small number of users distributed out among the school offices. This would allow for tighter controls with a reasonable fallback. If the local user responsible for this data was unavailable at a critical time, the Registrar’s Office or SISS Office could act as backup and provide the service.

Securing the Application:
In order to lock down access to the SSN via the Peoplesoft pages, we are cloning an existing page to create a new page for the purpose of entering and updating this data. This allows us to separate out that activity from all other data entry activity and to more easily limit user access. The “power users” mentioned above will be granted specific rights to this page and will be responsible for that data in their respective offices. This allows other permanent and temporary staff to update all other Bio/Demographic data without ever seeing the SSN. We will be able to easily report on users who are updating the data and we’ll continue to have an audit record on specific activities.

Incoming/Outgoing Data:
We have been in contact with all recipients of data extracts containing SSN and we are already engaged in removing it from those extracts we have so far identified. There are a few recipients who are requesting that we continue to provide SSN data until certain data dependencies are worked out across units. In cooperation with the IT Security Office we established a procedure for documenting and evaluating these requests. IT Security will follow up with those offices.

In Conclusion:
The SISS Office met the University’s June 30, 2005 deadline in restricting access to the social security number by either masking or removing it in every context within our control. The implemented SSN policy will be closely monitored by the IT Security Office.