POLICY FOR PURGING USERIDS ACF2 is the security software used with VM/CMS; MVS batch and TSO; CICS including Library NOTIS, FAMS, and SMARTRD; and IDMS including FAMS, FRS, HRS, SHD, BRS, ADM, and SIS. Among other things, ACF2 maintains userids and associated passwords for these users. To insure the integrity of ACF2, the following policy will be enforced. Userids will be removed from ACF2, and User Account Management System (UAMS) will be updated accordingly, for any of the following 3 conditions: never used, user termination, or extended inactivity. 1) NEVER USED: Any userid that has not been accessed or logged onto, at least one time, during the first 30 days after being created will be removed from ACF2, and User Account Management System (UAMS) will be updated accordingly. 2) USER TERMINATION: If "official" notification is received that a user is no longer associated with UK, the userid will be SUSPENDED. This action does not remove the ID from the database, but merely sets an indicator within the ACF2 database preventing the user from logging on to the userid. If there are ACF2 access rules in place which grant other users access to the departing user's data, those rules will be left in place for 30 days. 30 days after the userid has been SUSPENDED, those access rules will be deleted. If continued access to the data is necessary, then that data should be moved. This includes both VM/CMS minidisk files and MVS datasets. If other users need access to the departing user's data, and no access rule is in place, a rule can be created, with proper departmental approval, to allow access for 30 days. 30 days after the rule was created, any access rules for that user's data will be deleted, and any remaining disk data for that user will be archived to tape. The tape archives will be kept for 18 months, during which time the userid will remain in User Account Management System (UAMS) and on ACF2 in SUSPENDED status. If the user returns, the userid can be reinstated, and the archived data restored. If another user needs the archived data, it can be restored to another userid, with proper approval. After 18 months, the archived data will be deleted, and the userid will be removed from ACF2, and User Account Management System(UAMS) will be updated accordingly. Although the condition should not exist, it should be noted that when the userid is deleted from the database, any datasets that still exist, disk or tape, that use the same high level prefix as the userid being removed, will be deleted. Any files deemed as "permanent" should be copied to a high level prefix established specifically for that department that is not related to a userid. 3) EXTENDED INACTIVITY: If a userid has not been logged onto for a period of 60 days (basically 2 months), the userid will be CANCELLED. This action does not remove the ID from the database, but merely sets an indicator within the ACF2 database preventing the user from logging on to the userid. If there are ACF2 access rules in place which grant other users access to the inactive user's data, those rules will be left in place for 30 days. 30 days after the userid has been CANCELLED, those access rules will be deleted and any remaining disk data for that user will be archived to tape. If continued access to the data is necessary, then that data should be moved. This includes both VM/CMS minidisk files and MVS datasets. The tape archives will be kept for 18 months, during which time the userid will remain in User Account Management System (UAMS) and on ACF2 in CANCELLED status. If the user becomes reactivated, the archived data can be restored. If another user needs the archived data, it can be restored to another userid, with proper approval. After 18 months, the archived data will be deleted, and the userid will be removed from ACF2, and User Account Management System (UAMS) will be updated accordingly. Although the condition should not exist, it should be noted that when the userid is deleted from the database, any datasets that still exist, disk or tape, that use the same high level prefix as the userid being removed, will be deleted. Any files deemed as "permanent" should be copied to a high level prefix established specifically for that department that is not related to a userid.