Protect Federal Student Aid Information – FY18 Department of Education Audit Requirements
Institutions of Higher Education (IHEs) are legally obliged by a variety of laws and legislature to protect student information. These include the Family Educational Rights and Privacy Act (FERPA) and the Gramm-Leach-Bliley Act (GLBA). Notably the GLBA has several requirements pertaining to the security and control of customer information that directly applies to financial services organizations including IHEs.
To ensure that IHEs are securing student information the US Department of Education (ED) has added GLBA compliance draft language to their Fiscal Year 2018 (FY18) audit. This latest step follows two Dear Colleague Letters sent by ED in July 2015 (GEN-15-18) and July 2016 (GEN-16-12) to IHEs participating in the Title IV Federal Student Financial Aid (FSA) program reminding IHEs of their obligation to protect student information.
In GEN-15-18 ED reminds IHEs that the FSA Program Participation Agreement (PPA) and the Student Aid Internet Gateway (SAIG) Agreement contain clauses that require protection of student information including a clause in the PPA that requires IHEs to adhere to GLBA.
In GEN-16-12 ED writes “The Department will require the examination of evidence of GLBA compliance as part of institutions’ annual student aid compliance audit.” ED initially proposed this assessment for the FY17 audit, but agreed to push the requirement to FY18 due to concerns raised regarding clarity and expense of requirement.
Does This Impact My Institution?
Most likely – Any postsecondary institutions that participate in the Title IV Federal Student Financial Aid Programs (FSA). This applies to institutions outside the US as well that administer Title IV FSA funds.
What Is Required?
IHEs are required to comply with Gramm-Leach-Bliley Act (GLBA) – excerpted from GEN-16-12: “Under the GLBA, financial services organizations, which include postsecondary educational institutions, are required to ensure the security and confidentiality of student financial aid records and information. The GLBA requires institutions to, among other things:
Develop, implement, and maintain a written information security program;
Designate the employee(s) responsible for coordinating the information security program;
Identify and assess risks to customer information;
Design and implement an information safeguards program;
Select appropriate service providers that are capable of maintaining appropriate safeguards; and
Periodically evaluate and update their security program.”
NIST Special Publication 800-171: Protecting Controlled Unclassified Information in Nonfederal Information Systems and Organizations (NIST 800-171) – While not implicitly required at this time, ED in GEN-16-12 reference the more detailed control requirements outlined in NIST 800-171. Specifically “The Department strongly encourages institutions to review and understand the standards defined in the NIST SP 800-171.” Furthermore ED writes “we strongly encourage those institutions that fall short of NIST standards to assess their current gaps and immediately begin to design and implement plans in order to close those gaps using the NIST standards as a model.”
While NIST 800-171 is not currently required for FSA compliance, it is worth noting that Defense Federal Acquisition Regulation Supplement (DFARS) clause 252.204.7012 does requires DOD contractors and institutions that they share data with to be NIST 800-171 compliant by December 31, 2017. Additionally, many federal research grants and other contracts currently contain clauses requiring NIST 800-171 or in some cases the broader NIST 800-53a-r4 compliance.
What Is Included in the Department of Education Audit?
The FY18 draft audit language to ensure schools are securing student data can be found here. The Audit has three objectives: to “determine whether the IHE designated an individual to coordinate the information security program; performed a risk assessment that addresses the three areas noted in 16 CFR 314.4 (b) and documented safeguards for identified risks.” The three areas in 16 CFR 314.4 (b) that the risk assessment is to address are: “(1) Employee training and management; (2) Information systems including network and software design, as well as information processing, storage, transmission and disposal; and (3) Detecting, preventing and responding to attacks, intrusions, or other systems failures.”
How Do I Demonstrate Compliance?
Institutions are required to conduct a risk assessment as outlined above. Part of the suggested ED audit procedures includes to “Obtain the IHE risk assessment and verify that it addresses the three required areas noted in 16 CFR 314.4” as well as to “Obtain the documentation created by the IHE that aligns each safeguard with each risk identified from [the risk assessment] above, verifying that the HE has identified a safeguard for each risk.”
Can Salty Cloud, PBC Help Conducting a Risk Assessment?
Yes! We have a hosted application built just for that – ISORA. It was built in EDU and specifically designed to assess the standards relevant to your institution. ISORA is scalable so you can track, classify, and assess systems specific to GLBA/ FSA or more. Assess individual departments, system categories or across institution for GLBA, FERPA, NIST 800-171, NIST 800-53, NIST CSF, CCS CSCs, HIPAA, PCI, FISMA, DFARS, and/or other security and compliance frameworks.
ISORA for GLBA
ISORA Risk Assessment covers the three areas in 16 CFR 314.4 (b) as well as safeguard recommendations for identified risks. You can use ISORA to meet the ED FY18 audit requirements for a Risk Assessment. At the same time you can use ISORA for gap assessment relative to NIST 800-171 or other standard(s) to not only meet current requirements but also provide a roadmap to further strengthen your institution’s overall security posture.
ISORA is a hosted app built with EDUs in mind and preloaded with the standards and frameworks that matter most to Higher Ed. It allows for unlimited delegation so a single individual can setup and launch the assessment efficiently. No need for dedicated deployment teams and months of configuration/ customization.