Information Technology Policies

Safeguarding GLBA Customer Information

lhendrickson@govst.edu — Mon, 13 Apr 2026 16:26:48 +0000

Safeguarding GLBA Customer Information

Policy Statement
This policy establishes the foundation for compliance with the Gramm-Leach-Bliley Act (“GLBA”) Standards for Safeguarding Customer Information (“Safeguards Rule”).
Purpose
Pursuant to its program participation agreement and student aid internet gateway agreement with the U.S. Department of Education and as a condition to being eligible to participate in federal financial aid programs under Title IV of the Higher Education Act of 1965, the University must comply with the GLBA, which requires financial institutions to take steps to protect customers’ nonpublic personal information. Institutions of higher education are required to comply with the Safeguards Rule as outlined in 16 C.F.R. Part 314. These requirements are additional to those of the Family Educational Rights and Privacy Act (“FERPA”). The purpose of this policy is to ensure compliance with the University’s program participation agreement, student aid internet gateway agreement, the GLBA, and the Safeguards Rule and to protect the privacy interests of the University’s students.
Scope
This policy applies to all “customer information,” which is defined as any record, whether in paper, electronic or other form, containing nonpublic personal information about a customer (past or present) that is handled or obtained by ��Ƶ or on its behalf or by or on behalf of any affiliate of ��Ƶ. A “customer” is a person having a “customer relationship” with the University, meaning a continuing relationship under which the University provides one or more financial products or services to the customer that are to be used primarily for personal, family, or household purposes. The University’s primary “customers” are its students. Financial services provided by ��Ƶ may include the University administering or aiding in the administration of Title IV programs; making institutional loans or scholarship payments; or certifying a private education loan on behalf of a student. Customer information is limited to financial information connected to student and parent finances such as student and parent loans, bank account information and income tax information for financial aid packages.
1. Policy
  It is the policy of the University to maintain a reasonable information security program sufficient to meet the requirements of the GLBA Safeguards Rule. An “information security program” means the administrative, technical, or physical safeguards the University uses to access, collect, distribute, process, protect, store, use, transmit, dispose of, or otherwise handle customer information. The University’s information security program is comprised of the following nine elements.
  1. Element 1: Designate a Qualified Individual to oversee and implement its information security program
    The University Director of Information Security is responsible for this GLBA policy and is designated as the Qualified Individual for the University. The Qualified Individual is responsible for overseeing and implementing the University’s information security program and enforcing its information security program.
  2. Element 2: Identify and assess the risks to covered data in each relevant area of the University’s operations, and evaluate the effectiveness of the current safeguards for controlling these risks
    The Director of Information Security shall perform risk assessments, and may work with data custodians, application owners, units, and individuals to identify and assess risks to customer information including but not limited to:
    1. Unauthorized access to customer information;
    2. Compromised system security as a result of system access by an unauthorized person;
    3. Interception of customer information during transmission;
    4. Loss of data integrity;
    5. Physical loss of customer information in a disaster;
    6. Errors introduced into the system;
    7. Corruption of data or systems;
    8. Unauthorized requests for customer information;
    9. Unauthorized access to hard copy files or reports containing customer information;
    10. Unauthorized transfer or release of customer information by third parties contracted by the University;
    11. Unauthorized disposal of customer information; and
    12. Unsecured disposal of customer information.
    The University recognizes that the above list of risks may not be a complete list of risks associated with the protection of customer information. Since technology changes over time, the possibility of new risks may arise, and the risk assessment shall be updated regularly.
  3. Element 3: Design and implement a safeguards program with the minimum safeguards outlined in 16 C.F.R. 314.4 (c)(1) through (c)(8)
    The minimum safeguards to protect customer information include:
    1. Implement and periodically review access controls, including technical and, as appropriate, physical controls to authenticate authorized users and limit users’ access only to customer information needed to perform duties or functions;
    2. Identify and manage the data, personnel, devices, systems, and facilities that enable each unit to achieve business purposes in accordance with their relative importance to business objectives and the University’s risk strategy;
    3. Protect customer information held or transmitted by the designated units in transit over external networks and at rest, or use effective alternative compensating controls reviewed and approved by the Director of Information Security;
    4. Implement either multi-factor authentication or reasonably equivalent access controls approved by the Director of Information Security for information systems where customer information is held;
    5. Follow ITS approved secure disposal procedures for any system with customer information;
    6. Retain records in accordance with the State Record Retention Act;
    7. Follow ITS procedures for change management impacting University information systems where customer information is held; and
    8. Follow all ITS procedures and controls designed to monitor and log the activity of authorized users and detect unauthorized access or use of, or tampering with, customer information.
  4. Element 4: Regularly monitor and test the safeguards program
    The Director of Information Security will follow regular ITS procedures to monitor and/or test the technical safeguards for GLBA customer information. The University’s Internal Audit department will conduct periodic audits and reviews of the University's information technology and information security to assess compliance with applicable policies, regulations, and best practices.
  5. Element 5: Implement policies and procedures to ensure that University personnel are able to implement the information security program
    This Policy is related and subject to University Policy 92 and associated procedures. Where appropriate, unit level policies and procedures may be adopted as long as they are consistent with University Policy 92 and related procedures. Individual units are responsible for facilitating compliance with all information security policies and practices applicable to their unit. The University shall provide cybersecurity awareness training as ensuring employees are properly trained is an essential component of the information security program.
  6. Element 6: Select service providers that can maintain appropriate safeguards over covered data, ensure the service contract requires them to maintain safeguards, and oversee their handling of covered data
    University units shall not purchase software or enter into contracts with service providers prior to obtaining a completed risk assessment or other approval from ITS. Contracts shall ensure that service providers maintain safeguards with respect to University data, and that the University is entitled to audit compliance with that requirement.
  7. Element 7: Provide for the evaluation and adjustment of information security program in light of relevant circumstances, including changes in the University’s business or operations, or the results of security testing and monitoring
    The information security program and associated policies and procedures shall be reviewed and updated as necessary.
  8. Element 8: Establish a written incident response plan designed to promptly respond to, and recover from, any security event materially affecting the confidentiality, integrity, or availability of covered data in the University’s control;
    The University shall adopt a written incident response plan to respond to data security incidents. It is understood that in the event of a breach of customer information, the University is required to notify contacts designated by the U.S. Department of Education within 24 hours after an incident is known, identified, or suspected.
  9. Element 9: Require the Qualified Individual to report in writing, regularly and at least annually, to the Board of Trustees.
    The Qualified Individual will submit a report to the Board of Trustees annually.

lhendrickson@g… 04/13/2026

President Joyce Ester

04/01/2025

07/10/2025

SEO Summary

��Ƶ maintains a comprehensive information security program to comply with GLBA requirements and protect student financial information.

eCFR :: 16 CFR Part 314 -- Standards for Safeguarding Customer Information at https://www.ecfr.gov/current/title-16/chapter-I/subchapter-C/part-314

100

Safeguarding GLBA Customer Information (Policy 100)

Policy Categories

Information Technology Policies

Policy Owner/Department

Information Technology Services

04/01/2025 as Interim; 07/10/2025

Information Security Breach

lhendrickson@govst.edu — Sun, 29 Mar 2026 20:40:51 +0000

Information Security Breach

Purpose
The purpose of this policy is to describe ��Ƶ’s (��Ƶ) responsibilities and remediation practices as they relate to incidences of information data breach.
Scope
This policy applies to information safeguarded both by ��Ƶ and/or by third party vendors and contractors working with ��Ƶ. A breach is defined as unauthorized access/disclosure of personal information. The ��Ƶ Information Technology Services (ITS) Department will investigate all reports of security breaches of personal and/or sensitive University information. Based on the results of the University's investigation, internal and/or external parties may be notified, as necessary.
Policy
It is the policy of ��Ƶ that unauthorized access and potential information incidents or data breaches be fully investigated and the following actions taken as appropriate. As required by the Illinois Personal Information Protection Act 815 ILCS 530/1 (PIPA), in the event of a data breach ��Ƶ shall notify all identifiable individuals whose personal information is affected by a breach whether the source is a ��Ƶ computer system data or written material. This notification shall be made in the most expedient time possible and without unreasonable delay. ��Ƶ shall use an investigative process to help mitigate and remediate any on-going or future information security or data breach vulnerabilities. All ��Ƶ employees, regardless of status, ��Ƶ affiliates, and third-party contractors are required to report any potential information incident or data breach to the Associate Vice President (AVP) of Information Technology Services, who will notify all appropriate University officials.
Beyond notification and except where required by law, the University makes no promise of service to individuals affected by a Security Breach. The President of the University, however, may elect to provide additional services to affected individuals.
1. Internal Notification
  The ��Ƶ Information Technology Department will report all suspected cases of information security breaches to the University’s executive administration and will work with them to establish an appropriate response strategy. If the investigation determines criminal activity may have taken place, the Department of Public Safety and Legal Counsel will also be notified. The affected parties will be notified of the investigation outcome.
2. External Notification
  The AVP of Information Technology Services, in consultation with University Administration, will determine if external notification is required in the event of a personal information breach. Parties to be notified will include those affected by the breach.
3. Social Security Numbers
  ��Ƶ will collect, use, or disclose an individual’s social security number only in circumstances allowable under the Illinois Identity Protection Act (5 ILCS 179/1, et seq.) (IPA).
4. Personal Information
  Personal Information is defined by the Illinois Personal Information Protection Act 815 ILCS 530/1 (PIPA), the Family Education Rights Privacy Act 20 U.S.C. § 1232g; 34 CFR Part 99 (FERPA), and University Policy 12 (Access to Student Educational Records).
  Examples:
  1. Individual personal information such as driver’s license numbers and social security numbers;
  2. Financial data such as bank account numbers, tax forms, and credit/debit card numbers;
  3. Educational records such as transcripts, grades, test scores, and academic standing; and
  4. Human resource records such as health and benefit information, and dependent information.
  This includes but is not limited to physical and/or electronic media and paper records or files.
Enforcement
Any employee found to have been involved in a data breach may be subject to disciplinary action, up to and including termination of employment. Any student found to have been involved in a data breach will be subject to disciplinary action as outlined in the student code of conduct (University Policy 4). All entities found to have been involved in a data breach may be subject to legal and criminal investigation.
The President of the University, or designee, shall be empowered to declare a data breach.
The AVP of Information Technology Services has primary executive oversight of data breaches.
Based on the findings of the data breach investigation, the unit leader within whose area of responsibility the breach has occurred is accountable for ensuring that recommended actions are implemented and that suitable continuous improvement activities are performed.
Glossary
1. Data Breach: A security incident in which sensitive, protected or confidential data is copied, transmitted, viewed, stolen or used by an individual unauthorized to do so. Data breaches may involve financial information such as credit card or bank details, personal health information (PHI), personal identifiable information (PII), and protected academic records (FERPA).
2. Electronic Media: Any type of device that stores or allows the distribution or use of electronic information.
3. Family Education Rights Privacy Act ( FERPA) (20 U.S.C. § 1232g; 34 CFR Part 99)
4. Illinois Identity Protection Act (IPA) (5 ILCS 179/1, et seq.)
5. Illinois Personal Information Protection Act (PIPA) (815 ILCS 530/1)
6. Incident: An individual occurrence or event.
7. Unauthorized Access: Any individuals without a legitimate need to use personal information as defined in HIPAA, FERPA, PIPA, and IPA.
8. University Policy 4 Student Conduct Policy found on the ��Ƶ Policy Page
9. University Policy 12 Access to Student Educational Records found on the ��Ƶ Policy Page

lhendrickson@g… 03/29/2026

President Elaine P. Maimon

12/16/2013

05/16/2016

SEO Summary

��Ƶ's information security breach policy outlines procedures for investigating unauthorized access to personal data and required.

Access to Student Education and Treatment Records

Student Conduct Policy

Family Education Rights Privacy Act ( FERPA) (20 U.S.C. § 1232g; 34 CFR Part 99)
Illinois Identity Protection Act (IPA) (5 ILCS 179/1, et seq.)
Illinois Personal Information Protection Act (PIPA) (815 ILCS 530/1)

Information Security Breach (Policy 75)

Policy Categories

Information Technology Policies

Policy Owner/Department

Information Technology Services

December 16, 2013, February 22, 2016, May 9, 2016, May 16, 2016

Information and Systems Access Policy

lhendrickson@govst.edu — Sun, 29 Mar 2026 20:04:34 +0000

Information and Systems Access Policy

Purpose
The Director - Applications Development in the Information Technology Services Department is responsible for the administration of access to data and the Colleague@ Enterprise Resource Planning system. An important part of this duty is ensure that only persons duly authorized have access, and to ensure that access is removed when it is no longer needed.
Best practices in Information Technology dictate that access should be guided by set policies and established procedures to ensure consistent enforcement and proper management of University resources.
Definitions
1. Employee: A person employed by ��Ƶ (��Ƶ) in any capacity (faculty, staff, student worker) for any period of time (part-time, full-time, contract). Employees are responsible for requesting access and notifying changes in roles and separation from ��Ƶ to their supervisor.
2. Supervisor: Person in charge of a University unit or department with the role of approving user access requests, and notifying ��Ƶ about employee separations and role changes in their units.
3. Human Resources Department: Department in charge of managing human resource relations and processes. The role of the Human Resources (HR) Department is to notify the Information Technology Services (ITS) department when an employee separates or changes positions.
4. Data Custodians: Persons responsible for key functional units of the institution. The role of the data custodian or their designee is to approve/reject access requests to their respective functional modules. Data Custodians are authorized approvers who are typically unit heads whereupon a full list of Data Custodians can be found on the "Information Systems Access Procedures" on the portal.
5. CORE Data Custodian: Individual responsible for common core part of the system as defined in the "Information Systems Access Procedure" on the myGSU portal.
6. Information Technology Services Department: The Information Technology Services (ITS) Department is the functional unit of the institution that manages systems access and is in charge of processing access requests submitted by users, approved by supervisors, and endorsed by data custodians. ITS also terminates access upon notification from HR about a role change or a separation.
7. FERPA: Family Educational Rights and Privacy Act (FERPA) (20 U.S.C. § 1232g; 34 CFR Part 99) is a Federal law that protects the privacy of student education records.
8. IPA: FERPA (20 U.S.C. § 1232g; 34 CFR Part 99) is an Illinois state law seeking to control the collection and use of Social Security Numbers by state and local government agencies.
9. System: Colleague® Enterprise Resource Planning system and associated edge applications provide by Ellucian@ (www.ellucian.com).
10. Access: The ability for a person to retrieve or edit. data from the Colleague@ Enterprise Resource Planning system, using the System's provided user interfaces, third-party interfaces, or by any other means.
Policy
1. User Access Authorization
  ITS has procedures in place to enforce the adherence and compliance with FERPA regulations. Any person requiring access to any GSU system that can contain Education Records or Personally Identifiable Information as outlined by FERPA is required to:
  1. Undergo training covering FERPA rights, responsibilities and regulations.
  2. Provide proof that training was completed.
  3. Submit a written authorization form, signed and approved by their unit/department head for the minimum specific access needed to perform their duties.
  Once all approvals and a (physical) signed form exist, ITS processes the access form and the original requester is notified. Any access requests in addition to existing access must be requested by the user, approved by their unit/department head and by the respective data custodian(s). Access changes due to position or duty changes require a new FERPA authorization request. ITS documents and archives all FERPA requests in a secured, access controlled location.
2. User Access Removal
  ITS receives electronic notifications from HR regarding employees who are separating from ��Ƶ in accordance to the "Information Systems Access Procedure" on the myGSU portal.
  Once ITS receives notification, it processes the removal of access rights to all ��Ƶ systems by the date specified in the separation email. If there are exceptions for extended access or additional time needed, HR will need to notify the Associate Vice President (AVP) of ITS via email so that accommodations are made accordingly.
  ITS may temporarily remove access if there is evidence that an account has been compromised and/or it is being used by an unauthorized person (not the user). User access may also be removed through regular employee access audits conducted by ITS and verified by HR.
3. Employee Termination Access Audit
  ITS performs periodic reviews of users that have access to University systems and records to determine if the employee remains in the role/position that was authorized by their access request form. HR is notified of any exceptions whereupon HR will make corrective actions.
4. Compliance with Illinois Identify Protection Act (IPA - 5 ILCS 179
  ITS has controls in place to restrict who can view or edit Social Security Numbers (SSN). These controls prevent viewing of any (SSN) information by anyone other than those who need the information for the performance of their duties. Authorized use of SSN includes, but are not limited to, administration of Federal Financial Aid programs, management of financial transactions and collections activities by the Financial Services Office, and management of employee and student benefits by Human Resources and the Department of Public Safety. Other users include, but are not limited to, use of SSNs for criminal background checks as performed by authorized parties with appropriate consent, and use by local, state and federal law enforcement agencies in specific cases where a warrant or subpoena is present.
  ITS removes SSNs from all user screens, and blocks or masks their display through internal security processes in Colleague and on reports. Access to SSN information must be requested by the user, approved by the department head, and then approved by the CORE Data Custodian prior to granting access. Access to this information is limited to those who require it to perform their duties and may be revoked when duties or positions change, or at any time by the department head or the CORE Data Custodian.
  The SSN is intentionally excluded from the Operational Data Stores Web Intelligence (WEBI), the database utilized by end users to generate reports and data extracts. If SSN information is needed to submit information to third parties the users must provide their initial file along with a written request to ITS which includes unit head approval, to have the SSN information appended to the file along with justification for the request.
  Reports and data extracts which include SSN information and are created by ITS are made in writing, with unit head approval, which include specifications provided by the receiving party. The results are placed in password protected and encrypted files on a secured location which has limited access for the requestor and ITS.
  In compliance with IPA, ��Ƶ does not utilize SSNs for identification, access, or authentication; nor does it display this number in any publication, document or transmit it through unsecured means. All social security information is transmitted utilizing industry standard strong encryption.
5. Compliance with FERPA (20 U.S.C. § 1232g; 34 CFR Part 99) Provisions
  ITS complies with FERPA regulations by enforcing strict documented controls over who can access Academic Records and Personally Identifiable Information (PII). Access is only granted to those individuals who complete the established authorization process, and is revoked once the person changes duties or leaves the institution.
  The Colleague system tracks and controls who can log into the system, what they can access, and if they can modify any information. This access is controlled by security access classes defined to reflect roles of University employees. Data custodians can grant/deny access to information corresponding to their areas and manage membership to their respective security classes. ITS only adds/removes security classes assigned to users in accordance to properly authorized requests.
  ITS only shares established directory information with third-party vendors acting on behalf of ��Ƶ (contractors) for use in third-party services to students, such as myOneCard (CardSmith) and only to provide services to students.
  ITS also provides notification to all users accessing Colleague about the compliance requirements for FERPA by means of a pop-up message that must be acknowledged prior to accessing the system.
  New hires undergo orientation by ITS staff about FERPA requirements, procedures and about the process required to request access to FERPA protected information.

lhendrickson@g… 03/29/2026

President Elaine P. Maimon

11/02/2018

SEO Summary

��Ƶ's Information and Systems Access Policy establishes procedures for authorized access to university data and systems. Review policy.

FERPA (20 U.S.C. § 1232g; 34 CFR Part 99)
Illinois Identify Protection Act (IPA) - 5 ILCS 179

Information and Systems Access Policy (Policy 80)

Policy Categories

Information Technology Policies

Policy Owner/Department

Information Technology Services

Information Security Policy

lhendrickson@govst.edu — Fri, 27 Mar 2026 18:14:02 +0000

Information Security Policy

Purpose
��Ƶ (“��Ƶ” or the “University”) understands the value of information and data to its continued success.
��Ƶ understands its responsibility to its students, faculty, staff, and community members to secure the data that it collects, stores, and processes.
��Ƶ understands that fostering a security-minded culture and implementing sound, risk-informed controls will minimize risks from both internal and external threats that could cause operational, financial, and reputational harm to the University and ultimately compromise its ability to fulfill its mission.
��Ƶ understands its responsibility to comply with regulatory, legal, and industry requirements concerning information security.
As such, this Policy establishes the University’s Information Security Program and outlines the security principles that demonstrate how it ensures the confidentiality, integrity, and availability of information and data that it stores, maintains, processes, or for which it is otherwise responsible.
The Information Security Program is comprised of the policies, standards, and procedures that describe the requirements and supporting controls needed to protect University data and systems and satisfy applicable regulatory and legal obligations. Information security requirements and controls shall be chosen based on the expertise of technical and security staff, information security best practices, appropriate frameworks such as the NIST Cybersecurity Framework, legal and regulatory mandates, and the mission, needs, resources, and risk tolerance of the University.
The Information Security Policy reflects ��Ƶ’s acknowledgement of the threats to information security and the importance of protecting the data and information of the University community. This Policy is effective the date of approval but will be implemented in phases given the scope and complexity of the required efforts and continually changing security landscape.
Definitions
1. Individuals - Any person that accesses or consumes technology services (data, systems, printers, and other resources) provided by the University.
2. Technical controls – A type of security control primarily implemented and executed by an information technology or system through mechanisms contained in hardware, software, or firmware components.
3. Administrative controls – Administrative actions, policies, and procedures to manage the selection, development, implementation, and maintenance of security countermeasures to protect sensitive information and manage the conduct of an individual’s actions with the use of data or technology.
4. Physical controls – Physical measures to protect an information asset and related buildings and equipment from both natural and environmental hazards and unauthorized access.
5. National Institute of Standards and Technology (NIST) – Science laboratory and non-regulatory agency of the United States Department of Commerce, which develops and promotes standards and best practices to be used by private and public sectors.
6. Asset – Hardware, software, service, platform, or any other IT resource that requires controls for the enforcement of confidentiality, integrity, and availability.
7. Security Incident - A specific event or correlated set of events that has either compromised or has the potential to compromise the confidentiality, integrity, or availability of GSU’s information, systems, or data.
Information Security Policy
1. Scope
  This policy applies to the entire ��Ƶ community, including President, Vice Presidents, Deans, Directors, and Department Heads along with students, faculty, staff, administrators, alumni, trustees, temporary employees, contractors, volunteers, and guests who have access to University data and who use information technology services provided by GSU unless expressly excepted.
2. Responsibilities
  1. The Director of Information Security and Compliance leads University Information Security and Compliance efforts as part of the Information Technology Services (“ITS”) department and shall:
    1. Exercise authority and responsibility delegated by the Chief Information Officer (“CIO”) for the Information Security Program.
    2. Recommend information security policies, procedures, and standards to protect data and technology resources.
    3. Review and approve information security standards.
    4. Establish a process to submit requests for and review exception requests to this Policy and related standards.
    5. Review and approve exceptions to information security policies and standards.
    6. Review and manage University information security incidents, including but not limited to providing notice thereof to all appropriate parties.
    7. Provide reasonable assistance or guidance to units and individuals in their efforts to comply with this Policy and other University information security efforts.
  2. Information Security relies on the collective efforts of all University community members.
    1. Individuals shall:
      1. Ensure that their actions with respect to University data and systems adhere to this Policy, as well as any applicable standards, laws, regulations, and contractual obligations.
      2. Report known or reasonably suspected non-compliance to the Director of Information Security and Compliance or Chief Information Officer as soon as practicable.
    2. Unit leaders and administrators shall, in addition to their responsibilities as individuals:
      1. Exercise responsibility for their unit’s adherence to this Policy, as well as any applicable standards, laws, regulations, and contractual obligations as applicable their unit and the data, systems, and applications under the control of their unit.
    3. Application and system owners shall, in addition to their responsibilities as individuals:
      1. Exercise responsibility for adherence to this Policy, as well as any applicable standards, laws, regulations, and contractual obligations as applicable to the data, systems, and applications under their control.
  3. Information Security Program
    The Information Security Program is divided into the following functional categories.
    1. Governance, Risk, Compliance
      1. Information Security Program management
        The Information Security Program is managed by the Director of Information Security and Compliance as part of the ITS department.
      2. Risk Management
        All information security decisions and actions are intended to address risks and the University understands the importance of identifying and managing risks in order to make informed decisions and take appropriate action. ITS engages in risk management activities and shall adopt a formal Risk Management Process to further guide robust risk management activities.
      3. Internal Security and Compliance Audit
        To help ensure compliance with and effectiveness of established security policies, standards, and procedures, an Internal Security and Compliance Audit process shall be adopted.
      4. Data Classification
        The classification of information is essential to derive the sensitivity and criticality of information that is transmitted, stored, or processed by ��Ƶ. The classification system provides the basis for defining appropriate protection methods. The Data Classification Policy and Data Handling Policy shall establish criteria necessary for appropriate data security.
      5. Compliance
        The University is required to comply with certain regulations and accreditation standards. Controls, policies, standards, and processes shall be adopted for each regulation as required.
      6. Change Control
        ITS conforms to an established change control process to maintain system and data integrity and availability. This process ensures that any changes to a production system are formally approved to minimize problematic or unauthorized changes. A formal policy shall be adopted to accompany the established process.
    2. Operational Security
      1. Identity and Access Management
        Identity and Access Management (“IAM”) ensures the proper identification, authentication, and authorization of individuals that are granted access to the technology resources of the University based on the following core principles:
        Ensure that each individual is uniquely identified for proper management of access privileges and appropriate level of activity monitoring.
        Grant access to technology resources based on the Principle of Least Privilege.
        Build a process for periodic compliance reviews to validate access is appropriate and acceptable according to University policies.
        Extend the current authorization capabilities across current and future service platforms.
        Build and document an account lifecycle management program, ensuring user accounts are created, suspended, and removed according to a defined ruleset.
        The goal of access control is to manage access to technology resources based on need in order to maintain the confidentiality, integrity, and availability of those resources. The process to manage access control is reflective of the core foundational requirements that include identification, authentication, and authorization. An IAM Policy shall be adopted to prescribe consistent practices across all systems, and will additionally include provisions for remote access, privileged access, and segregation of duties.
      2. System and Network Security
        Technology assets require network connectivity to communicate with other systems internal and external to ��Ƶ. Attacks against the network and connected systems have the potential to cause significant harm to the University including by compromising information, limiting system availability, and subjecting the University to ransomware. To mitigate and limit the effectiveness of such attacks, security controls shall be deployed throughout the environment, which may include monitoring and blocking technologies such as firewalls and intrusion detection systems.
        Furthermore, ��Ƶ shall build and maintain configuration standards for all technology assets with networking capabilities, and/or which otherwise may store or process data.
      3. Vulnerability and Patch Management
        Vulnerabilities are known and unknown weaknesses or deficiencies within a server, platform, or application that have the potential to be exploited by malicious actors. The exploitation of such vulnerabilities could create significant financial and reputational harm to the University through the scenarios such as ransomware attacks or the exfiltration or compromise of sensitive information.
        To limit the potential exposures as outlined above, ITS shall develop processes that outline routine vulnerability scans of all applicable servers, platforms, and applications in order to provide a comprehensive list of the known vulnerabilities throughout the operating environment. The vulnerabilities identified shall be ranked based on the criticality of the potential exposure and/or susceptibility of potential compromise.
        As vulnerabilities are discovered, they are often remediated or mitigated by patches and updates released by the vendor or manufacturer. Timely installation of such security patches is critical to ensuring the security of GSU’s systems, and the University shall develop and comply with a formal update and patch management process for each of the following areas:
        Servers;
        Desktops and laptops;
        Mobile devices;
        Network infrastructure devices;
        Applications; and
        All other Network-connected devices that do not fall into an existing category (security cameras, IP phones, HVAC and lighting, etc.).
      4. Application Security
        Although the University does not currently develop its own applications, modifications to existing systems may still present an opportunity for increased risk. Additionally, as automation becomes increasingly important and commonplace, scripts present similar opportunities for increased risk.
        To help prevent unnecessary risk, the University shall develop and implement a code review process. All code implemented by the University shall be subject to this process.
        Addressing the security of an information system or application within all stages its lifecycle is critical to ensure that:
        All security requirements are compliant with the University’s governance policies.
        Information that is sensitive is properly protected throughout its lifecycle.
        The deployment of consistent and appropriate level of controls (i) limit the introduction of new risks during system maintenance and (ii) ensure proper removal of the system and residual data upon decommission of the application.
        To ensure security is considered throughout the lifecycle of an application, the University shall adhere to the seven phases of the System-Development Life Cycle (“SDLC”). The minimum level of security requirements must be followed within each stage to ensure a proper level of due diligence:
        Planning – Define the scope of the application and service. Level of security commitments required are identified and documented.
        Systems Analysis and Requirements – Define functional requirements of the application or service. Type of information consumed is identified and evaluated.
        Systems Design – Details the specifications, features, and operations that satisfy the functional requirements. Security control requirements are discussed and addressed.
        Development – Development efforts begin. Applications are developed to secure the data identified in the phases above. In the case of cloud-based solutions, verification of how the provider maintains the security is validated and documented.
        Integration and Testing – Systems integration and system testing is conducted. Security is capabilities are confirmed and quality assurance is completed.
        Implementation – Application or service is used in production. Security control monitoring mechanisms are deployed.
        Operations and Maintenance – Fine-tuning activities – performance improvements, upgrades, patches. All activities conducted in this phase must follow the University’s change control policies and procedures to limit risk-induced problems (misconfigurations, system or service availability, etc.).
      5. Incident Management and Response
        A Security Incident Response Plan is critical to enable rapid mitigating and investigatory actions upon becoming aware of a potential security incident. The proper response and handling of such incidents helps reduce its impact and integrates continual improvement measures over time.
        The University shall adopt a Security Incident Response Plan focused on rapid response and supporting triage activities.
      6. Detection and Monitoring
        Detection and monitoring refer to mechanisms used to improve necessary visibility and event tracing required to detect threats and confirm the validity and effectiveness of the security controls deployed throughout the network and computing environment.
        As these are key foundational components to effective information security operations and effective incident investigation and response, the University shall build processes and standards to ensure that appropriate detection and monitoring is in place and functional, and that appropriate systems, activities, and data are within scope.
      7. Data and Communications Security
        To ensure the confidentiality and integrity of information stored, processed, or communicated by the University, a Data Classification Policy has been established, and a Data Handling Policy is planned. The Data Handling Policy will outline how data in classification should be stored, transmitted, processed, and destroyed.
      8. Disaster Recovery
        A disaster recovery plan is a set of documentation and procedures to ensure the proper and efficient resumption of critical services that support the daily operations of the University based on an unforeseen or unexpected interruption of the systems and resources.
        ��Ƶ currently has established a robust disaster recovery process which is tested semi-annually. A formal policy is planned to accompany these processes.
      9. Training and Awareness
        A formal training and awareness policy shall be adopted to accompany and build upon existing yearly information security training exercises. This policy will outline the necessity and coverage areas, and other requirements of ��Ƶ’s Information Security Awareness and Training efforts.
      10. Information Asset Management
        A full and comprehensive accounting of information assets is necessary for effective security efforts. An Information Asset Management Policy shall be adopted outlining the need to assemble and maintain a comprehensive inventory of the following information asset types.
        Hardware;
        Virtual machines;
        Network shares;
        Storage media;
        Applications;
        Cloud services; and
        Vendors and service providers.
  4. Exemptions and Risk Acceptance
    Although rare, exemptions to information security policies and processes may be necessary to carry out the mission of the University. A formal exemption policy and process shall be adopted to allow individuals to formally request an exemption and allow for the approval or rejection of the request based on specified criteria.
  5. Enforcement
    Any individual that accesses or consumes University data or information technology resources provided by the University shall be required to comply with all applicable laws and regulations, and policies and procedures developed in accordance with ��Ƶ’s information security efforts. Any individual with who engages in unauthorized use, disclosure, alteration, or destruction of University data will be in violation of the Information Security Policy and will be subject to appropriate disciplinary action, up to and including termination and/or legal action

lhendrickson@g… 03/27/2026

President Cheryl Green

05/01/2023

SEO Summary

��Ƶ's Information Security Policy establishes standards for protecting institutional data and systems against internal and external.

Data Classification

Information Security Policy (Policy 92)

Policy Categories

Information Technology Policies

Policy Owner/Department

Information Technology Services

Backup and Disaster Recovery

lhendrickson@govst.edu — Wed, 25 Mar 2026 21:45:36 +0000

Backup and Disaster Recovery

Purpose
Data backups and disaster recovery planning are essential to re-establish the normal operations of the University’s identified production enterprise systems in the event of a disaster, data breach, or other extended interruption. Compliance with this policy will help ensure that critical University data and systems are able to be restored when needed.
Definitions
1. Replication – In the context of ��Ƶ’s backup and disaster recovery processes, replication is the act of copying data to the University’s disaster recovery site at Illinois State University.
2. Disaster – Any situation that presents the possibility of an extended outage or interruption of University identified systems or data.
3. ERT – The Emergency Response Team is responsible for declaring and reacting to University emergencies.
Policy
1. Scope
  This policy applies to identified Enterprise-wide University systems and data as classified in this policy.
2. Responsibilities
  All system and application owners are responsible for the data under their purview, including ensuring for appropriate backup, recovery, and operational continuity, and for developing associated procedures.
3. System And Data Classification
  For the purposes of backups and disaster recovery, systems and data shall be classified per the Disaster Recovery System Classification Standard.
4. Backup and Replication
  University-hosted systems and data shall be backed up and/or replicated to the University’s remote disaster recovery site as directed by their classification in the Disaster Recovery System Classification Standard.
5. Disaster Recovery
  The University has established and shall maintain a disaster recovery process to ensure that University-hosted systems are able to be restored in the event of an extended outage or disaster. The process is documented in the Disaster Recovery Run Book and is updated at least semi-annually.
6. Testing
  Using a mock disaster exercise, the disaster recovery process is tested semi-annually against the Disaster Recovery Run Book. Results of each test is recorded and the Run Book is updated as necessary based on the results of the test.

lhendrickson@g… 03/25/2026

President Cheryl Green

06/01/2023

SEO Summary

��Ƶ's Backup and Disaster Recovery Policy (Policy 93) ensures critical data and systems are protected and recoverable during emergencies.

Backup and Disaster Recovery (Policy 93)

Policy Categories

Information Technology Policies

Policy Owner/Department

Information Technology Services

Identity Protection Policy

lhendrickson@govst.edu — Tue, 24 Mar 2026 03:15:05 +0000

Identity Protection Policy

PURPOSE
As mindful stewards of the data of the University community, and in compliance with the Illinois Identity Protection Act (5 ILCS 179), ��Ƶ (��Ƶ) establishes this policy to protect the social security numbers of individuals.
DEFINITIONS
"Publicly post" or "publicly display": To intentionally communicate or otherwise intentionally make available to the general public.
PROHIBITIONS ON THE COLLECTION, USE, AND DISCLOSURE OF SOCIAL SECURITY NUMBERS AT ��Ƶ.
1. The University or anyone acting on behalf of the University are prohibited from the following except where specifically allowed by 5 ILCS 179.
  1. Publicly posting or displaying any individual’s social security number.
  2. Printing social security numbers on access cards or identification cards.
  3. Requiring an individual to transmit an unencrypted social security number over the Internet, or transmit their social security number over an unencrypted connection.
  4. Sending a social security number via postal mail or electronic mail or other similar method of delivery.
  5. Collecting, using, or disclosing a social security number unless
    1. required to do so under State or federal law, rules, or regulations, or the collection, use, or disclosure of the social security number is otherwise necessary for the performance of that agency's duties and responsibilities,
    2. the need and purpose for the social security number is documented before collection of the social security number, AND
    3. the social security number collected is relevant to the documented need and purpose.
  6. Requiring an individual to provide their social security number in order to access a web site.
  7. Using a collected social security number for any other purpose than the one for which it was collected.
2. ��Ƶ may collect, use, or disclose social security numbers under the following circumstances or situations:
  1. The disclosure of social security numbers to agents, employees, contractors, or subcontractors of a governmental entity or disclosure by a governmental entity to another governmental entity or its agents, employees, contractors, or subcontractors if (1) disclosure is necessary in order for the entity to perform its duties and responsibilities and if (2) disclosing to a contractor or subcontractor, prior to such disclosure, the governmental entity must first receive from the contractor or subcontractor a copy of the contractor’s or subcontractor’s policy that sets forth how the requirements imposed under the Illinois Identity Protection Act on a governmental entity to protect an individual’s social security number will be achieved.
  2. The disclosure of social security numbers pursuant to a court order, warrant, or subpoena.
  3. The collection, use, or disclosure of social security numbers in order to ensure the safety of:
    1. State and local government employees;
    2. Persons committed to correction facilities, local jails, and other law-enforcement facilities or retention centers;
    3. Wards of the State; and
    4. All persons working in or visiting a State or local government agency facility.
  4. The collection, use, or disclosure of social security numbers for internal verification or administrative purposes.
  5. The disclosure of social security numbers by ��Ƶ to any entity for the collection of delinquent child support or of any State debt or to a governmental agency to assist with an investigation or the prevention of fraud.
  6. The collection or use of social security numbers to investigate or prevent fraud, to conduct background checks, to collect a debt, to obtain a credit report from a consumer reporting agency under the federal Fair Credit Reporting Act, to undertake any permissible purpose that is enumerated under the federal Gramm-Leach-Bliley Act, or to locate a missing person, a lost relative, or a person who is due a benefit, such as a pension benefit or an unclaimed property benefit.
  7. Social security numbers that are requested by ��Ƶ from an individual must be placed on records/documents or stored in a manner that makes the social security number easily redacted if required to be released as part of a public records request. If there is a request to inspect or copy records under the Illinois Freedom of Information Act or any other federal or state law, the University must redact social security numbers from the information or documents before allowing inspection or copying.
  8. When collecting a social security number, or when requested by an individual, the University must provide a statement describing the purpose for which the social security number is being collected.
  9. Only those ��Ƶ employees requiring access to social security numbers as part of their job duties shall be granted access to social security numbers.
  10. Any ��Ƶ employee that requires access to social security numbers will be trained to protect the confidentiality of social security numbers.

lhendrickson@g… 03/23/2026

President Cheryl Green

03/04/2022

SEO Summary

��Ƶ protects personal information and social security numbers under Illinois Identity Protection Policy 88. Learn our data protection.

Illinois Personal Information Protection Act (815 ILCS 530)

Identity Protection Policy (Policy 88)

Policy Categories

Information Technology Policies

Policy Owner/Department

Information Technology Services

Payment Card Security

lhendrickson@govst.edu — Mon, 23 Mar 2026 22:04:09 +0000

Payment Card Security

Policy Statement
��Ƶ is committed to establishing appropriate security controls and
ensuring compliance with the Payment Card Industry Data Security Standard (PCI DSS), helping
to protect payment card information and ensuring the security of transactions.
Purpose
The Payment Card Industry Security Standards Council (PCI SSC) has developed a set of security standards (the Payment Card Information Data Security Standard or “PCI DSS”) to protect payment card information. PCI DSS governs all merchants and organizations that collect, process, store, or transmit credit card information. As an agency of the State of Illinois, the University is required to comply with PCI DSS. This Policy outlines the requirements for safeguarding payment card information and complying with PCI DSS.
Scope
All individuals, departments, and groups that handle cardholder data or use or maintain in scope systems must comply with this Policy.
Roles and Responsibilities
Individuals are required to comply with the components of this Policy as applicable.
Credit and Source
This Policy was developed internally.
Definitions
1. Cardholder - Non-consumer or consumer customer to whom a payment card is issued or any individual authorized to use the payment card.
2. Cardholder Data Environment (CDE) - The people, processes and technology that store, process, or transmit cardholder data or sensitive authentication data. These, along with any system that connects to or can affect the security of the CDE, are referred to as “in-scope.”
3. Card Not Present (CNP) Transactions - Cardholder is not physically present at the point of sale. These transactions occur online, over the phone, or through mail order, requiring the use of card information (such as card number, expiry date, and security code) provided by the cardholder to complete the transaction.
4. Card Validation Code 2 (CVC2) – For MasterCard payment cards. A three or four-digit code that is used to verify the authenticity of a credit card.
5. Card Verification Value 2 (CVV2) – For Visa payment cards. A three or four-digit code that is used to verify the authenticity of a credit card.
6. Card Identification Number (CID) – For American Express and Discover payment cards. A three or four-digit code that is used to verify the authenticity of a credit card.
7. E-commerce - Buying and selling goods and services online.
8. EMV – Global standard for secure payment transactions. Commonly referred to as the “chip” that provides enhanced security features, reducing the risk of card fraud.
9. Encryption - Rendering data unreadable except to holders of a specific cryptographic key.
10. Magstripe - Short for magnetic stripe, is the thin strip on the back of a payment card that contains encoded information. It is used for card authentication and data storage, allowing the card to be swiped through a magnetic stripe reader for transaction processing.
11. Merchant - For the purposes of the PCI DSS, a merchant is defined as any entity that accepts payment cards bearing the logos of any of the five members of PCI SSC (American Express, 2 Discover, JCB International, MasterCard Worldwide or Visa, Inc.) as payment for goods and/or services.
12. NFC (Near Field Communication) - Short-range wireless technology used for contactless communication between devices, utilized for secure and convenient contactless payments.
13. Patch - Update to existing software to add functionality or to correct a defect.
14. Payment Card - For purposes of PCI DSS, any payment card/device that bears the logo of the founding members of PCI SSC, which are American Express, Discover Financial Services, JCB International, MasterCard Worldwide, or Visa, Inc.
15. Payment Application - Any application that stores, processes, or transmits cardholder data as part of authorization or settlement.
16. Payment Card Information/Cardholder Data (CHD) - At a minimum, this type of data consists of the full Primary Account Number (PAN) and may also appear in the form of the full PAN plus any of the following: cardholder name; expiry date; and/or service code.
17. Point-to-Point Encryption (P2PE) – PCI-DSS Point-to-Point Encryption: a solution that cryptographically protects account data from the point where a merchant accepts the payment card to the secure point of decryption.
18. Primary Account Number (PAN)/Account Number - Unique payment card number (typically for credit or debit cards) that identifies the issuer and the particular cardholder account.
19. Personal Identification Number (PIN) - Secret numeric password known only to the user and a system to authenticate the user to the system. The user is only granted access if the PIN the user provides matches the PIN in the system.
20. Point of Sale (POS) or Payment Terminal - A hardware device and/or software used to process payment card transactions at merchant locations.
21. Self-Assessment Questionnaire (SAQ) - Tool used by any entity to validate its own compliance with the PCI DSS.
22. Sensitive Authentication Data (SAD) - Security-related information (including but not limited to card validation codes/values, full track data (from the magnetic stripe or equivalent on a chip), PINs, and PIN blocks) used to authenticate cardholders and/or authorize payment card transactions.
Policy
1. Security Incidents
  Any suspected or actual incident relating to a breach of payment card information including but not limited to unauthorized disclosure, unsecure transmission, tampering of devices or substitution, impersonation, theft, fraud, or any other activity that could negatively impact the cardholder or the University must be reported to the ITS Helpdesk immediately.
2. Attestation of Compliance
  1. Each University merchant is required to complete the relevant PCI DSS Self-Assessment Questionnaire (SAQ) yearly and must satisfy the related requirements to remain compliant with PCI DSS. The Information Security and Compliance Office will guide each merchant through this process unless otherwise noted.
  2. Any modifications to in-scope devices, networks, software, services, or processes must follow the ITS change management process and may require the completion of a new SAQ.
3. Payment Processors
  The University’s preferred payment processor must be used unless another processor is explicitly approved. Requests to use a non-preferred payment processor must be approved in writing by each of the following University offices prior to entering into an agreement and must be reviewed yearly thereafter:
  1. Finance
  2. Procurement
  3. ITS
  4. Information Security
4. Payment Terminals
  1. Payment terminals must be part of a P2PE solution offered by an approved payment processor and must be P2PE compliant.
  2. Payment terminals may not be purchased or replaced without approval by each of the following University offices:
    1. Finance
    2. Procurement
    3. ITS
    4. Information Security
  3. An inventory of payment terminals must be maintained and verified at least yearly. The inventory must contain at least:
    1. Make and model of the devices
    2. Location of the devices
    3. Device serial number or other methods of unique identification
  4. Payment terminals may only use vendor-supported operating systems and applications and all security patches must be installed within 30 days of release.
5. ECommerce Sites
  1. The University’s preferred e-commerce solution (uPay) must be used to accept online payments unless another e-commerce solution is explicitly approved.
    1. Requests to use an alternate must be approved in writing by each of the following University offices prior to entering into an agreement and must be reviewed yearly thereafter:
      1. Finance
      2. Procurement
      3. ITS
      4. Information Security
    2. E-commerce solution providers must provide evidence of current PCI DSS compliance prior to entering into an agreement and yearly thereafter.
    3. E-commerce solution providers must provide a PCI DSS responsibility matrix prior to entering into an agreement and yearly thereafter.
  2. Groups who wish to accept online payments may request a uPay site from ITS.
6. Alternative Solutions
  1. The use of any unauthorized devices, software, or services to accept payments or store or process CHD is prohibited.
  2. The use of P2PE solutions and uPay sites dramatically reduces the amount of time, effort, and resources required to implement and maintain a PCI DSS compliant payment solution. Merchants that opt to use an alternate solution may be responsible for any additional expense required for implementation and ongoing maintenance and may be required to accept full responsibility for ensuring compliance with PCI DSS.
7. Third-Party Service Providers
  1. The use of any third-party service providers that store or process cardholder data, including payment processors, must be explicitly approved in writing by each of the following University offices:
    1. Finance
    2. Procurement
    3. ITS
    4. Information Security
  2. Agreements with all third-party service providers that store or process cardholder data must explicitly require that the service provider provide supply the following:
    1. Evidence of current PCI DSS compliance prior to entering into an agreement and yearly thereafter.
    2. A PCI DSS responsibility matrix prior to entering into an agreement and yearly thereafter.
8. Handling Account Data
  1. Payment card information may only be used for the purpose for which it has been provided by the cardholder. Violations of this policy may result in discipline, up to and including termination.
  2. Except as otherwise provided herein, payment card information such as the PAN, PIN, CVC2, CVV2, or CID, or Sensitive Account Data may not be stored in any form, digitally (on any computer or University network) or on paper after a payment is authorized. Account data shall be securely deleted when no longer needed.
  3. The last four digits of the PAN may be stored for record purposes and audit trail.
  4. No system or device may transmit or store CHD in any unencrypted manner.
  5. University employees may not handle a customer’s payment card.
  6. University employees may not handle mobile devices of customers wishing to use contactless payments with Apple Pay, Google Pay, or other contactless payment app.
  7. Card Not Present Transactions
    1. Manual entry of cardholder data is not permitted except when entered directly by the customer onto an approved e-commerce site.
    2. Acceptance of non-functioning or damaged payment cards is not permitted.
    3. Telephone payment card transactions are not permitted.
    4. Mail order payment card transactions are not permitted.
  8. EMV Transactions
    EMV compatible payment cards contain a chip that establishes a secure connection with the payment terminal when inserted. EMV compatible cards should only be processed by inserting (dipping) the card into the chip card slot or reader.
9. Personnel
  1. All employees who handle payment card information:
    1. Must participate in the annual security awareness training provided by the University.
    2. Must participate in PCI DSS training provided by the University and formally acknowledge their responsibilities as stated within this policy annually. The annual security awareness training and PCI DSS training will be administered by the Information Security and Compliance Office, which will adopt procedures with which University merchants can identify those employees who must complete the trainings.
  2. All employees who use payment terminals:
    1. Must be trained to be aware of suspicious behavior and to report any tampering or substitution of devices.
    2. Must verify the identity of any third-party persons claiming to be repair or maintenance personnel prior to granting access to modify or troubleshoot devices.
    3. May not install, replace, or return devices without authorization.
    4. Must ensure payment terminals are physically secured when not in use.
  3. Employees who have not taken the appropriate cybersecurity training and PCI DSS training within the last 12 months may not handle cardholder data or use any in-scope systems.
10. Infrastructure
  1. Dedicated Network
    1. All systems considered in-scope for each University merchant (including but not limited to payment gateway devices, workstations, card readers, servers, applications, databases, etc.) must be hosted and operated only on an isolated network or VLAN dedicated for card payment operations unless the systems are P2PE compliant.
    2. Only explicitly allowed traffic may enter or leave the dedicated network.
    3. Physical and/or logical controls must be implemented to restrict access to network jacks that are part of the dedicated network.
  2. Software
    1. All in-scope devices must be updated per the University’s patch management processes plus any supplemental PCI DSS requirements.
    2. Where possible, all in-scope devices must have antivirus software installed and must be patched regularly to maintain vendor-supported operating systems and applications.
  3. Access
    1. Where practical, a lock screen must be enabled on devices used for card payment operations when users are away from the devices.
    2. All default system passwords and other security parameters must be changed and unnecessary default accounts must be removed prior to the system being used.
    3. Access and permissions to in-scope systems may be granted only as required for an individual’s job function.
    4. User access must be terminated immediately when it is no longer required or when employment ends.
    5. A monthly audit of user access and associate permissions for in-scope devices must be performed and documented by the merchant.
    6. Passwords for in-scope devices must comply with the University’s password policy plus any additional PCI DSS requirements.
  4. Audit logs
    1. Audit logs must be kept for all in-scope systems and software that are not P2PE compliant.
    2. Audit logs must be retained for at least one year with a three-month record immediately available for analysis. Where applicable, the audit trail/log should contain the following:
      1. User identification
      2. Type of event
      3. Date and time
      4. Success or failure indication
      5. Origination of event
      6. Identity or name of affected data, system components, or resources.
  5. Change detection
    For non-P2PE systems, mechanisms must be implemented to detect unauthorized modification of critical system files, configuration files, or content files. The change detection mechanism must alert the appropriate personnel to investigate.
  6. P2PE Implementation Manuals
    P2PE service providers will provide a P2PE Implementation Manual (PIM). Merchants must comply with any rules established by the service provider within the PIM.
PCI DSS Precedence
Although intended to be comprehensive, some requirements established by PCI DSS may not be included in this Policy. Additionally, PCI DSS may change or add requirements that are not immediately reflected in this Policy. In such cases, and in cases where PCI DSS imposes stricter requirements than University policies, the PCI DSS requirements must take precedence.

lhendrickson@g… 03/23/2026

President Cheryl Green

05/09/2024

SEO Summary

��Ƶ enforces payment card security standards to protect cardholder data and ensure PCI DSS compliance across all departments.

Payment Card Industry Data Security Standard (PCI DSS)

Payment Card Security (Policy 98)

Policy Categories

Information Technology Policies

Business Policies

Policy Owner/Department

Information Technology Services

Email Use Policy

lhendrickson@govst.edu — Sun, 22 Mar 2026 20:15:42 +0000

Email Use Policy

Purpose
��Ƶ (“��Ƶ” or the “University”) provides email services as a tool to facilitate communication in service to its mission. The purpose of this policy is to augment and supplement other University policies, to describe permitted uses of University email, and to describe when certain email features are required to be used.
Compliance with this Policy is essential to improving email communications, ensuring the security and privacy of University data, protecting the University’s reputation, and ensuring compliance with established regulations and legal and other obligations.
Definitions
1. Communication Devices – refers to ��Ƶ-owned devices, such as cell phones and computers, as well as to email servers or systems.
2. Email – Communications, including but not limited to messages and attachments thereto, distributed via electronic means using an Official Account or other account maintained by ��Ƶ such as a group account.
3. Freedom of Information Act (FOIA) – Illinois statute (5 ILCS 140/1 et seq.) regarding the definition, handling, and disclosure of public records.
4. Information Security – Actions, rules, and controls that serve to protect the confidentiality, integrity, and availability of data.
5. ITS – The ��Ƶ Office of Information Technology Services.
6. Malware – Any unauthorized computer application which serves a nefarious purpose. Viruses and spyware are examples of malware.
7. Official Email Account – A Microsoft 365 email account assigned to an individual User or group of Users by ��Ƶ.
8. Public Records – Shall have the meaning ascribed in the Illinois State Records Act, as it may be amended from time to time and as now includes Email:
  made, produced, executed, or received by any agency in the State in pursuance of State law or in connection with the transaction of public business and preserved or appropriate for preservation by that agency or its successor as evidence of the organization, function, policies, decisions, procedures, operations, or other activities of the State or of the State Government, or because of the informational data contained therein. Library and museum material made or acquired and preserved solely for reference or exhibition purposes, extra copies of documents preserved only for convenience of reference, and stocks of publications and of blank forms are not included within the definition of records as used in this Act.
9. User – A person assigned a GSU email account, including but not limited to University employees (current and, where permitted to retain it, former/retired employees), students, third party contractors, and any other person granted a GSU email account address.
10. Other Capitalized Terms used herein shall have the meaning ascribed to them in 89 – Data Classification.
Policy
1. Scope
  1. It is the responsibility of all Users to review and follow all University policies. Failure to comply with this policy may result in disciplinary actions, up to and including termination, costly data breaches, breach of privacy expectations, and damage to the University’s reputation.
  2. ��Ƶ provides Official Email Accounts via the Microsoft 365 service using the govst.edu and student.govst.edu domains. Third party services and applications may be configured to send email using ��Ƶ domains with appropriate approval, which shall be contingent upon compliance with this Policy as though such email were sent from an Official Account.
  3. All Users are subject to this policy when utilizing an Official Email Account to send or receive email or when using a Communication Device to text, to receive voicemail, or to send or receive email via an Official Email Account.
2. Privacy of Email
  1. Email is subject to search, review, and production, including to third parties, for any number of reasons, including but not limited to searches: in response to litigation discovery requests, a subpoena, or civil investigative demand; in response to an internal or external complaint, inquiry, or investigation into University operations; in response to a FOIA request; and in connection with an internal investigation of reported or suspected wrongdoing.
  2. Users have no expectation of privacy when using an Official Email Account or Communication Devices to send or receive emails from an Official Email Account, to send or receive texts from a Communication Device, or to receive voicemails on a Communication Device, nor do Users have an expectation of privacy in account records (e.g., call logs) relating to Communication Devices.
  3. Use of a password or encryption for an Official Email Account, or on a Communication Device does not create an expectation of privacy and does not diminish the public nature of ��Ƶ emails or of texts or voicemails stored, sent, or received using a Communication Device.
3. Official Email and Acceptable Use
  1. All students and employees of the University are assigned an Official Email Account. University business conducted via email shall be transmitted only via an Official Email Account. Employees shall not use any personal or non-��Ƶ issued email account for ��Ƶ business or to transmit University data. Emails inadvertently sent to or from an employee’s non-��Ƶ email account regarding ��Ƶ business shall be forwarded by the User to the User’s official ��Ƶ account as soon as the User discovers the error.
  2. Users are responsible for regularly monitoring their Official Email Account and any Official Email Account for which they are responsible. All Users shall be presumed to have received all Email messages sent to their Official Email Account and are responsible for reading those communications.
  3. Personal use of an Official Email Account is not permitted, except for de minimis use. De minimis use may include occasional, sporadic use that does not interfere or detract from the performance of work responsibilities and is not illegal or in violation of University policy, such as the engagement in prohibited political activity.
  4. Retirees and emeriti are bound by this and other applicable policies, and it is the responsibility of the individual to familiarize themselves with and adhere to applicable policies, standards, and procedures.
  5. Special-use and department email accounts and email aliases may be requested by submitting a ticket at help.govst.edu or sending an email to help@govst.edu.
4. Email That Constitutes University Records
  1. Email may constitute a public “record” within the meaning of the Illinois Records Act as it may convey approval or denial of a decision, contain evidence of receipt or expenditure of funds, document the official position of the University, or otherwise evidence the official transaction of the business of the University. Therefore, it is important for Users to identify Emails that constitute Records.
  2. Email may constitute a public “record” within the meaning of the Illinois Records Act as it may convey approval or denial of a decision, contain evidence of receipt or expenditure of funds, document the official position of the University, or otherwise evidence the official transaction of the business of the University. Therefore, it is important for Users to identify Emails that constitute Records. Employee Users are required to preserve Email that constitutes a Record pursuant to the Illinois Records Act and University policy and practice, including the University’s Records Schedules by Department found on the ��Ƶ portal.
5. Transmission of Sensitive Data
  1. Use of Email to communicate Restricted or Internal-Only data (89 – Data Classification) to external third parties are strictly prohibited without the use of email encryption.
  2. It is the responsibility of all Users to review the information on how to use email encryption features. Instructions on the use of encrypted email are available in the ITS Tutorials Library.
  3. It is the responsibility of all Users to review and follow the Information Security Policy, Data Classification Policy, and other applicable policies, standards, and procedures.
6. Email Security
  1. ii. iii. It is the responsibility of all Users to report email incidents to the ITS Office of Information Security. Email incidents include, but are not limited to, all types of phishing attacks, unauthorized access, or changes to an Official Email Account by a third party, accidental data disclosure to unintended parties, and all types of email threats of potential harm to person or property.
  2. Report email incidents by submitting a ticket at help.govst.edu or sending an email to help@govst.edu. Any real or perceived threats to persons or property should be immediately reported to 911 or Campus Police.
  3. Users are encouraged to report phishing and spam using the appropriate tools included in the desktop and web versions of Outlook provided by the University.
  4. Users are required to take any and all mandatory training issued by the University regarding Email (or more generally, data) security. Failure to timely take such training may result in disciplinary action, including but not limited to restricted access to Email and other ��Ƶ systems and termination.
  5. ��Ƶ uses technology systems that scan Email for Malware and sensitive content and enable Users to search their own emails. These systems may present a warning or prevent a message from being sent or received if triggered.
  6. Sharing credentials, including credentials to Official Email Accounts, is strictly prohibited. If multiple users require access to a single email account, delegated permissions must be used.
  7. Email should only be accessed using approved email client software. For Users, currently approved software is limited to Microsoft Outlook for Windows, Mac OS, iOS, and Android, as well as Outlook.com via any supported web browser.
  8. Accessing Email on a personal device should be minimized and may be restricted by other policies.
  9. If used for official University business, or storing or transmitting University data, Communication Devices may have security settings automatically applied, including encryption, authentication requirements, minimum operating system requirements, and the ability for the University to remotely lock and erase the device.
7. Email Forwarding
  1. Manual or automatic forwarding or moving University email that contains non public information as defined by the GSU data classification policy, to any destination, internal or external, other than where it was originally sent is only permissible for valid business purposes and where appropriate security controls such as encryption are in place.
  2. In addition, any records (including emails) that relate to the transaction of University business (i.e. public records) are subject to the Illinois Freedom of Information Act (FOIA), regardless of whether those records are stored in GSU or non-GSU email accounts.
  3. If an employee forwards, transacts, or otherwise transfers their University e mail to non-GSU email accounts, those other accounts become subject to searches in response to FOIA requests.
  4. Routine, automatic email forwarding is discouraged. Please contact ITS to determine if a more appropriate alternative process is available.
8. Email Content Policies
  1. The University’s Department of Marketing and Communications establishes certain requirements regarding the content of Email including:
    1. Standardized rules for the appearance and content of signatures and other email components.
    2. Protocols for complying with accessibility requirements and best practices.
    3. Internal and External mass communications.
  2. Refer to policies, procedures, and standards established by Marketing and Communications, or contact that department for additional information.

lhendrickson@g… 03/22/2026

President Cheryl Green

12/15/2022

SEO Summary

��Ƶ email use policy establishes guidelines for permitted email communications, security requirements, and compliance with data.

Data Classification

Email Use Policy (Policy 91)

Policy Categories

Information Technology Policies

Policy Owner/Department

Information Technology Services

Data Classification

lhendrickson@govst.edu — Sun, 22 Mar 2026 19:44:45 +0000

Data Classification

Policy Statement
Data security is among the most critical activities required to ensure operational continuity, maintain the trust and confidence placed in the University, and meet the University’s legal obligations to maintain the confidentiality of certain data. In turn, ensuring adequate and appropriate confidentiality, integrity, and availability of University data is enabled by an established data classification policy. A data classification policy permits the University to calibrate its data use protections according to the sensitivity of the data at issue. It also permits the University the ability to balance its duty of permitting public inspection of certain information pursuant to the Illinois Freedom of Information Act with confidentiality concerns.
Purpose
This policy serves to establish ��Ƶ’s data classifications. It does not define rules governing the storage, processing, sharing, transmission, disposal, or other handling of data.
Scope
This policy applies to all data for which the University is responsible.
Policy
1. Statement of Policy:
  1. It is the University’s policy to comply with all legal obligations to maintain the confidentiality of certain University Data, while also permitting the reasonable access to and use of data for University business and compliance with laws such as FOIA. In furtherance of its policy, the University hereby adopts a Data Classification system.
  2. While this policy provides examples of Data that meets each Data Classification, it is the responsibility of each University Department to classify Data it regularly stores, processes, or transmits and to ensure that employees within such Department are trained on such Data Classifications and any changes thereto. The exemplar lists contained in this Policy are not intended to be exhaustive. In
    no event shall any Department classify data in a less restrictive manner than required by this policy absent written approval from the University’s Legal, Compliance, or Information Security Offices.
  3. Access to or use of Data for a particular purpose (e.g., disclosure of student records pursuant to a FERPA waiver) shall not necessarily change the Data Classification of said Data; only where Data becomes public due to no fault of the University or its employees or agents would disclosure constitute cause for a change in Data Classification.
  4. In the event that the categorization suggested by this policy conflicts with categorization suggested by another policy, law, contract, or other guidance, the data custodian should err on the side of the more restrictive classification until the data custodian can seek additional guidance for the data custodian’s supervisor or University’s Legal, Compliance, or Information Security Offices.
  5. Failure to classify Data appropriately (or seek guidance in doing so before using or disclosing such Data), and failure to observe Data Classifications, may result in corrective action up to and including termination of employment.
2. University Data Classifications: The University has adopted a three-tiered Data Classification system, which is outlined below from most to least restrictive.
  1. Restricted
    The “Restricted” data classification refers to University Data which could result in serious or potentially irreparable harm to the University or its constituents, including but not limited to its students, alumni, applicants, trustees, employees, and contractual partners, if accessed, disclosed or used in an unauthorized manner. Inappropriate handling of this data could result in criminal or civil penalties to or liabilities of the University, loss of federal or state funding to the University, reputational damage to the University, identity theft, financial loss, or invasion of privacy of the person whose data is at issue (such as a student or employee). The University also may classify certain Data as “Restricted” due to legal, ethical, or contractual obligations, even though such Data does not have the foregoing characteristics. Restricted Data is distinguishable from the other Data Classifications set forth herein because it is kept on a “need to know” basis, even internally.
    Examples of Restricted Data include, but are not limited to:
    1. “education records” as that term is defined by the federal Family Education Rights and Privacy Act (FERPA). (20 U.S.C. § 1232g; 34 CFR Part 99), relating to current or former students or alumni, unless such information is subject to disclosure pursuant to a legal exemption, including but not limited to where express, written consent has been obtained prior to disclosure. If subject to a legal exemption, an education record may be disclosed only consistent with the requirements of such legal exemption; an education record does not otherwise become public because disclosure was permitted pursuant to an exemption. Personnel records relating to any prospective, current, or former employee or employment applicant;
    2. Background checks, including credit check results and criminal record check results;
    3. Applications, or data submitted in support thereof, for accommodations for persons with disabilities;
    4. Applications, or data submitted in support thereof, for leave under the Family and Medical Leave Act (FMLA) (29 U.S.C. §§ 2601 et seq) or similar law, including but not limited to genetic information submitted in support thereof;
    5. Individuals’ personal health information in which the individual has a reasonable expectation of privacy;
    6. Data that would permit access to University accounts, including but not limited to investment and banking accounts, such as bank statements, account numbers, and account passwords, in combination or isolation;
    7. Data relating to the University’s emergency response planning, including response plans;
    8. Data relating to the University’s data security plans, including but not limited to network and system diagrams and configurations;
    9. Data subject to the attorney-client privilege and/or attorney work product doctrine, including but not limited to confidential communications by and between and attorney and client (or representatives of the client) for the purpose of obtaining or providing legal advice;
    10. Government classified information;
    11. Information designated “controlled unclassified information” within the meaning of the National Institute of Standards and Technology, Publication 800-171, V.2, as it may be revised from time to time;
    12. Board of Trustee documents, including meeting minutes, reflecting discussions occurring during closed sessions for so long as they are deemed confidential by the Board of Trustees;
    13. With the exception of information that is otherwise public by lawful means, “personal information” as that term is defined by the Illinois Personal Information Protection Act (PIPA), (815 ILCS 530/1 et seq.), meaning:
      1. the first name or initial coupled with the last name of any person, including students, alumni, or employees, in combination with one or more the following data elements:
        Social Security number;
        Driver’s license number or State identification card number;
        Account number or credit or debit card number;
        Medical information;
        Health insurance information;
        Unique biometric data generated from measurements or technical analysis of a person for purposes of authenticating the person, such as a fingerprint, retina or iris image;
      2. A user name or email address combined with a password or security question and answer, which together would permit access to an online account;
      3. An account number or credit or debit card number in combination with any required security code, access code, or password that would permit access to an individual’s financial account; and
    14. Information requiring such treatment pursuant to a Non-Disclosure Agreement (NDA).
  2. Internal-Only
    Internal-Only data is that which could result in harm to the University or its constituents, including but not limited to its students, alumni, applicants, trustees, employees, and contractual partners, if accessed, disclosed or used in an unauthorized manner. Internal-Only Data is distinguishable from the other Data Classifications set forth herein because it is intended to be used solely by University personnel or authorized University agents but is not kept on a “need to know” basis only.
    Inappropriate handling of Internal-Only Data could result in reputational damage for the University, as well as loss of competitive advantage and higher costs for University business processes. Even some data that eventually becomes part of the public record may be classified as Internal-Only for interim purposes, such as while certain negotiations are ongoing. Typically, Internal-Only Data is that which is not intended to be shared with persons or entities outside the University or its authorized agents, such as accountants and attorneys.
    Examples of Internal-Only Data include, but are not limited to:
    1. Unpublished Research Data;
    2. Intellectual Property not intended to become public, such as software code;
    3. Preliminary drafts, notes, recommendations, memorandum and other records in which opinions are expressed, or policies or actions are formulated;
    4. Certain communication, correspondence, memos, meeting minutes, or processes and procedures;
    5. Other data not listed by any other restricted classification that is exempted from disclosure under FOIA, 5 ILCS 140/7-7.5;
    6. Vendor taxpayer identification numbers.
  3. Public Data classified as Public is information that may be disclosed to any parties regardless of their affiliation with the University and without restriction. Individuals should not assume that data obtained from University systems is public unless expressly designated as such or obviously intended as such. For example, interim drafts of policies, procedures, reports, findings, resolutions, minutes, and other types of communications may not be intended for public inspection or distribution and may be exempted from public disclosure. When in doubt, an individual should assume information is not public unless and until the user has obtained clarifying guidance from a supervisor or the University’s FOIA Officer.
    Examples of Public data include, but are not limited to, final and published versions of:
    1. Press releases;
    2. Course catalogs;
    3. Marketing materials; and
    4. Information posted to the University’s publicly-accessible website, including but not limited to published policies, consumer disclosures, and job postings.
3. Other Data Classifications
  1. Gramm-Leach-Bliley Act Customer Information
    1. Information obtained by ��Ƶ as a result of providing a financial service such as when the University administers or aids in the administration of Title IV programs; makes institutional loans or scholarship; or certifies a private education loan on behalf of a student. Customer information is limited to financial information connected to student and parent finances such as student and parent loans, bank account information and income tax information for financial aid packages.

Credit and Source

Developed internally.

lhendrickson@g… 03/22/2026

President Cheryl Green

11/14/2022

01/24/2025

SEO Summary

��Ƶ establishes data classifications to ensure security, maintain confidentiality, and comply with legal obligations protecting.

eCFR :: 16 CFR Part 314 -- Standards for Safeguarding Customer Information

Data Classification (Policy 89)

Policy Categories

Information Technology Policies

Policy Owner/Department

Information Technology Services

Backup and Disaster Recovery

lhendrickson@govst.edu — Sun, 22 Mar 2026 19:34:09 +0000

Backup and Disaster Recovery

Purpose
Data backups and disaster recovery planning are essential to re-establish the normal
operations of the University’s identified production enterprise systems in the event of a
disaster, data breach, or other extended interruption. Compliance with this policy will help
ensure that critical University data and systems are able to be restored when needed.
Definitions
1. Replication – In the context of ��Ƶ’s backup and disaster recovery processes, replication is
  the act of copying data to the University’s disaster recovery site at Illinois State University.
2. Disaster – Any situation that presents the possibility of an extended outage or interruption
  of University identified systems or data.
3. ERT – The Emergency Response Team is responsible for declaring and reacting to University
  emergencies.
Policy
1. Scope
  This policy applies to identified Enterprise-wide University systems and data as classified
  in this policy.
2. Responsibilities
  All system and application owners are responsible for the data under their purview,
  including ensuring for appropriate backup, recovery, and operational continuity, and for
  developing associated procedures.
3. System and Data Classification
  For the purposes of backups and disaster recovery, systems and data shall be classified
  per the Disaster Recovery System Classification Standard.
4. Backup and Replication
  University-hosted systems and data shall be backed up and/or replicated to the
  University’s remote disaster recovery site as directed by their classification in the
  Disaster Recovery System Classification Standard.
5. Disaster Recovery
  The University has established and shall maintain a disaster recovery process to ensure
  that University-hosted systems are able to be restored in the event of an extended
  outage or disaster. The process is documented in the Disaster Recovery Run Book and is
  updated at least semi-annually.
6. Testing
  Using a mock disaster exercise, the disaster recovery process is tested semi-annually against the Disaster Recovery Run Book. Results of each test is recorded and the Run Book is updated as necessary based on the results of the test.

lhendrickson@g… 03/22/2026

President Cheryl Green

06/01/2023

SEO Summary

Protect ��Ƶ's critical data & systems. Our disaster recovery & backup policy ensures rapid restoration & business continuity after any outage.

Acceptable Use Policy for Computing and Networking (Policy 93)

Policy Categories

Information Technology Policies

Policy Owner/Department

Information Technology Services