Guidelines

There are many central-source files into which institutional data is collected from university information systems. These files are maintained on systems for which security has been explicitly considered and continuously addressed. While no protections are 100 percent, data on these systems is considered "safe", both logically and physically. These systems are maintained in the data center of Wrubel Computing Center (IU Bloomington), and the data center located in the Informatics and Communications Technology Complex (ICTC) (IU Indianapolis). Other locations may be equally as secure, but these are known to be and currently contain these central systems and data stores.

Departments and information application development teams are extracting sensitive personal or institutional information from these central sources, or they are directly collecting data from users via online or paper forms, and they are storing the data on computer systems located in departmental areas, outside of these central data centers. These distributed data stores are mostly maintained in support of departmentally developed applications.

Regardless of where the data resides, Indiana University has legal and ethical obligations to ensure that this data is managed in a manner that maximizes its utility while minimizing risk of unauthorized or inappropriate use or disclosure.

There are various concerns about the University's ability to actually fulfill this responsibility as the data strays further from the central "official" sources to decentralized storage locations. While many department managers and technicians may give good attention to these issues, others may not have the knowledge or expertise to appropriately manage and protect these data stores. Specific areas of concern are lack of awareness of the nature of the data and associated legal and ethical issues, less attention to analysis of access requirements and ensuring appropriate release and use, lack of appropriate security protections commensurate with the sensitivity of the data, insecure transmission of the data, little or no planning for systems or business continuity or disaster recovery, lack of planning for continuity of knowledgeable staff related to the technology and the information, and use of computer systems and/or data storage space designed and protected for public or non-sensitive data to store and manipulate restricted data.

Indiana University has policies governing access to and management of University institutional information. These policies describe a process by which all data is reviewed and classified (see Data Classification, below), and provides guidance as to how data of various classifications should be treated. Information policy documents can be viewed on this site in our policies section. For more on University Data Management, visit IU's Data Management site.

University Data Management Council (UDMC)

Members of the UDMC are responsible for "recommending policies, and establishing procedures and guidelines for university-wide management of institutional data. Individually, several of the Data Stewards have management and policy-making responsibilities for specific segments of the institutional data base."

Data managers

Data Managers are located in various departments within the University, and are responsible for receiving, evaluating, and putting into motion the actions required to implement the requests for access to institutional data, primarily by notifying the appropriate technology organization that the specific database or application permissions must be executed.

University data administrator

Data administration involves the application of formal guidelines and the appropriate tools to manage Indiana University's information resources. The University Data Administration function (within the Office of the Vice President for Information Technology) exists to support and further the goals of the University data management committees and structure.

Data classification provides a methodology for categorizing data associated with a University function. The classification level assigned to data should steer business and technical project teams to the security protections and access authorization mechanisms appropriate for that data. Such categorization encourages the discussion and subsequent full understanding of the nature of the data being displayed or manipulated.

The classification of data must result from legal protections (by statute, regulation, or by the data subject's choice), contractual agreements, ethical considerations, or strategic or proprietary worth. Data can also be classified as a result of the application of "prudent stewardship", where there is no reason to protect the data other than to reduce the possibility of harm or embarrassment to individuals or to the institution. If none of these pressures are associated with the data, then the data should be classified as "public" and the need for protections is eased considerably. The Indiana University classification scheme is described on the Data Management site.

In any case, it is critical that all data are classified and that consideration of the classification be an important part of any project to develop an application or database that will extract, manipulate, and/or store the data. Obviously, the greater the damage that the release of data could cause individuals or institutions, the higher the sensitivity and the assigned classification. And the higher the assigned classification, the greater the protections necessary for that data.

The technology and business processing environments must be analyzed to see where there are risks to the data in that particular implementation. Risks can be associated with both logical and physical access, and are expressed as a function of what can happen:

• disclosure (violation of institutional or personal privacy, document confidentiality, etc.)
• denial of service (degradation, availability, and reliability of services and data).
• alteration (compromise of integrity and validity)
• Along with the probability of the thing actually happening and the level of resulting damage (in whatever form that may manifest itself), all parties involved in a project should objectively discuss these issues. Risk points must be identified and mechanisms or processes designed to mitigate or minimize the risk should be built into the task plan. There are four common ways to handle risk:
  • Avoid the risk - decide not to implement technology or business process.
  • Minimize the risk implement controls or processes to minimize the risk.
  • Transfer the risk buy insurance against the occurrence or resulting damage.
  • Accept the risk because probability of occurrence is low or cost of protections outweighs the total cost of damage or recovery.

Risk assessment can be made easier by defining the data architecture and the technical architecture in security domains, described later in this document.

There are several entities that have tasks related to ensuring that data is protected appropriately. Each has knowledge that the others must rely on to ensure that Indiana University's obligations to various constituents are satisfied.

University Data Stewards and Data Managers

University Data Stewards are responsible for determining authentication and other security requirements for access to institutional data. Data Stewards and Data Managers are specifically tasked with understanding and applying the legal and ethical restrictions associated with their particular functional area, and assigning classifications to the data per University guidelines. It is their responsibility to ensure that processes and procedures are in place to ensure that these requirements are met, determine what logical and physical security protections are necessary, and determine what policies are applicable and what audit processes are necessary to ensure compliance.

By policy, any requests for access to institutional data must come through these individuals, though the daily activities related to this have been delegated to the Data Managers. The Data Stewards and Managers are the only persons having the authority to review actual needs and subsequently grant access.

University Information Policy Office (UIPO)

The UIPO in the Office of the Vice President for Information Technology is responsible for providing leadership in the area of data management and technology policy.

This responsibility generally includes working with the UDMC to develop and interpret information policy and standards, and to provide information management resources and education for information providers and consumers.

The University Information Policy Officer will participate in discussions of data classification and handling, and will provide expertise and/or research to best practices in these areas.

The UIPO can be contacted at uipo@iu.edu.

University Information Security Office (UISO)

The UISO in the Office of the Vice President for Information Technology is responsible for providing leadership and resources in the area of information and information technology security for Indiana University.

This office will research, acquire, or develop security tools as appropriate to satisfy the protection requirements outlined by the Data Stewards and others, and will make these available to the Data Stewards, systems administrators, and applications developers in a "security toolkit". In addition, this office maintains a comprehensive online security resource, provides consulting, and makes recommendations to the CID, UDMC, business managers, technology managers, technicians, and others regarding appropriate information security and information access.

The UISO security officers and staff will work with applications developers and systems administrators to review technical architectures and provide information as to known vulnerabilities that specific components introduce. They will provide available information as to how to reduce the risk associated with those exposures, and make arrangements for new systems to be scanned for these vulnerabilities periodically and automatically.

UISO can be contacted at uiso@iu.edu.

University Information Technology Services (UITS)

UITS in the Office of the Vice President for Information Technology is responsible for providing a central information systems support infrastructure. 

UITS maintains the expertise required to understand and adequately describe (to Data Stewards, functional area managers, and consumers) how the applicable technology has been deployed or will be deployed, how the data flows, and where exposures may exist. UITS provides applications development and information services, and must also be aware of and adhere to security standards and other requirements identified by the UDMC as appropriate for the data being manipulated.

Information about UITS can be found at uits.iu.edu.

University Internal Audit

University Internal Audit provides independent appraisal of the University's financial, operational, and control activities.

This office reviews and reports on adequacy of internal controls, the accuracy and propriety of transactions, the extent to which assets are accounted for and safeguarded, and the level of compliance with institutional policies, government laws and regulations. Internal Audit actively participates in the development of new computer systems or enhancements to current systems to promote the design of adequate internal controls prior to implementation and reduce the need for corrective measures at a later date. Audits can be as a result of a loss or fraud investigation, mandated by law, or upon request.

Technicians (Programmers, Database Analysts, System Administrators, Etc.)

In conjunction with functional area project managers, Data Stewards/Managers, security staff, and others as appropriate, technicians must review the information contained in this document and develop material describing how they are addressing the technical concerns and issues herein.

Technicians are responsible for ensuring that operating systems, file structures, programs, databases, and other constructs developed in support of manipulation and storage of data adhere to established data and system security standards and policies. In order to do this the technicians must develop thorough documentation related to the planned technical and data architectures. If the resulting documents contain an adequate amount of detail, this process should ensure that issues are identified and formally considered, and good information is provided to the project team members, Data Stewards, Security staff, Auditors, and others.

In addition, technicians must maintain an adequate level of technical expertise appropriate to the technical architectures (development tools, operating systems, hardware, database management systems, etc.) involved, as long as the application is active. They must be aggressive in ensuring that their technologies are maintained and configured in such a way as to ensure an initial and continued high-level of security.

The technicians must proactively maintain their hardware, operating systems, and applications to ensure that appropriate upgrades and patches are applied (especially those designed to eliminate security vulnerabilities) and that appropriate actions are taken on applicable security and other advisories issued by the vendors, the UISO, and other appropriate agencies.

The technicians must proactively use available security tools appropriate for their hardware and operating system -- the UISO can provide access to general software licensed to the University for this purpose, but there may be other specific software that will better determine the security state of certain architectures.

Technicians may consult with the UISO as they are planning their technology architecture, or that consultation may come in conjunction with a meeting with the Data Steward(s)/Managers.

Department Managers (Deans, Directors, Chairs, Managers)

In conjunction with project technicians, Data Stewards, Security staff, and others as appropriate, departmental/functional area managers and project leaders must review the information contained in this document and develop material describing how they are addressing the concerns and issues herein.

Departmental/functional area managers and project leaders who have commissioned an application or database that will involve the manipulation or storage of institutional data are responsible for ensuring that appropriate contacts as outlined herein are made before work begins on their project. They are further responsible for ensuring that their processes adhere to University business standard practices and policies, and to data usage, handling, and security standards and policies.

The appropriate Data Stewards must be consulted in order to determine the best deployment situation -- level of user authentication, for example -- for the data involved in any given implementation. Advice and authorizations must be obtained from the Data Steward(s) at the outset of the project involving institutional data on departmental computer systems. If this is not done, significant changes may be required for partial or completed projects, in order to bring the implementation into line with existing procedures, standards, and policies.

In addition to the technical materials developed by the project technicians, departmental/functional area managers and project leaders must be prepared to describe in detail:

1. the business process that will be supported by the application or database,
2. why its necessary to create this distributed application or database,
3. the intended audience or beneficiaries of the application or database,
4. local processes that will ensure continued adherence to data management and data administration policies, and
5. local processes that will ensure continued compliance with policies and laws related to release and use of the information being accessed.

In addition, the senior manager of the functional area or department must be prepared to guarantee that they have adequate systems and technical support to develop and implement the project, and that they will be in a position to maintain a fully trained and technically capable support staff as long as the application is active. That is, they must indicate the means to deploy and maintain a continuous level of technical staffing with good expertise appropriate to the chosen system and data architectures.

University Data Administration

This office is concerned with issues related to electronic information management (usage/protection policies, practices, and assessment programs), digital records retention/preservation (processes, standards, and issues related to deterioration of media), data administration (standards for institutional data modeling, definitions, data element naming, and logical data structures, data classification), and directory services (identification and authentication of users, account administration procedures, user directories, and online address books).

University Data Administration is available to project teams and developers to discuss appropriate data extraction, manipulation, storage, dissemination, and general protection of data being manipulated by their applications or systems.

Indiana University Archives

The University Archives is a department within the Indiana University Library system. The primary mission of the University Archives is to collect, organize, make accessible and preserve records documenting Indiana University's origins and development and the activities and achievements of its officers, faculty, students, alumni and benefactors. The University Archives is the largest and most comprehensive source of information on the history and development of Indiana University. Project teams and functional area managers should consider the implication of their records in these areas, and communicate with the Archivist to ensure that processes are installed to ensure appropriate records are retained.

Generally, issues related to the appropriate protection of institutional data can be described and discussed in four categories: identification, authentication, authorization, and accountability. While specific data and system architectures will have a bearing on how goals in these areas are satisfied, there are best practices/standards related to each.

Identification

Identification involves the collection of a name or some other form of description for a particular user.

For any access to non-public institutional or personal data, it is very important that each user have a unique identity assigned. Anonymous (no user identifier required) or generic (a common username for all users) access does not permit adequate accountability, because if the information were inappropriately disclosed under those circumstances, there would be no way to determine and assign responsibility, and subsequently no administrative or legal recourse. Identification done this way provides no deterrence, since opportunity is given and anonymity is ensured. Only in very few circumstances can anonymous or generic access be permitted -- normally where other controls are in place to specifically identify the person accessing the material (a paper access log, for example).

UITS, Campus Computing Centers, and other technology centers must coordinate the assignment of usernames and personal identification numbers to ensure that users of institutional information have a unique University identity. Standard patterns for creation of an eight (8) character username have been established and will be followed.

Authentication

Authentication is the process of ensuring that the person supplying an identity is the person to whom the supplied identity has been assigned.
There are industry-standard methods for authenticating the identity of users. Generally, it is accepted that the forms of authentication come in three types -- something the user knows (e.g., a passphrase), something the user carries (e.g., an ID card), or something about the user (e.g., a fingerprint). A combination of at least two of these is necessary to adequately ensure appropriate access to the most sensitive/confidential information, while a passphrase may be adequate for less sensitive (e.g., non-restricted) materials.

Five (5) standard levels of authentication for access to services are currently recognized, and selection of the appropriate method will be based upon the type of access and the sensitivity of the data involved. The Data Steward for the data area involved will, with input from others, make the decision about the level and type of authentication that will be deployed:

1. Network Address/Physical Location. May be used where it is only important to restrict access to data or a particular service to persons using a specific or any Indiana University networked device. "Proxy"-type services may be deployed where it is necessary to provide this access to IU users who are not physically attached to an IU network segment. However, some additional form of authentication is necessary to ensure that the person accessing this proxy mechanism is indeed a member of the IU community and as such authorized to access the network address-protected services.
2. Public/Anonymous. Applications, systems, or services which provide read-only access to data which has been classified as "public", and for which wider internal or external dissemination is desirable, will be considered candidates for access via public or "guest" accounts where no username and/or authenticating passphrase is required. This does, however, slightly compromise accountability.
3. Passphrase. Passphrase authentication may be used for applications where access to data or information systems require individual (personal) identification, and where the passphrase is sufficient to authenticate this identity. The passphrase should be used where a high-level of individual accountability must be guaranteed for access to the data or application system.
4. Authentication Device. This level of protection makes use of token technology as a means of user authentication when near-absolute individual accountability is important. These devices require that the user physically possess the device and (optionally) know the associated PIN assigned to the device. Since the device generates a one-time password (i.e., the password is only good for one authentication), the validation dialogue need not be accomplished via a secure communications method.
5. Passphrase/Authentication Device. This level of protection makes use of token technology as an additional means of user authentication, in addition to a passphrase, when near-absolute individual accountability must be guaranteed. These devices add an additional security mechanism that requires that the user physically possess the device in addition to knowing the passphrase associated with the account.

Authorization

Authorization is the process of associating the user with a status, organization, job function, or some other profile or category, determining what access permissions they have been granted, and subsequently ensuring that they can only get to those resources.

Once an identity has been authenticated, there must be some process to determine what that individual can do or access based on who they are. The user may fit into a category of users all with the same access requirements, such as payroll clerks for a large department. Or they may have individual authority to access very specific information, such as an employee accessing their own personal payroll information.

In any case, authorization request processes must be in place, and associated technical mechanisms to enforce the authorizations must be implemented, in order to limit to only that material that the person is authorized to see and use.

Accountability/non-repudiation

Ensuring Accountability/Non-repudiation is the process of making sure that users cannot extend or change the access permissions assigned to them based on their authenticated identity, and also making sure that another user (authorized or unauthorized) cannot assume the identity and associated authority assigned to someone else. In this way, authorized users can be held accountable for their actions.

When designing an application or data extract process, there are several components, or security domains, of the technical architecture that must be considered in the interaction between a user extracting or providing data and the ultimate data store. Each of these has its own security risks and exposures, and includes the logical and physical security protections afforded the data on the user's desktop (the "client"), on the network, on the application servers, and on the database servers.

Firewalls/security perimeters

Generally, firewalls are applications designed to keep certain people from executing or participating in specific technology-based services inside and outside of the University network confines. There are myriad levels of firewalls, from protecting a specific directory on a specific system, to protecting a entire computer system with network address filtering, to protecting an entire network segment with several resident hosts, to large perimeter firewalls designed to protect an entire institution from the outside world. The use of firewalls in the IU environment, particularly one that protects the entire enterprise, is difficult for various reasons, including cost of maintenance, difficulty in ensuring that policies and rules are updated concurrent with constant changes in University technology services, reliance on single points of protection and failure, and appearance of restricted flow of information within the University environment. Technicians should consider firewalls in specific instances where it is important that only certain individuals be permitted access to a service or minimal set of services, but where freedom within the restricted area by these authorized individuals is important. Firewalls may only be deployed on the university network when in compliance with policy IT-19: Extending the University Data Network.

Client workstation

Primarily, users will be connecting to data sources and applications from personal computers, and the authentication and other sensitive data that is handled by these personal computers must be protected.

1. Data must not be stored on the user's device after the application or connection has been terminated, unless the user has specifically intended that the data be saved. Where possible, developers of client applications handling sensitive information must ensure that programs are written or configured so that data isn't stored on the user's hard disk or in memory after the application has been terminated.
2. Where "caching" of data is necessary, users must be clearly instructed on how to configure client software to eliminate the data after the session is complete. For example, in the WWW environment, browsers such as Apple's Safari and Microsoft's Internet Explorer use "disk caching" to store information related to application and user activity. Disk caching of information makes downloading previously manipulated and/or viewed data more efficient. Documents that are secured with the Secure Sockets Layer (SSL) protocol are not automatically disk cached, and developers of documents collecting sensitive information must tag server documents so they aren't stored on the user's hard disk.
3. Developers of client applications must implement appropriate identification and authentication mechanisms commensurate with the sensitivity of the data associated with the application, as determined by the appropriate Data Steward.
4. Developers of client applications must implement appropriate protections to ensure user accountability is maintained.
5. Departmental/functional managers must proactively inform users of the consequences of mishandling sensitive institutional, confidential, or personal information.

Client-to-application server network connection

Communication between the user's computer and the host where the data are being collected or from which the data are being disseminated must be secured. That is, there should be no opportunity for unauthorized disclosure of the information as it traverses the network.

For example, the current best practice in the WWW environment is to use the SSL protocol to secure the browser-to-server traffic. Server certificates can be purchased from the University Information Security Office, and must be renewed annually. Departments are responsible for ordering and paying for their own certificates.

Data collected on the application server

If data collected via the application are initially collected into file space on the application server, access to that data must be protected against unauthorized access with file protections and access control lists. It is important that data NOT be in a location accessible via unauthorized persons, and it is recommended that data be encrypted where feasible.

Data transfer

If the data are transferred from the application server file space to another computer, they must be conveyed using an encrypted method. That is, the data must be transmitted such that no unauthorized person can view it or intercept it.

Technician/database/data Administrator access

Access by system and data administrators to systems where sensitive/confidential information is stored must be done in a secure manner, so that unauthorized persons cannot intercept those credentials and gain privileged access to the server and to the data.

Access via a directly connected console terminal is one method of ensuring this access is secure. Another more flexible method is the use of an authenticated and encrypted access method such as "secure shell" (SSH), instead of Telnet.

Administrators may not view or disseminate institutional or personal information stored or otherwise supported by their systems without permission from the functional managers or Data Steward.

Data storage

Once the data is loaded to a longer-term file space, access to it must be protected against unauthorized access with file protections and access control lists. It is important that this data NOT be in a location accessible via the network by unauthorized persons. A lot of people neglect to consider how their database ports are accessible, even though they have restricted terminal access to the system on which the databases are housed. These ports should be blocked or unauthorized access to them be prevented.

It is recommended that this data be encrypted where feasible.

Physical security

The application server and the server where the data is maintained and manipulated must be physically protected so that the actual computers and storage media cannot be stolen and access to direct connect console terminals is restricted. Unless full and strong encryption of all data is used, logical protections are useless if someone can remove the data storage media to a location where they can attempt access at their leisure.

There should be procedures in place to ensure that the data can be reconstructed in the event that the primary copy becomes unusable (the file is inadvertently deleted or inappropriately modified extensively, or the server or the facility is inaccessible due to some disaster, etc.). There must be a process for securely copying the data to a secure off-site location, and also a periodically exercised process for recovery of the primary copy from these backups if necessary.

All copies made for the purpose of disaster recovery must be logically and physically protected and not accessible by unauthorized persons.

The following are areas that are discussed in the Guidelines for Handling Electronic Institutional and Personal Information (this) document. Project/business managers should use this document and checklist as a guide when developing project documentation related to security or data use, or when requested to provide information for audits or other reviews.

Descriptions and narratives in each of these areas should be in as much detail as possible. It is important that all parties understand the risks inherent in unsound business practices related to University operational processes and procedures as well as in inadequate data and technical management. The University may be greatly embarrassed by the inappropriate release of personal or proprietary information, or may suffer direct legal liability. Just as important, individuals may suffer personal loss due to ineffective management on the part of a University agency.

Consultations with various offices or agencies are encouraged throughout the project planning and implementation process. Obviously, it is costly to have to back up and make changes to processes and components that are already in place, because they do not comply with University or other requirements.

I. Initial Data Steward Consultation. Consult with the Data Steward for the appropriate data area(s) about data or information that may be involved in the project, in order to have preliminary discussions about appropriate use, statutory requirements, or ethical considerations.

II. Initial Financial Consultation. If there are financial (commerce) aspects of the project, the project team must consult with Treasury Operations, as there are standard processes and procedures that must be followed for collection of monies, credit card information, etc.

III. Initial Technology Policy/Security Consultation. Contact the University Information Technology Policy Office and describe preliminary plans, in order to ensure that there are no obvious technology policy or security issues related to the proposed processes or technologies.

IV. Initial Audit Consultation. Contact University Audit and describe preliminary plans, in order to ensure that there are no obvious audit/control issues related to the proposed processes or technologies.

V. Business Process Narrative. The project team must describe the overall business function and process, describing in detail the business being performed:

1. 1. 1. what University service is being provided,
      2. what product is being sold,
      3. what audience ("customer") is being addressed,
      4. what information is collected from the customer, and what is done with that information,
      5. how is the customer identified,
      6. what is the business cycle,
      7. what accounts are involved,
      8. what external providers/vendors are involved,
      9. other information that is pertinent to others understanding the entire business process.

VI. Data Architecture Narrative. The project team must describe how the data flows through the business process, using data flow diagrams as appropriate:

1. 1. 1. Describe specific data elements. E.g., GPA, student home address, employee office phone number, faculty discipline, etc.
      2. Describe data sources (actual or proposed). E.g., from the customer, central University files or databases, paper or electronic forms, phone interviews, etc.
      3. Describe authorized users/viewers. Once the data is collected and stored, describe who will need continued access to the data for business, system administration, or data administration purposes.

VII. Technical Architecture Narrative. Describe the overall technical architecture in detail:

1. 1. 1. purchased applications;
      2. external vendor technical services;
      3. development tools/environment;
      4. operating systems;
      5. system software;
      6. databases or other data storage;
      7. middleware (application server, database connectivity modules, directories, etc.);
      8. programs, processes, scripts;
      9. client/workstation environment;
      10. database host/server environment;
      11. network environment (between components supporting the business process and external agencies or systems);
      12. Development and testing environment;
      13. Application source code databases;
      14. End-user identification, authentication, and authorization processes;
      15. Business staff/administrator identification, authentication, and authorization processes;
      16. Administrator/technician identification, authentication, and authorization processes;
      17. Access authorization table -- who will have access to
          1. application (client executable),
          2. application source code,
          3. data (databases via data manipulation language
          4. databases (data definition language),
          5. supporting programs, scripts, and processes,
          6. operating systems software,
          7. other systems software.

VIII. Management Narrative. Describe in detail the processes and procedures in place to ensure appropriate continued management of the business process, data environment, and technical environment:

1. 1. 1. Describe how managers and staff will be trained/refreshed on procedures and processes associated with the business being described.
      2. Describe the current level/capability of technical staff, and describe how the department plans to provide for a continued adequate level of technical expertise for technology deployed to support the business being described.
      3. Describe how technologies will be maintained and configured in such a way as to ensure an initial and continued high-level of security (change management procedures).

IX. Security Narrative.

1. 1. 1. Describe how data and applications in support of the business being described and residing on the client workstation are protected.
      2. Describe how data transmitted from the client workstation to the first-level-server (WWW server, application server, or database server) will be protected.
      3. Describe how data communicated or retrieved from the client workstation will be stored and protected on the first-level-server.
      4. Describe how data extracted from the first-level-server to subsequent servers will be protected during transmission.
      5. Describe how data stored in its "final" database will be secured.
      6. Describe how end-user identification will be validated and authenticated.
      7. Describe how business staff identification will be validated and authenticated.
      8. Describe how technician identification will be validated and authenticated.
      9. Describe how end-users will be restricted to accessing only functions and/or data for which they are authorized.
      10. Describe how business staff will be restricted to accessing only functions and/or data for which they are authorized.
      11. Describe how technicians will be restricted to accessing only functions and/or data for which they are authorized.
      12. Detail how direct access to database ports (e.g., with generic ODBC clients) will be secured.
      13. Describe how hardware and software components under the control of the business unit will be physically protected from direct access or theft.
      14. Describe backup and recovery procedures, including how backup media will be secured.

X. Central Systems/Databases Narrative. With appropriate input from University Information Technology Services (UITS)

1. 1. 1. Describe processes, scripts, job control streams, or programs that will execute on or will interact with central systems maintained by UITS.
      2. If there are items described in #1 of this section, describe how applicable UITS database standards and policies are being met.
      3. If there are items described in #1 of this section, describe how applicable applications development standards and policies are being met.

XI. Security Review. Consult with the University Information Technology Policy/Security Offices:

1. 1. 1. Review prepared documents/information.
      2. Discuss and agree on appropriate electronic information handling processes.
      3. Discuss and agree on appropriate logical security mechanisms and processes.
      4. Discuss and agree on appropriate physical security mechanisms and processes.

XII. Audit Review. Consult with University Internal Audit:

1. 1. 1. Review prepared documents/information.
      2. Discuss and agree on appropriate management controls on business and financial processes.
      3. Discuss and agree on required reconciliation processes.

XIII. Data Steward Review. Consult with the Data Steward for the data area(s) involved:

1. 1. 1. Review prepared documents/information, including information from the Security and Audit Reviews.
      2. Discuss applicable statues/protections related to the data involved.
      3. Determine the best/appropriate data sources.
      4. Discuss legal obligations and training requirement.
      5. Obtain approval to use the data for the business purpose stated.

XIV. Financial Review. Consult with Treasury Operations:

1. 1. 1. Review prepared documents/information, including information from the Security and Audit Reviews.
      2. Ensure that standard University processes and procedures are being used/followed, or that appropriate exceptions are approved.