Why Student Data Privacy Compliance is Top of Mind

Let’s start with the obvious: protecting student data has been the law of the land since 1974. For any technology solution to be sold in K-12 education, it is a non-negotiable requirement. Over the course of my career, I’ve seen student data privacy evolve from something nobody seemed to even think about, to a token bullet point mentioned in passing during adoption assessment, to where it is now, which is a complex ecosystem of laws, agreements, and frameworks that every industry leader needs to understand.

The intrinsic goal of protecting data is what’s most important, but the financial risks for data privacy compliance failure ought to be a pretty good motivator as well. Case in point, the recent PowerSchool data privacy settlement, a $17.25 million dollar agreement by PowerSchool and Chicago Public Schools for allowing the Naviance platform to expose private student data to a third party provider. This specific case wasn’t because of a data breach— this was simply because the data was being shared without consent.

If you want to give your product the best chance of supporting or improving teaching and learning, then you have to dive a little deeper to understand student data privacy. Even if your technology tool doesn’t currently manage student data, it’s important to be prepared. Look at accessibility, which is a few years ahead of security/data privacy in the compliance lifecycle, yet still caught many solution providers flat footed and grasping for ineffective approaches to protecting renewals.

The Ecosystem of Student Data Privacy

The current ecosystem for managing student data privacy is a complex acronym soup that consists of federal and state laws, vetting instruments, and security frameworks. The foundation layers of the Student Data Privacy Compliance chart below are the laws governing the handling of student data. The middle layers are how districts evaluate risks and govern providers’ access to student data. The top layers are the latest frontier: the security frameworks and ongoing verification that providers have adopted to ensure strong security practices.

The Six Layers of Student Data Privacy Compliance

The Challenge of Managing Bits (not Atoms)

It’s remarkable how big a student data footprint can extend quickly and easily through your business. A Data Privacy Agreement (DPA) usually accompanies any contract with a public school district, and applies to all copies of student data, wherever it might live, not just in your platform’s production database. It extends to staging or development servers, subprocessors, or subcontractors you’ve hired to work on the platform. Anyone or anything that can touch student data downstream from your school district customers’ becomes your responsibility. For this reason, most DPAs require you to contractually bind your subprocessors and contractors to the same standard if they have any access to your student data.

As someone that has spent years in the development trenches, I can attest that the path of least resistance puts your customer data in all those places almost by default. As an example, developers often copy production data down to local machines or development servers to build and test new features. If your organization doesn’t require sanitizing that data as part of your development practices, and a contractor gets hacked or a developer’s laptop is stolen from a car, then all that student data could become public. If someone in Product or Marketing wants to use a cool analytics tool they just learned about and they don’t take extra steps during integration, that third-party company and its staff may now have access to your customers’ sensitive information. 

Steps to Take to Help Protect Student Data Privacy

Avoiding scenarios like these and committing to good data hygiene practices takes deliberate planning and ongoing supervision. If you’re unsure about your level of compliance, here are some concrete steps to assess where you’re at and how to move forward.

1. Catalog where personally identifiable information (PII) and student data live in your organization. Review your product and record every instance of stored PII. Document distinctions between student, educator, parent, and administrator information. All user PII matters, but most regulation focuses on student data specifically.
2. Create a system diagram that shows your production platform and how it connects to third-party integrations like analytics and telemetry, staging and development computers, systems logs, and backups. You want a full picture of where and how data flows so you can build the proper gates for blocking or sanitizing the data.
3. Complete the CoSN K-12 CVAT in anticipation of its request from your customers to avoid stalling sales and marketing efforts.
4. Establish a breach-response plan and run a fire drill at least annually. Write the process down before you need it, so you’re not figuring out what your policy and next steps are in the middle of a security incident.
5. Document the specific additional requirements applicable to each customer’s DPA.
6. Commit to implementing a DPA-approved security framework like NIST CSF.

The challenge is most of this information is siloed in organizations. Your legal team is already aware of the laws about student data privacy, but doesn’t know infrastructure. Your CTO knows what cybersecurity practices are necessary to protect your infrastructure, but isn’t aware of the regulatory requirements regarding student data. And your product or marketing teams are focused on improving the product and user experience, and aren’t thinking about the consequences of integrating third-party tools to help them measure user behavior. Someone in your organization needs to understand all these domains, or you can partner with people who already do. Reach out to learn how we can help you take steps to protect student data privacy and break down the silos and get everyone on the same page.