Social Security Number Issues

Social security numbers were initially included in the data collection for purposes of CORI checking. Since then, the requirement for SSN has been dropped, making the collection of the members’ SSN optional at best. Many members are validly wary of providing their SSN, particularly for long-term storage. It also causes some concern for Executive Committees and administrators that are being trusted with this information. Your unit should decide whether to collect and store SSNs.

Am I required to collect and store SSNs?
The short answer here is no. It's no longer required for it's original purpose, so unless your unit has an overriding concern or need for the SSN, don't store it. If you're unsure about future need, you can always store the SSN on the member's paper application which is much easier to safeguard in a locked file cabinet than the database which is intended to be portable and used by many.

I have a password on my database, isn't it protected enough?
There is no such thing as unbreakable protection, particularly with databases. Even if your database is password protected, hackers could theoretically break the code. The password also encodes the database, which provides an additional layer of protection, but again, given enough time and resources, it can be hacked.
Given the nature of the MRC (emergency management), it stands to reason that several people will have and should have the password to the database. In many units, several copies of the database are distributed to the executive committee members to ensure continuity of response in  the event of an emergency. This is a good practice, but it extends the range of possible exposure, and members should be aware of this.

Why can’t I see the SSN on screen? The fields I used to enter it appear empty.
The system protects against on-screen display of the SSN by ‘masking’ the SSN data entry process. Three fields are provided to enter the three ‘parts’ of the SSN. When you click on  the INPUT button,  the system ‘assembles’ the full SSN and stores it in the SSN field in the table. It then displays “***-**-****” in the SSN field to show you that it has an SSN stored. This is so that the SSN isn’t visible on screen for casual observers to see. The SSN is, however, printed on member files and stored in the member table.

How do I get rid of SSNs that are already in the system?
The SSN field is protected to safeguard against cut/paste operations, so you can’t access it directly. However, you CAN overwrite the field by entering zeros in the data entry area. The ‘new’ SSN (000-00-0000) will replace the old one, and although it will still display as “***-**-****”  

Where does the SSN actually appear? I don’t see it on any reports.
The SSN was originally stored as a function of CORI checking. The CORI bulk report generates the member last name, first name, DOB, and SSN. This is the only report that will display the SSN. This report will be discontinued in the next revision of the MRCDB since it is no longer applicable for CORI checking.