GOSHEN COLLEGE PRIVACY OF ELECTRONIC FILES AND COMMUNICATIONS

The following guidelines shall serve to protect the privacy of the Goshen College community.

1. Goshen College computing resources are provided for educational and administrative purposes. We recognize that computing resources will be used for storing and communicating many types of information, including that of a personal nature. Members of the College community are expected to be judicious in their use of computing resources. These resources should never be used for personal for-profit gain, theft, fraud, invasions of privacy, distribution of illegal materials, or distribution of copyrighted or licensed materials without appropriate approval. Individuals bear the responsibility to avoid libel, obscenity, undocumented allegations, attacks on personal integrity, and acts of harassment.

2. Files stored on an individual's computer or on a shared central system or file server are considered private, to be viewed only by the original creator of the files, unless otherwise so designated by the creator. Access to files by others is prohibited without just cause. (See section 5 below.)

2a. Faculty and staff should take steps to ensure that documents necessary to the operation of the College are available to those that may require them.

3. Electronic communications and messages (such as e-mail) are considered private, to be viewed only by the original sender and designated recipient(s). Access to messages by others is prohibited without just cause or permission. (See section 5 below.) We encourage individuals to reinforce this for sensitive files and messages by flagging them as confidential.

3a. As a matter of principle and ethics, individuals bear the responsibility for assuring that e-mail messages, including attachments and previous appended messages, are forwarded only to parties whose interest is consistent with the purpose of and intent of the previous correspondents. If in doubt, obtain the consent of the original correspondents before forwarding.

4. Members of the Goshen College community should be aware of the following considerations:

4a. Data storage and communications are not perfectly secure. There are software and physical limitations that can compromise security. ITS tries to minimize such exposures, but the risks exist.

4b. Mail delivered outside of the College is notably insecure and should be treated like a postcard. Individuals may redirect (forward) their electronic mail to another Internet site off-campus. Unless you know that the intended recipient of an e-mail message has not redirected mail to an off-campus site, you should assume the possibility that others may see the content of the message.

4c. Deletion of files or e-mail messages does not guarantee the inaccessibility of those files and messages. Centrally maintained file-storage devices and mail systems are archived to portable hard drives regularly. These backup devices are stored in multiple off-site locations. Thus, even deleted files and email may be available from backups taken months or even years earlier.

4d. Privacy depends upon individuals keeping their password secure. Anyone using Goshen College systems must have difficult-to-guess passwords and must not share his or her password with others. Guidance for choosing a password is available on our Secure Password Policy page.

4e. Many off-campus Internet sites may record information you provide and divulge this to others without your prior consent. In some circumstances, information about you, your activities on the remote site, and information about your computer, may be recorded without your knowledge. Some remote Web sites may store information on your computer in the form of hidden files or "cookies." Caution and prudence are advised when providing any information you would consider confidential to unknown third parties.

5. Access to another individual's electronic files and e-mail is permissible only if there is just cause in the following situations:

5a. If the creator of files, or the sender/recipient of electronic mail messages, has granted specific permission for another individual or individuals to view designated files and messages.

5b. In the event of a significant electronic mail system software problem that prevents automatic delivery of electronic mail, e-mail message headers must be read by authorized ITS staff to direct e-mail to the intended recipients.

5c. In cases of suspected violations of ITS policies, especially unauthorized access to ITS systems, the administrator of the ITS system may authorize detailed session logging and/or limited searching of user files to gather evidence on a suspected violation. Illegal, irresponsible, or unethical activities may result in loss of privileges or penalties consistent with the judicial procedures and policies of the College.

5d. In the event of a medical emergency involving a member of the College community which renders them unable to access files or messages considered essential for the continuation of College business, another individual may access the individual's electronic files and communications under the procedures set forth in section 6 below.

5e. In the event of a need-to-know emergency (suicidal or homicidal threat), access to an individual's files or messages is permitted, following the procedures outlined in section 6 below.

5f. In the event that a local, state, or federal law-enforcement authority in the investigation of a crime, civil litigation, or regulatory proceeding produces a subpoena, discovery request, or warrant granting access to files or messages, following the procedures outlined in section 6 below.

5g. In the event of a financial or legal audit, following the procedures outlined in section 6 below.

5h. In any other instance, no access is granted to an individual's electronic files or messages without prior review and approval by the appropriate body as indicated in section 6a below.

6. Emergency access to another individual's electronic files and messages is granted only under conditions noted in section 5 above.

6a. Before invoking any such procedure, the circumstance creating the need for access shall be reviewed in a timely fashion, access shall not take place without approval, and specific procedures and strictures may be recommended for each circumstance. The persons involved in the review and approval process will vary depending upon the individual involved:

- The Provost will assume review and approval responsibility in cases involving a faculty or staff member.

- The VP of Student Life will assume review and approval responsibility in cases involving a student.

- ITS will work with the individuals mentioned above to determine if the needs of the College or third party requesting access outweigh the privacy needs of the individual.

6b. A neutral third party (not the person's supervisor, adviser, or teacher) shall examine files and messages on the individual's computer, mailbox, or file-server space and provide only the specifically requested file(s) or message(s) to the requester.

6c. The student, staff, or faculty member will be notified that access has been granted to his/her files or messages unless there is sufficient and compelling reason not to have done so.

6d. No other files or messages may be copied, transferred, or forwarded.

7. The ITS personnel charged with the administration of the College's computing systems and file servers take their obligations to protect individuals' privacy very seriously. The professional standards consistent with positions that require select individuals to have access to personal and sensitive information are strictly enforced. In accordance with general College policy, inappropriate use, access, or sharing of confidential information is grounds for summary discharge of employment.

8. Goshen College has procedures, protocols and training protocols for employees to optimize privacy and security of financial transactions and personal information in compliance with the Gramm-Leach-Bliley Act and Family Educational Rights and Privacy Act (FERPA).

9. These policies are subject to change with prior notice as may be reasonable under the circumstances.

JENZABAR SECURITY PROCEDURES

Jenzabar information systems are an integral part of the mission of Goshen College. The college has made a substantial investment in human and financial resources to obtain and manage these systems. The following procedures have been established to protect this investment and the good reputation of the college; to develop data stewardship to safeguard the information contained in these systems; and to enhance the fulfillment of the mission of the college.

Information Technology Services (ITS) Data Systems staff are responsible for the administration of these security procedures, in accordance with all college information policies dealing with security, access, and confidentiality of college records.

Statement of responsibility

All users of Jenzabar, Jenzabar CampusWeb, and applications that depend on Jenzabar data (GC Online) are required to comply with these security procedures.

ITS (Information Technology Services) responsibilities

ITS shall be responsible for the administration of all access controls for Jenzabar. ITS will process adds, changes, and deactivations to user accounts upon receipt of a written request from the end user's supervisor or manager. (See sections titled Request for user access process and Access deactivation process.) Requests to add or change access must include all required approvals for the appropriate level of access. Requests to deactivate access may be processed by an oral request from Human Resources prior to the receipt of the written request. Data Systems staff will periodically run scripts that monitor employee status to ensure that former employees are deactivated.

 Employee Responsibilities

An employee who uses Jenzabar or applications that depend on Jenzabar data shall:

Ensure that all Jenzabar access requested and used is for professional reasons and they are required for their productivity.

Use and protect their own account passwords and privileges, and not share those with other employees or non-employees.

Be responsible for the content of all Jenzabar data that is placed over the Internet, sent through email or passed to other departments for college use.

Know and abide by all college information policies dealing with security and confidentiality of college records.

Avoid transmission of non-public Jenzabar information. If it is necessary to transmit non-public information, employees are required to take steps reasonably intended to ensure that information is delivered securely to the proper person who is authorized to receive such information for legitimate college use.

Supervisor and manager responsibilities

Supervisors and managers shall:

Ensure that all appropriate personnel are aware of and comply with these security procedures.

Provide appropriate data stewardship in their areas of responsibility.

Work with the Data Systems staff to create and validate proper authorizations for Jenzabar data access for current and new employees.

Create appropriate control practices, standards, and methods designed to provide reasonable assurance that all employees observe these security procedures.

Provide appropriate support and guidance to assist employees in fulfilling their job responsibilities under these security procedures.

HR (Human Resources) responsibilities

HR will notify ITS of employee transfers and terminations in a timely fashion. Involuntary terminations will be reported concurrent with the termination.

 Module Owner responsibilities

Data stewardship

Data stewardship has as its main objective the management of the college's data assets in order to improve their usability, accessibility and quality. This is accomplished through the role of the departmental module owners, who have planning and policy level responsibility for data within their areas, and management responsibilities for defined segments of the institutional data. In the simplest terms, the data stewards could be said to be the owners of the data. Ultimately, data stewardship is the responsibility of departmental directors and their designates, in conjunction with ITS staff.

It is the module owners responsibility to develop consistent data definitions, develop and adhere to data standards created by the institution, document the business rules of their area, monitor the quality of the data input and output from the Jenzabar systems they use, define security requirements, work with other module owners on integration requirements, and communicate critical uses of data on which other departments depend. As data are developed, the module owners assure that entry and access of the data is appropriately managed. This shall include the classification of all forms, reports and all other forms of access in which this data is expressed.

There shall be a module owner designate for each Jenzabar module in use at the college. Currently these include: Admissions (AD), Advising (AV). Business Office (BU): General Ledger and Accounts Receivable, Development (DE), Financial Aid (FA), Human Resources (HR): Payroll and Personnel, Registrar (RE), Student Life (SA), Tasklist Security (TL). The college also maintains and develops custom applications that are designed for and integrated with Jenzabar which also require data stewardship, GC Online, photoID database and online timecard.

Oracle security requirements for Jenzabar

Security roles

Jenzabar security is designed and implemented based on inherent characteristics of Oracle database security, including password management, object privileges, security roles, and grants. Jenzabar maintains security classes that enable Oracle roles containing specific object privileges. These security classes allow the college to implement a distributed security model based on security class ownership of specific Jenzabar functionality and data. The Module owneror a designated data steward shall be the security class owner who controls all access requests for the security class.

Each Jenzabar module and functional area shall design a set of security classes which define all forms used within their module or area and the access type of either Query (view only) or Maintenance (adds, changes, inserts, and deletes). In addition to Oracle database security implemented in Jenzabar security, some of the modules provide system specific security at the form level. This allows the college to maintain security by fund and organization code, employee class code, and/or salary range. Details on the design and definition of Jenzabar security are available in the Jenzabar Technical Reference Manuals.

Security classes can be designed based on the following access types:

Administrator, Maintenance accessan administrator with global access to tables and forms for administration purposes in a given module, allows view and change (updates, inserts, and deletes)

Internal user, Query accessa selection of relevant forms, allows view only

Internal user, Maintenance accessa selection of relevant forms, allows view and change

External user, Query accessa selection of relevant forms for individuals outside of a given functional area, allows view only

External user, Maintenance access a selection of relevant forms for individuals outside of a given functional area, allows view and change

Student user, Maintenance accessa limited selection of relevant forms for data input

In general, a user may have multiple security classes assigned to him/her, rather than developing a custom security class to meet the needs of an individual, or sporadically adding individual forms to a given user account to create a completely custom profile for each person. For example, the gift processing department manager in Advancement may need the External user, Query access type for budget forms to review the department's budget; the Internal user, Maintenance access type for Advancement gift processing to assist with inputting gift data; and the Internal user, Query access type for Advancement for donor-related information to see but not modify relevant information related to donors.

User accounts

To use the Jenzabar client software or Jenzabar CampusWeb a user must have an Oracle user account in the appropriate databases in accordance with their job function. During the implementation phase of any Jenzabar module, a user may have multiple user accounts in the Production, Pre-Production, Practice, Training, and Development databases. All Oracle user accounts for Jenzabar are created by Data Systems Staff.

 Access control

The data access type and security classes appropriate to the user shall be approved by the Module owneror the data steward of the functional area before the user account can be established or maintained. In some areas the security class maintenance function is performed by the Technical or Module ownerin accordance with special administration rights granted by the DBA and Systems Administrator. Questions about the different data access types for security classes should be directed to the DBA and Systems Administrator.

Oracle security requirements for other applications (InfoMaker) using Jenzabar data

Security roles and role ownership

Each Jenzabar module and functional area shall design a set of Oracle security roles that define object privileges on all tables, views, object access views, and custom views used within the module and the access type of either Selectallows query for reporting only; or Update, Insert, and Deleteallows data to be changed and is restricted to Technical Leads for conversion and special purposes. These security roles allow the college to implement a distributed security model based on security role ownership of specific Jenzabar data. The Module owneror a designated data steward shall be the security role owner who controls all access requests for the security role. In addition to Oracle database security, some of the Jenzabar views provide system specific security at the view level using functions that filter the data so that only the appropriate data is shown to the user. This allows the college to maintain security by fund and organization code, employee class code, cashiering, and/or salary range.

To use other applications such as Toad and SqlPlus a user must have an Oracle user account, or an authorization to an existing Jenzabar schema account such as is needed for system or application development. All authorizations to existing Jenzabar schema accounts are granted by the DBA or the Systems Administrator.

User accounts

To use InfoMaker, a user must have both an Oracle user account with security role grants. The Oracle user account is granted the appropriate security roles Data Systems Staff.

Access control

The InfoMaker product type and security roles appropriate to the user shall be approved by the Module owneror the data steward of the functional area before the access can be granted.

 Request for user access process

A basic form is provided to all Module Owners which they submit for each new employee, or changes in positions/responsibility for existing employees. If an employee leaves one area and begins working in another, a termination form MUST be submitted by the original area, and a new employee form submitted by the new area to guarantee that permissions from one don't ``linger'' into the new area.

Steps to create user access:
- if new employee, network access created first
- must have written request
- create Oracle user account
- grant security classes
- if InfoMaker needed, must have written request
- create InfoMaker user account
- grant security roles
- if employee needs system level security (Fund/Org, Eclass, etc.) send to appropriate data
steward for setup

Access deactivation process

HR will send a written request to ITS for an employee's access to be deactivated due to transfer or termination with the effective date. On the effective date, and within 24 hours of the employee's official separation from the college, the Oracle user account, GC Online and Jenzabar CampusWeb access will be expired and disabled. Some level of access detail information is retained for audit purposes. Timeliness is essential to prevent any unauthorized access to data, therefore HR also submits this information to ITS to guarantee that both internal and external users of a Jenzabar module are also removed from the system in a timely manner.

 Security assessment

Each functional area has a clearly defined set of Jenzabar security classes that is readily available for review and stored in a location that is available to said area, as well as appropriate systems management staff. Each area reviews the definition of their classes at least annually, and at the time of a system upgrade, to guarantee definitions are still appropriate, and that newly delivered forms are assigned to appropriate classes. Each functional area is required to review and sign off on their Jenzabar security classes each year.

At least twice a year, the module owner for each Jenzabar module receives from the DBA or Systems Administrator a printed report of all users who currently have access to some portion of their data and the roles assigned. Module owners are REQUIRED to review this information, sign off, and return this to the DBA and Systems Administrator to keep on file. Receipt of this report is the final ``catch all'' particularly for users perhaps outside of the functional lead's primary area. Before returning to the Systems Administrator, the module owner determines that those external to their primary area are still employed similarly and need access similar to what had been originally granted. Changes are typically fairly limited, as the termination protocol should capture these changes immediately. Non-receipt of this important documentation may result in user account terminations.