FERPA and Legal Compliance

Attention

This page is a technical/process summary, not legal advice. Before using this tool with any student’s data beyond your own, confirm your understanding with your institution’s registrar or FERPA compliance office.

Overview

This project (pbj.db plus the goaltracker Django application described in Class Objectives Tracker (goaltracker)) stores information about which syllabus learning objectives a student has completed. That data lives in a self-hosted PostgreSQL database, reachable only through a login screen, and – as currently built and used – holds data about exactly one student: the person running it, about themselves.

This page walks through why that current setup does not trigger FERPA obligations, what would change that, and what to do before expanding the tool beyond personal use.

What FERPA Actually Covers

The Family Educational Rights and Privacy Act (FERPA) restricts how an educational agency or institution that receives federal funding may disclose personally identifiable information from a student’s education records without consent. Two things both have to be true for FERPA to apply to a given system:

1. The records are maintained by, or on behalf of, the institution (not a student’s own personal notes, kept independently and not shared with or accessible to the institution).

2. The records are about an identifiable student – grades, evaluations, disciplinary records, enrollment status, and similar.

FERPA does not stop a student from creating, keeping, or even publicly sharing their own records about themselves. A student has an absolute right to disclose their own educational information; FERPA regulates the institution’s disclosures, not the student’s.

Why the Current Setup Does Not Trigger FERPA

• It is not maintained by or for the institution. The application runs on personal hardware, under Docker Compose, started and administered by the student – not deployed, operated, or contracted by the school.

• It only contains the student’s own data about themselves. Every GoalCompletion, Enrollment, and ProjectPlanItem row is scoped to a single Django user account, and every view in the app filters strictly by request.user – there is no code path where one student can see another student’s progress.

• The imported course/goal content is curriculum data, not student data. Course and Goal rows (titles, descriptions, syllabus topic hierarchy) describe what a class covers, not how any particular student performed. Nothing in the current import brings in grades: the tasks table in pbj.db, which does carry a graded weight and status field, was deliberately excluded from the import specifically to avoid pulling grade-shaped data into the app (see Class Objectives Tracker (goaltracker)).

• Publishing this documentation is the student disclosing their own information, which FERPA explicitly permits. It would be a different situation if these pages, or pbj.db, contained any other student’s name, grade, or performance data – they currently do not, and should stay that way.

What Would Change That Assessment

Any of the following would mean this needs a real compliance review before proceeding, not just an assumption that “it’s still fine”:

• Multiple students’ data in one instance. The moment a second real student’s GoalCompletion/Enrollment data is stored alongside the first, the database contains identifiable education records about more than one person.

• The institution operating, hosting, or contracting the tool. If a department, professor, or the school’s IT stands this up as an official or semi-official tool – even informally, e.g. “everyone in the class use this to track progress” – the school becomes a party responsible for how the data is protected and disclosed.

• An instructor or administrator account with visibility into other students’ progress. Nothing like this exists in the current code (courses_overview and friends only ever query request.user’s own data), but a future “professor dashboard” feature would immediately raise this if it exposes one student’s completion data to another user.

• Grades, discipline records, or other protected fields entering the schema. Importing the tasks/work_log tables from pbj.db (currently skipped) or adding new fields like exam scores would move the data from “curriculum design” into “student performance record” territory.

If Any of Those Become True

Recommended steps, roughly in order:

1. Stop and get sign-off first. Talk to your institution’s registrar or FERPA/compliance office before rolling the tool out to more than one student. Whether a professor viewing student progress qualifies as a “school official with legitimate educational interest” under FERPA’s exception is a determination the institution has to make and document – it is not something a student developer can decide unilaterally.

2. Tighten infrastructure defaults. The current docker-compose.yml uses a hardcoded dev secret key and default database password (dev-only-secret-key-change-me, goaltracker/goaltracker). Those are fine for a single-user personal instance but must be replaced with real secrets, and the site must be served over HTTPS, before it holds anyone else’s data.

3. Keep access scoped per-student. Preserve the existing pattern of filtering every query by request.user – do not add a feature that lets one student query another’s GoalCompletion rows without an explicit, reviewed reason and access control.

4. Only collect what’s needed (data minimization). Keep grade-like fields (the tasks table’s weight/status) out of any shared instance unless there’s a specific, approved reason to bring grade data in.

5. Write down retention and deletion. Decide, and document, how long completion/enrollment data is kept and how a student can have their data removed – FERPA gives students rights to access and, in some cases, request correction of their own education records.

6. Log access to shared data. If the tool moves to a shared instance, keep a record of who accessed or exported student data and when, so that any FERPA-covered disclosure can be accounted for.

7. If a third party ever hosts this (a cloud platform, a school’s shared server run by someone else), get a written data-handling agreement in place before any real student data touches it.

Other Laws Worth a Quick Check

• State student-privacy laws. Several states have their own student data privacy statutes layered on top of FERPA (often stricter, and sometimes covering K-12 specifically rather than higher ed). If this is ever used below the college level, check your state’s requirements separately.

• General data breach/notification law. Even a personal project that starts holding other people’s data is generally subject to your state’s breach-notification law if that data is ever exposed – another reason to fix the dev-only secrets before broadening use.

• COPPA. Only relevant if any user could be under 13; not expected to apply to a college-course tracker.

Summary

As built today – single student, self-hosted, no grade data, no cross-student visibility – this project is a personal tool the student is using to track their own learning, which sits outside FERPA’s scope. That status is fragile: it depends entirely on staying single-user, curriculum-only, and self-hosted. The moment any of those three conditions changes, treat it as a new project from a compliance standpoint and get institutional sign-off before real student data goes in.