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.
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
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 layers.
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.
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 transactional table. 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, as well as alerts and prompts to prevent users from accidentally deleting data. The audit trail records 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 access student data only for the students 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 (FIPPA), 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.
Follett Destiny
The Follett Destiny® suite shares many of the same security attributes as Aspen – including multiple levels of support data security.
Follett Destiny Data Security