So you’re building an EdTech app? (An intro to data privacy)

Schools, districts, and EdTech vendors are faced with a challenge: providing personalized learning software while protecting student privacy.  With rapid changes in technology, EdTech vendors and school officials must spend time understanding the relevant laws and adopting best practices for handling student data.

If we, the creators of educational software, build products that don’t respect student data privacy, we will lose the opportunity to build products for students.  In this post, we’ll take a look at data privacy from the perspective of an EdTech software vendor who is focused on the US K-12 market.

Regulatory background

Two federal acts define the regulatory framework for student data privacy: FERPA and COPPA.

Companies receiving student data from schools must understand FERPA, which protects the privacy of student records at publicly-funded schools.   FERPA means schools may only release student data with parental permission or for legitimate educational purposes.  FERPA puts the burden of enforcement on schools, who, in turn, subject their vendors to scrutiny before sharing any data.

Companies serving students younger than thirteen must comply with COPPA, the Children’s Online Privacy Protection Act.  The act applies to companies (but not nonprofits) who knowingly offer service to children. There have been several large fines against companies for violations of COPPA, and as a result many companies restrict their services to those age thirteen or older.  For companies serving children, COPPA requires:

• an explicit privacy policy
• parental consent (either directly through a website or indirectly through a school)
• limited retention of data
• collecting only information that is reasonably necessary
• protecting the personal information that is gathered

Note that regulations may vary depending on the type of student information you are using. Rules for “personally identifiable information” like birthday and student ID are more stringent than those for “directory information” like name and address. Also, note that individual states also regulate handling of student data.  California recently introduced new legislation, and several other states made changes in 2013.

Recent developments

Two trends in learning software make data privacy increasingly urgent.  First, learning software is becoming more personalized towards individual students, by collecting usage and performance data.  Second, software is increasingly deployed from hosted services, as opposed to on a local district network.  In short, there is more data, distributed more widely.  A recent Fordham study found that 95% of districts rely on cloud services, but fewer than 25% of contracts specify the purpose for disclosed student data.

Regulatory agencies are moving to keep up.  PTAC, the privacy advisory center run by the Department of Education, recently issued new guidance.  The guidance includes many examples and clarifying comments.  For example, “If the school has shared information under FERPA’s school official exception…the provider cannot use FERPA-protected information for any other purpose than the purpose for which it was disclosed.”

Good practices

Based on the regulatory framework, these are some good practices for a maker of learning software.

Don’t be the bad guy

Foremost, choose a business model that avoids problematic areas.  For example, avoid profiling students for advertising or marketing purposes.

Be transparent

“Human readable” privacy policies are the new gold standard.  For example, see Clever’s policy.  We also like Edmodo’s policy.  More broadly, TOSDR is leading the charge towards simple terms of service.

Get parental consent

Make an explicit decision if you want to serve students under age thirteen.  If you do, you need to get parental consent, either directly through your site or indirectly through a school.

Limit data collection and retention

Think about what data is truly necessary to offer your product.  Don’t ask for information you don’t need.  Limit retention to what is useful.  Storing unnecessary data may be a red flag to schools and districts who are considering your product; and the more data that is stored, the greater the severity of a data breach.

Be secure

If you’re handling student data, you need to handle it securely.  For example, don’t email around CSV files of student data.  Do follow best practices for web security.  A good resource is OWASP, which maintains a list of the top 10 web security vulnerabilities.  Mature web frameworks like Ruby on Rails also have comprehensive security guides.

Seek legal advice

Consult legal experts well-versed in education.  For example, Harvard’s Berkman Center offers a brief on FERPA and COPPA.  Clever retained Kent Talbert to advise on FERPA compliance.

Next steps

Observers at all levels are noting the gaps and recommending improvements.  A recent report and a blog post from an educator suggest next steps like clarifying regulation, simplifying privacy policies, and standardizing contracts between districts and software vendors.

Software makers must work together in protecting data privacy to ensure a vibrant EdTech ecosystem.  Clever, for its part, offers a secure system for districts to share data with software vendors.  We are excited to work with software developers, school officials and regulators to make data privacy simple and reliable.

What are your questions about EdTech data privacy?