Annual audits are coming, and all signs point to a continued focus on protecting student financial information. Title IV/SAIG institutions must protect Federal Student Aid (FSA) applicant information from unauthorized access and disclosure, and comply with the Gramm Leach Bliley Act (GLBA) Safeguards Rule. In recent years, GLBA compliance has been added to the FAFSA Participation Agreement and the Federal Student Aid Handbook.
At the end of last year, FSA released a high-level overview of its cybersecurity compliance plans and a future Campus Cybersecurity Program. While what exactly is to be included in the official Cybersecurity Program framework is unknown, it is clear the NIST SP 800-171 guidelines for securing controlled unclassified information will provide the baseline requirements.
As colleges and universities work to review their environments and proactively implement the necessary safeguards defined within the NIST SP 800-171, determining what exactly is in scope for GLBA can be challenging. We know student financial aid information must be protected, but what other information falls under the GLBA umbrella and where can this data be found across campus?
GLBA applies to any organization engaging in financial activities. For higher education institutions this can include activities like:
- Student loans
- Grants
- Federal Work-Study programs
- Financial advisory services (i.e. 401K programs)
- Career counseling services
- Issuance of debit or long-term payment plans with interest charges
- Collection of delinquent loans or accounts (in-house or third-party)
- Check cashing services
- Obtaining information from a consumer report
- Health insurance provisioning
- Personal property or real-estate appraisals
At a high level, any personally identifiable personal or financial information obtained from a customer in connection with providing a financial product or service should be considered covered data. This can include:
- Names and addresses (f they are associated with financial data)
- Bank account numbers and payment card numbers
- Social security numbers
- Applications for a financial product (student loans/grants)
- Tax return information
- Credit history and credit reports
It will be impossible to protect the data if you are not able to determine and define where it is located. Any people, processes, or systems/technologies that store, process, or transmit this financial information should be considered in scope. This may involve things like servers and workstations, firewalls, student information systems, applications, departments that are accessing controlled unclassified information, file cabinets, paper documents or media with CUI, etc. As a start, commonly impacted departments on campus are listed below, so you will want to determine which areas have access to any in-scope systems and data within your organization.
- Administration
- Admissions/Enrollment
- Registrar
- Financial Aid
- Bursar
- Student Loans
- Student Services
- Housing
- Public Safety
- Fundraising (Development, Foundation, Alumni)
Human Resources and Information Technology/Security will also need to be involved in the GLBA compliance effort as they play a role in implementing the appropriate safeguards on those in-scope systems. Once the GLBA scope is defined, organizations can then begin the required risk assessment process, identifying gaps, prioritizing risks, and implementing the necessary safeguards for compliance.
If your organization is just beginning the process of identifying in-scope departments and systems, it can be overwhelming. Prioritize your highest risks and focus on the primary processing departments first (i.e. Financial Aid, Student Accounts, etc.). If you can begin to get your arms around these core areas, and formalize your safeguards program, you can then go back and search out any other departments or systems that may also be involved and include them in your program moving forward.
Some additional guidance from the CampusGuard Security Advisor Team:
[Campbell]: As with most compliance programs, there is some level of judgment needed once you move beyond the obvious scope. That judgment needs to be calculated with your institution’s risk tolerance and strategic approach in mind. In other words, step back and ask yourself if it matters whether or not particular data was officially “in scope” if you suffer a data breach. You might decide that all data with value on the black market needs to be protected with at least baseline security controls. This can in turn simplify your scope, because you can spend time and resources securing that data rather than getting lost in the weeds discussing whether an area can be excluded from scope.
Finally, I will re-emphasize the point in the last paragraph of the article. Don’t try to “finish” GLBA compliance in one step. It is best to think in terms of maturity models and phases. Build a foundation of security controls. Protect the most critical data. Then in iterative phases you extend those protections to additional areas, continually improving both the scope of your coverage and the quality of your controls. Data thieves are always adapting, so you must as well.
