Follett is committed to data security and supporting our customers’ data privacy needs. As student data collection evolves, Follett continues to provide and enhance the necessary levels of security to ensure your student information is secure and private in our learning management and educational systems.
Protection of individual sensitive and personally identifiable information (PII) is a priority for Follett. To ensure compliance with all applicable privacy legislation, Follett has established policies and processes that focus on the protection of all potentially sensitive customer data. Follett has invested in technologies that support the protection of and provide security for data while in transit or at rest.
Follett’s Pledge of Student Privacy
Follett is proud to be one of the first signers of the national Student Privacy Pledge regarding the collection, maintenance, and use of student personal information. The pledge states: “School service providers take responsibility to both support the effective use of student information and safeguard student privacy and information security.”
Follett takes the Student Privacy Pledge seriously and strives to go above and beyond the privacy constructs defined within.
Follett Aspen® Student Information System (SIS) provides several levels of security that control access to your system from people external to your organization, internal to your organization, and even among other Follett products that you are using.
Aspen was created with security in mind.
We built Aspen to include security as a core component of its design. This design includes a strict adherence to the separation of different layers within the application. Users interact with a presentation layer that is strictly HTML. All business logic operates on the application server in a business layer that is isolated from both the presentation and the database access.
All data is securely transmitted over the HTTPS protocol. This includes page content, images, fonts, and user data. All database access is handled by a third and isolated persistence layer. Between the end user and the actual storage of sensitive data, there are three independent layers in the Aspen application that all play important roles in ensuring only the appropriate data gets to each user.
The Aspen data model consists of a single database, meaning that data does not need to be replicated to other data stores. Security rules are applied universally to each database instance when it is created, and the database is not accessible from outside the data center firewall. Each Aspen customer has a separate logical database, and each Aspen instance only has the user account of the database for that instance.
Our approach to security at the design level means that typical hacking techniques such as SQL injection and cross-site scripting (XSS) are blocked, not by patches and fixes to vulnerabilities that come out on a periodic basis, but by the basic design of the application and encapsulation of each layer.
Security and penetration tests are routinely run on Aspen to verify that our security is intact. This testing allows us to verify that the security measures we’ve developed – such as the cross-site scripting protection layer that prevents database access via SQL injection – are working to prevent known attack vectors.
Aspen has multiple levels of data security.
All access to the database is managed through the application, and the data is only visible to users with specific rights and permissions. To accomplish this, you can apply your data security in a number of ways, including field-level, component-level, record-level, or scoping and navigation security.
User Group Profile and Maintenance
Aspen provides role-based security. Roles are defined and granted privileges to create, read, update, delete, or mass-update (CRUD-M) records in a particular table. There are also business privileges for special operations like archiving a student or accessing teachers’ grade books. Roles are then assigned to users. Aspen allows users to be associated with multiple roles and with multiple schools. A user gets the cumulative privileges allowed by those roles.
Audit Reporting of System and Application Access
Aspen has auditing abilities that allow you to review and confirm that your policies are working the way you intended. Aspen includes an audit trail component that can be enabled for any table and field in the Data Dictionary. For each record modified, the audit trail shows who made the change, what was changed (both the original and new values), and when the change was made. Only users with the appropriate privileges to view a record’s audit trail history can do so.
Aspen also makes use of security roles to restrict users from intentionally deleting data, alerts and prompts to prevent users from accidentally deleting data, and the audit trail to record what data may have been lost.
Aspen complies with FERPA guidelines.
The Family Educational Rights and Privacy Act (FERPA) business rules are built into the system so that guidelines (for example, teachers can only access student data for students that they teach) are automatically enforced. System-wide searches only show directory info that is within the FERPA guidelines and can be disabled at the discretion of the district. The comparable Canadian privacy act, Freedom of Information and Protection of Privacy Act (FOIPPA), is also supported.
Student-identifiable information is not shared or uploaded to any other systems from Aspen – including other Follett software solutions. The ability to share patron data with Follett Destiny® exists but must be explicitly and proactively configured. Student-identifiable information that would not otherwise be stored in Destiny is not shared.
The Follett Destiny® suite shares many of the same security attributes as Aspen – including multiple levels of support data security.
Follett Destiny® Data Security
Follett Recommendations for Minimizing Cyber Threats to Local K-12 School Servers
As a leader in PreK-12 education technology tools and applications, Follett is constantly monitoring for potential security threats and providing enhancements as needed to protect all of our products and customer data.
In July 2018, Follett released Destiny 16.0, which updated the underlying architecture of our Destiny applications to more modern versions of Java technology. Follett strongly encourages all locally-installed customers to update to Destiny version 16.0, and to take the proper precautions to minimize potential threats to local server environments.
Follett strongly encourages its customers to apply the latest auto-update for their Destiny version or upgrade to Destiny version 15.0, and to take the proper precautions to minimize potential threats to local server environments.
Specifically, customers running Destiny on local servers should take the following steps:
Follett’s Support team is available to provide help and assistance at 877.899.8550, option 3. For server security concerns outside of the scope of the Destiny application, schools can contact the Multi-State Information Sharing and Analysis Center (MS-ISAC) for information and support.
Note: In April 2016, Follett identified a potential vulnerability in the underlying architecture of Destiny applications installed on local school servers, and in May 2016 provided a patch to eliminate the vulnerability. At that time, Follett provided patches for Destiny versions 9.0-13.5. One of the world’s leading cybersecurity companies has validated the effectiveness of the patch in closing the vulnerability. All subsequent releases (Destiny 14.0-16.0) contain the security patches or technology upgrades that make those patches unnecessary.