Policy Purpose and Benefit
The purpose of this Policy is to regulate employee access to the University’s online business applications. The Policy ensures that employee logins and access needs are authorized and granted in a legitimate, documented manner. When this Policy is followed, risk to the University’s business operations and reporting due to unauthorized access and inaccurate or misused data is reduced.
Applications Governed by this Policy
- This Policy shall govern employee access to all current and future enterprise administrative software applications.
- Banner is the University’s primary administrative application. Banner Modules include Recruit/Admissions, Student, Financial Aid, Accounts Receivable, Advancement, Human Resources / Payroll, Finance / Grants, and General.
Other Policies
Other policies have a direct bearing on applications access: Banner Data Acceptable Use Policy, Password Policy, and Requirements for Secure Computing.
Access Request Forms
- This Policy is enforced through Position Based Provisioning or Access Request Forms. Benefited positions have the appropriate access stored with the position. As employees are hired, the access is automatically provisioned. When an employee separates or transfers to another position the access is removed. New Benefited positions require review by data stewards who determine appropriate access. Once approved, the access is stored with the new position. All other positions require an Access Request Form.
- There are two types of Access Request Forms. User Access Request Forms are used to create, terminate, or reinstate employee logins to applications. Module Access Request Forms are used to define, or redefine, the detailed scope of application access to be given to employees in accordance with their work duties.
- Access Request Forms vary somewhat in content depending on the application, but all share a common, easy to use format. For applications closely connected to Banner, such as BDMS and Data Transfer, the Banner Module Access Request Form is used to request access.
- For more information regarding access, visit Access Request Forms.
Requirements for User Login Access
Two requirements must be fulfilled before User Access Request Forms may be submitted to EAS. The employee must have a signed Confidentiality Obligation on record.
Department Responsibilities
- Departments are responsible for the content and usage of the University’s business data that is entrusted to their individual missions; therefore, Departments are responsible for initiating the Access Request Forms workflow.
- Signatories who shall progressively complete, approve, and sign Access Request Forms are the Department Manager, the Division Head/Budget Officer, and additionally for Module Access Request Forms, the Module Signatory.
- The Department Manager is the supervisor of the employee for whom the Access Request Form is being submitted. The Department Manager shall complete, or review, the Employee User Information, the Module access details, and sign the Access Request Form.
- The Division Head/Budget Officer is responsible for verifying that the access requested is appropriate for the employee’s job duties. The Division Head/Budget Officer shall approve the Department Manager’s request and sign the Access Request Form.
- The Data Steward/Module Signatory is employed by the Department responsible for the Module’s data, and is responsible for approving all requests to access Module data. After the Module Access Request Form has been signed by the requesting Department’s Department Manager and Division Head/Budget Officer, the Module Signatory shall review the requested Module access details, determine the appropriate security classes to be given, and sign the form.
- For the Banner Finance / Grants Module Access Request Form, if viewing grants is required, the Grant Principal Investigator shall also approve the Department Manager’s request and sign the form.
- For the Banner Human Resources / Payroll Module Access Request Form, if accessing master organizations is required, the Director of Human Resources shall also sign the form.
- Issues pertaining to Module access may arise between the requesting Department signatories and the Module Signatory. Access issues shall be resolved by the requesting Department and the Department responsible for the Module’s data.
EAS Responsibilities
- EAS shall follow Identity Management guidelines for granting and documenting authorized access to administrative applications. See the section below, “Understanding Identity Management”.
- The EAS Staff shall process only completed Access Request Forms that have been signed by each required Department signatory. For Module Access Request Forms, the employee shall be given only the security classes that are listed by the Module Signatory. The ERP Training and Support Specialist shall sign and image every processed Access Request Form.
- To reduce the risk of security incidents, the Assistant Vice Chancellor of EAS shall approve and permit only authorized people to access the servers that store the University’s proprietary application source code.
Understanding Identity Management
- Identity Management (IdM) is an IT methodology whose goal is to facilitate and control employee access to critical online applications.
- In IdM, the word “identity” refers to more than just employee login identities. IdM also defines software identities, such as reports, processes, and forms, and service identities, such as security classes. See the section below, “Understanding Security Classes.”
- Authorized access is controlled by which software and service identities have been assigned to given employee login identities.
- A key feature of IdM is the use of a centralized directory for storing these identity sets. The EAS IdM Directory is physically stored within the Banner application and is updated from Access Request Forms. The EAS IdM Directory may be easily queried at any time to report the current population of employee logins and their currently assigned security classes.
Understanding Security Classes
A security class defines a particular scope of Module data access, for example, “access to update Banner Student Registration.” A given security class may be assigned to a group of employees who share common work duties, for example “maintain Registration data.” Thus, security classes foster efficient management of access because they do not have to be repetitively created for each individual user.
Policy reviewed June 2020 by Rohini Ananthakrishnan.