Obligatory CYA note: This article is presented as an “insider’s look” at how SIS security works and the common pitfalls associated with the “convenience vs. compliance” dilemma. The author is not a lawyer and the piece should not be misconstrued as legal advice.
When FERPA was signed into law by President Gerald Ford in 1974, “accessibility” meant “the key to the filing cabinet,” and an “information request” was either an in-person conversation or a bundle of paperwork.
Now, nearly 50 years later, the entire context of the law has changed. Educational records have found a new (digital) home. Efficiency and accessibility are basic expectations, and the amount of red tape required to perform basic duties is shrinking all the time.
But how do you balance the need for speed with legal privacy obligations? Student information systems (SISs) have replaced paper as the default location for most educational records, rendering traditional safeguards irrelevant. A recurring security audit is one of the best ways to determine whether “legitimate educational interest” is being skirted in favor of convenience. Here’s what to look for:
The technical background
To adequately understand the challenges faced by school district IT staff, you need to have at least a little background on SIS security settings. Long story short, the way it works is this:
- The district assigns employees to certain “security groups” within the system, often role-based by default; i.e., principals, teachers, coaches, counselors, various student services roles, etc.
- Each group is assigned granular view/edit access to the modules, screens, and fields they need to do their jobs.
- Non-role groups are often needed based on function; i.e., locker assignments, graduation requirements, or discipline. These groups will cover scenarios in which some, but not all, people in different roles may need permissions.
- Each entity (usually a school campus) will have its own groups, while other groups will have access to the whole district (think district administrators or district-wide student services).
It’s not sexy, but it gets the job done. The point is this: Despite all the worries about centralizing information in one database, the security is granular enough to meet letter-of-the-law FERPA requirements on the technical side. So, we’re all good here, right? Not quite.
The accessibility dilemma
Everyone wants more access, and it’s usually easier to grant it than it is to take it away. Believe it or not, there are more than a few districts out there where every individual who has access to the SIS also has access to every student record. This kind of oversharing is the number one reason for failed student data management audits in recent years.
Here are some things to look for when reviewing your own security practices*:
- Do teachers have access to only the students assigned to their courses and only while those courses are in session?
- Do special education teachers or service providers have access to only the students in their caseloads?
- Are sensitive records such as health and discipline protected and visible only to those who need the information to do their jobs?
- Is cross-entity information available only to those whose responsibilities span more than one campus?
- Are your onboarding, offboarding, and transfer processes automated to the point where access is granted, removed, or edited immediately when job status changes?
- Have you clearly documented your security strategy, meaning you can provide a clear picture of who has access to what data and why at any given point in time?
*One important caveat here: The district bears the burden of defining and defending “legitimate educational interest.” If you can make a strong enough case that your policies demand exceptions to common rules or practices, you might be able to stand up to a challenge. When in doubt, it’s usually best to consult an attorney.
The limitations of system security
Let’s assume for a moment you are doing everything right at the district level to balance the security and accessibility of student data. It’s a step in the right direction, but it’s not the only thing you have to worry about. It’s easy to forget (and much harder to police) what happens to data after it leaves the friendly confines of your SIS.
Even now, two of the most common functions of any SIS are the “export” and “print” capabilities. In both cases, the user is extracting presumably secure data from the system, but now they, not your vendor or your system administrator, are accountable for who sees it and how it gets used.
Google Drive (incorrect sharing settings), classroom websites (private data posted in a public forum), and local workstations (sensitive data accessible to anyone who uses the computer) are three of the most common culprits for post-SIS FERPA fault lines. The best way to stay in front of potential issues? Keep awareness high and make sure everyone has a clear understanding of how they can meet the “legitimate educational interest” standard. Failure to do so can lead to serious consequences for your students and your staff.
It’s always better to have a conversation with people about why they can’t have access to something than it is to have a conversation with a reporter about why your district fell short of federal student privacy regulations. Stay in the know, keep awareness high, and make sure the people who need to make these decisions are intimately familiar with the ins and outs of FERPA, your local definitions, and what you’re doing to keep things transparent for your community.
Follow-up resources: Free security training videos
Your SIS is just the beginning. From email to Google to the local desktop, cybersecurity threats seem to be lurking around every corner these days. Stay informed with the video-enhanced blog, Advancing K12 Security Drill—3 Threats to Watch For.