Procedure
Effective Date
November 14, 2012
Date of Last Revision
February 24, 2015
Chapter Name
Information Management
Chapter Number
Title
4.8.P.11
Production Banner ERP System Access
1.0 Purpose
Access to production Enterprise Resource and Planning (ERP) information is granted based on the security
principles of “Need to Know” and “Least Access Privileges”. This procedure will document how the access is
requested and granted based on one of two methods associated with the type of user (casual or departmental)
requesting the information.
2.0 Governing Policy
Number/Document Name
4.8 EMU Systems Accounts
Effective Date
September 30, 2008
3.0 Procedure
Casual User:
1) Complete request for access at https://app.emich.edu/banner/views/login
a. Log in using NetID
b. Enter the requested basic information
c. Select the type of access being requested. If a training date is required and training has not been
completed, then the access will not be granted
d. Submit the request.
e. Sign the appropriate confidentiality agreement and return it to IT within 30 days
2) A Help Desk ticket is automatically created and distributed to the correct Functional Security
Representative (FSR) based on the access being requested. Refer to:
http://www.emich.edu/it/about/committees/banner_security_team.php
3) Functional Security Representative (FSR):
a. Approve/deny the request
b. Forward the ticket via email reply to Banner Security with instructions on what needs to be
completed or identifies the appropriate template/class/access to be granted in the email
4) IT Banner Security:
a. Update the appropriate system with the approved access
b. Close ticket and email requestor that access has been granted
IT Procedure
Form Version 3.0
Page 1 of 3
Departmental User:
1) The initial step varies depending on the module
a. For Advancement module access, the FSR processes the initial request on behalf of the
departmental user. If additional access is necessary, the departmental user needs to contact the
FSR to discuss additional access.
b. For all other modules, contact the appropriate FSR directly to discuss the type of work being done
that will require access to an ERP system.
2) FSR:
a.
b.
c.
d.
Contact data owner if different from the FSR, if requested access differs from job responsibility
template
Request via email a new security class/template be created (optional)
Request via email modifications to security class/template (optional)
Send an email to it-banner-security@list2.emich.edu approving access and designating the
appropriate security class/template as well as any additional access approved
3) IT Operations will:
a. Create ticket listing FSR as the client
b. Assign to Banner Security
4) IT Security will:
a. Ensure that all affected FSRs have approved the request if it crosses module boundaries
b. Update all ERP systems with the appropriate access
c. Close ticket with indication that request has been processed
d. Follow up to be sure that the appropriate confidentiality agreement is on file and signed. If the
agreement is not signed and returned to IT within 30 days, access may be suspended
Special Processing for access: Supervisors are contacted for verification of student employees and graduate assistant
access needs to student information. Supervisors are contacted anytime the FSR has a concern regarding the access
being requested.
4.0 Responsibility for Implementation
The Director of Enterprise Operations is responsible for the implementation of this procedure.
5.0 Definitions
Term
Casual User
Departmental user
Data Owner
ERP System
Functional Security Representative
(FSR)
IT Procedure
Definition
A general user with access to basic system features to perform their job
responsibilities.
A back office user with additional access needs.
A data owner is an entity that can authorize or deny access to certain data, and is
responsible for its accuracy, integrity, and timeliness. For ERP modules, the
Functional Security Representative assumes the role of data owner.
Enterprise Resource Planning (ERP) includes Banner INB, Banner Workflow,
Banner Document Management System (BDMS – Xtender), BI/BOE and other
relevant third party software.
An entity that can authorize or deny access to data within the ERP module that
they are responsible for.
Page 2 of 3
6.0 Revision History
Description
Initial Draft – audit response
Updated by Lynnette Rose and the Policy Committee
Updated by Lynnette Rose
IT Policy Committee First Review
IT Policy Committee Second Review
Approved by CIO
IT Procedure
Approval Date
January 8, 2015
February 5, 2015
February 24, 2015
Page 3 of 3