FERPA Compliance for Automotive Education Software
Every automotive program that adopts classroom software becomes responsible for the student data that flows into it. FERPA, the Family Educational Rights and Privacy Act, governs how education records are handled, and the moment a program shares those records with an outside tool is exactly where compliance gets tricky. This guide walks program directors through what FERPA actually requires and the questions to ask before signing with any vendor.
What FERPA Requires When You Use a Third-Party Tool
FERPA applies to any school that receives federal education funding, which covers essentially every public CTE program, community college, and most trade schools. It protects a student's education records: grades, enrollment status, coursework, and personally identifiable information such as names and student IDs. As a general rule, a school cannot disclose those records to an outside party without written consent from the student (or the parent, if the student is a minor).
Classroom software is a disclosure. When you push rosters, enrollments, and grades into a curriculum platform, you are handing education records to a third party. So how does any ed-tech tool operate legally? Through the "school official" exception.
The School Official Exception
FERPA lets a school share records, without individual consent, with a party it has designated as a "school official" performing a service the school would otherwise handle itself. To rely on this exception, the school must keep the outside party under its "direct control" with respect to how the records are used and maintained. In practice, that control is documented in a written agreement.
The Data Processing Agreement
The instrument that establishes direct control is a Data Processing Agreement (DPA), sometimes called a data privacy agreement. It is the contract that says, in writing, that the school owns the data, the vendor may only use it to provide the service, the vendor will not disclose it further, and the vendor will follow the school's instructions and FERPA. If a vendor cannot or will not sign a DPA, your legal footing for the school official exception is shaky. This is the single most important document in a compliant adoption.
The Questions to Ask Any Vendor
A DPA only protects you if the practices behind it are sound. Before you sign, get clear, written answers on data ownership, security, and what actually happens to student records. The areas below are where programs most often get exposed.
Data ownership. The agreement should state plainly that your institution owns the student data and the vendor is a processor acting on your behalf. You should never see language that grants the vendor a broad license to the data for its own purposes.
Selling or sharing. Ask directly whether student data is ever sold, rented, or shared with third parties, including for advertising or model training. The answer you want, in writing, is no.
Sub-processors. Most platforms rely on other providers (hosting, email, analytics). Ask the vendor to disclose its sub-processors and confirm those parties are bound by the same restrictions.
Encryption in transit and at rest. Student data should be encrypted while moving across the network (in transit) and while stored on disk (at rest). Both matter, and a serious vendor will confirm both.
Data residency. Ask where the data physically lives and on what infrastructure. Some districts and states have requirements about data staying within the country or on named cloud providers.
Breach notification. There should be a defined process for notifying you if data is exposed, including how quickly you will hear about it. Silence here is a warning sign.
Deletion and retention. Confirm that you can request deletion of student records and understand the retention policy, especially what happens to the data after your contract ends.
Student age and COPPA. If your program serves dual-enrollment high schoolers, some may be minors. For students under 13, COPPA imposes requirements on top of FERPA, so confirm the vendor's age policy before enrolling younger students.
The FERPA Vendor Questionnaire
- Will the vendor sign a written Data Processing Agreement that names your school as the owner of the data?
- Does the vendor confirm in writing that student data is never sold, rented, or shared with third parties?
- Is student data encrypted both in transit and at rest?
- Where is the data stored (data residency), and on what infrastructure does it run?
- Does the vendor disclose the sub-processors that handle student data?
- Is there a defined breach notification process, and how quickly are you told?
- Can you request deletion of records, and what is the retention policy after the contract ends?
- For dual-enrollment minors under 13, does the vendor address COPPA in addition to FERPA?
FERPA compliance is a shared responsibility. Your school remains the legal custodian of the records, and a well-built vendor gives you the contractual and technical controls (a signed DPA, encryption in transit and at rest, and a firm no on data resale) that let you designate them a school official under the exception. There is no such thing as a FERPA certified product, so evaluate the agreement and the architecture, not a badge.
How LTI 1.3 Reduces Your Exposure
The less student data you hand to an outside tool, the smaller your compliance surface. This is where the integration standard matters. A curriculum platform built on LTI 1.3 (Learning Tools Interoperability) connects to your LMS (Canvas, Blackboard, Moodle, or D2L) and provisions students through the roster the LMS already holds.
That design has three privacy benefits:
- Minimal data shared. LTI 1.3 passes only the identity and enrollment information the tool needs to function, rather than exporting your full student directory.
- Roster via the LMS. Enrollment flows from the system of record you already manage under FERPA, so you are not maintaining a second, separate copy of the roster somewhere less controlled.
- No separate student accounts. Students launch from your LMS and are authenticated there, so the tool does not need to collect and store its own set of student credentials.
Fewer accounts and less data movement mean fewer places where records can be mishandled or exposed. When you evaluate a platform, ask whether it uses LTI 1.3 and provisions students from the LMS roster, rather than asking you to upload student lists into a standalone system.
How Trackara Education Is Designed
Trackara Education is built to support your FERPA compliance rather than to claim a certification that does not exist. A Data Processing Agreement is signed at onboarding, establishing your school as the owner of the records and Trackara Education as a processor acting under your direction. Student data is hosted on Google Cloud and encrypted in transit and at rest, and it is never sold or shared with third parties. Students must be at least 13 years old, and LMS integration runs on LTI 1.3, so provisioning happens through your existing roster instead of a separate student sign-up.
Frequently Asked Questions
Is Trackara Education FERPA certified?
No product can be FERPA certified, because no such certification exists. FERPA governs schools, not vendors. Trackara Education is designed to support your FERPA compliance through a Data Processing Agreement signed at onboarding, encryption of student data in transit and at rest, and a commitment never to sell or share that data.
Who owns the student data we put into the platform?
Your institution does. The Data Processing Agreement signed at onboarding names your school as the owner of the records and Trackara Education as a processor acting under your direction, which is what the school official exception under FERPA contemplates.
Where is student data stored and how is it protected?
Student data is hosted on Google Cloud and encrypted both in transit and at rest. It is never sold or shared with third parties.
Can minors in a dual-enrollment program use the platform?
Students must be at least 13 years old to use Trackara Education. For learners under 13, COPPA adds requirements beyond FERPA, so confirm age eligibility with any vendor before enrolling younger minors.
Do students need a separate account, and does that create more data to protect?
No. With LTI 1.3, students launch from your LMS and are provisioned through the existing roster, so there are no separate student accounts and the amount of personal data shared with the tool is kept to the minimum needed.
See how Trackara Education handles student-data privacy.
Walk through the Data Processing Agreement, the security model, and the LTI 1.3 integration with your team. We will answer every question on the vendor questionnaire.