FERPA, GDPR, and student writing process data: what institutions need to know

The question institutions are asking — and why now

Automated writing process tools — tools that log keystrokes, measure typing cadence, and record the sequence of edits that produced a document — are being deployed in higher education at speed. The institutional motive is understandable: in an environment where AI generation is trivially easy and AI detectors are demonstrably unreliable, the writing session record is the most direct evidence of whether a student composed their own work.

What institutions have often not stopped to consider is the legal character of that record. Keystroke logs, timing data, and session recordings are not inert audit files. They contain detailed behavioral information about an identifiable student, generated during an activity the institution required, and stored on systems the institution controls or procures. That description almost certainly puts them inside the regulatory perimeter of the Family Educational Rights and Privacy Act (FERPA) for US institutions, and inside the General Data Protection Regulation (GDPR) for UK and EU institutions. Understanding where the boundaries sit — and what they require — is now a practical compliance question, not a theoretical one.

---

Is writing process data an "education record" under FERPA?

FERPA (20 U.S.C. § 1232g) defines "education records" as records, files, documents, and other materials that (1) contain information directly related to a student, and (2) are maintained by an educational institution or by a person acting for such institution. The definition is deliberately broad. It was designed to cover any institutionally held record about a student, not only transcripts and grade books.

Applying that definition to writing process data collected through an institution-deployed tool:

• Directly related to a student. Keystroke logs are by design tied to a specific student's account, session, and submission. The entire purpose of the record is to capture that particular student's behavior. There is no serious argument that such a record is not directly related to a student.
• Maintained by the institution. If the institution deploys the tool, mandates its use as part of course requirements, or holds the data under a data processing agreement with a vendor, the institution is maintaining the data — either directly or through a person acting for it. A vendor who processes student data under an institutional contract is, under the Department of Education's longstanding guidance, acting as a "school official" with a legitimate educational interest for the purposes of that relationship.

The conclusion — that writing process data collected through an institution-deployed tool constitutes an education record — is not a contested legal interpretation. It follows from a straightforward application of the statute's text.

The sole-possession records exception. FERPA excludes records that are kept solely in the personal possession of the person who made them and not accessible to others. This exception might theoretically apply to informal notes an instructor keeps privately, but it does not apply to data held by a third-party vendor or stored in any institutional system, however nominally "private." If a vendor retains keystroke logs on its servers under an institutional contract, those records are accessible to the institution, the vendor, and potentially to regulatory demands — they are not sole-possession records.

The practical implication: institutions deploying process capture tools must treat the resulting data as education records, with everything that follows from that classification.

---

What FERPA compliance requires for process data collection

FERPA's core requirements for education records are inspection rights, disclosure limits, and data governance obligations. For writing process data specifically:

Right to inspect. Students have the right to inspect and review their own education records. An institution that collects keystroke logs must be able to produce those logs to the student who generated them on request. A vendor arrangement where student data is not retrievable in a readable format is not compliant.

Disclosure limits. FERPA restricts disclosure of education records to third parties without prior written consent, subject to enumerated exceptions. Sharing writing process data with external researchers, other institutions, or product development teams at a vendor falls outside the permitted exceptions unless the institution has obtained consent or can demonstrate the sharing falls within a recognized exception such as the studies exception (§ 1232g(b)(1)(F)).

Does FERPA require student consent for collection? Strictly speaking, no. FERPA is primarily a disclosure statute; it governs what institutions may do with records once they have them, not a direct prior-consent requirement for all collection. An institution can collect writing process data under a legitimate educational interest justification without first obtaining a signed consent form.

However, FERPA's silence on consent for collection should not be read as institutional permission to collect covertly. Other doctrines apply: the institution's own reasonable expectation policies, state privacy statutes, and accreditation standards may all impose collection-side obligations. And there are strong non-legal reasons — discussed below — to obtain explicit student consent regardless of what FERPA strictly requires.

Data minimization and retention. FERPA does not impose explicit data minimization or defined retention periods in the manner of the GDPR, but the Department of Education's guidance on institutional data governance strongly implies that institutions should not retain education records beyond the period needed to fulfill the purpose for which they were collected. Retaining keystroke logs indefinitely as a precautionary measure, without a clear institutional records retention policy that covers process data, is a governance gap.

---

The international picture: GDPR for UK and EU institutions

For institutions subject to the GDPR — which includes all UK institutions under the retained UK GDPR, and all EU institutions — writing process data raises a distinct and in some respects more demanding set of questions.

Is writing process data "personal data" under GDPR Article 4? Almost certainly yes. Article 4(1) defines personal data as any information relating to an identified or identifiable natural person. A keystroke log tied to a named student account is personal data by definition. A timing record that could be re-linked to a specific individual through session metadata is personal data even if the name has been removed from the immediate record.

Is it potentially "special category" data? This question deserves careful attention. GDPR Article 9 provides heightened protection for special category data, which includes data concerning health. Keystroke dynamics — the timing and pressure patterns of typing — are used in biometric research and in neurological diagnostics. Patterns associated with Parkinson's disease, essential tremor, and certain cognitive conditions are detectable in keystroke data collected for other purposes. An institution collecting detailed keystroke logs at scale is collecting data that could, depending on the depth of capture and the analysis applied to it, reveal information about a student's health or neurological condition. Whether that triggers Article 9 depends on the specifics of the capture — but it is a question institutions should put to their data protection officers before deployment, not after.

Lawful basis under Article 6. Institutions must identify a lawful basis for processing personal data. The two most likely candidates for writing process data are Article 6(1)(e) (processing necessary for the performance of a task carried out in the public interest) and Article 6(1)(b) (processing necessary for the performance of a contract — the student's enrollment). Either basis requires that the processing be necessary and proportionate. Covert collection that goes beyond what is needed to support the legitimate educational purpose would not satisfy proportionality.

Article 17 erasure rights. Under GDPR, students have the right to request erasure of personal data where it is no longer necessary for the purpose for which it was collected, or where the lawful basis ceases to apply. An institution that relies on Article 6(1)(e) and has no retention policy faces the risk that a student who has submitted their work and received their grade can validly request erasure of their keystroke logs. Institutions should have a documented answer to that request before they receive it.

The UK's Information Commissioner's Office guidance on the UK GDPR mirrors these obligations for UK institutions, and the OIA has noted in its casework guidance on AI and academic misconduct that institutions face heightened scrutiny when evidence in disciplinary proceedings was gathered without clear legal basis or adequate disclosure.

---

The consent-first approach: why it is legally safer and epistemically stronger

There is a tendency in institutional compliance to minimize consent requirements — to identify the legal minimum and stop there. For writing process data, this is the wrong optimization.

The legal argument for consent. Explicit, per-session consent does not merely satisfy legal requirements — it insulates the institution from the strongest lines of challenge. A student who argues that their process record was collected unlawfully, or should be excluded from proceedings on data protection grounds, has a much weaker argument if they affirmatively consented to collection before each session. Consent that is specific (this session, this assignment), informed (you are told what is being collected and why), and revocable (you may decline) is the most defensible posture regardless of what the strict legal minimum requires.

The epistemic argument for consent. A process record gathered with the student's knowledge and agreement is stronger evidence than one gathered covertly — not because the data itself changes, but because its provenance is stronger. A student who argues in a disciplinary proceeding that a covertly gathered record was manipulated or planted has a line of attack that is closed if they consented to and acknowledged the capture in real time. The consent record, when sealed as part of the process record, establishes that the student knew the record was being created: the strongest possible answer to a later claim of fabrication.

This is not a theoretical benefit. The OIA's casework guidance reflects a pattern of successful student challenges that rested on procedural objections — including objections about how evidence was gathered — rather than on the underlying merits. An institution that built its evidence on a consent-first foundation eliminates that procedural attack surface.

---

What institutions should require from vendors

When procuring a writing process capture tool, the following contractual and technical requirements are not optional. Each maps to a specific compliance obligation.

(a) Student-owned records. The contract should specify that the student is the subject of the record and has the right to access a complete export of their own data in a readable format on request. A vendor who cannot deliver this cannot satisfy FERPA's inspection rights requirement on the institution's behalf.

(b) Right to erasure — contractual and technical. The contract must give the institution the ability to delete individual student records on request, and the technical architecture must actually implement that deletion rather than soft-deleting or archiving in a form that remains processable. For UK and EU institutions, the vendor must be able to demonstrate compliance with Article 17 erasure requests within the required timeframe.

(c) No secondary use of data. The contract must prohibit the vendor from using student writing process data for any purpose other than providing the contracted service to the institution. This explicitly excludes product improvement, model training, benchmarking, research publications, and any sale or licensing of data to third parties. A vendor whose terms of service reserve broad rights to aggregate or analyze student data for their own purposes is not compliant with FERPA's re-disclosure limits.

(d) No re-identification. If the vendor offers any form of anonymized or aggregated reporting, the contract should require that anonymization be technically irreversible — not merely that names are removed from exports. Keystroke dynamics are potentially biometric; they can in some circumstances be used to re-identify individuals even without direct identifiers. The prohibition on re-identification should cover the full data chain, not just the labeled records.

(e) Data processed within jurisdiction. For EU institutions, GDPR Article 44 restricts transfers of personal data to third countries without adequate protections. For UK institutions, equivalent restrictions apply under the UK GDPR. A vendor whose infrastructure is located in the United States must either rely on an adequacy decision, standard contractual clauses, or another recognized transfer mechanism. The contract should specify where data is processed and stored, and the institution should verify that the answer is consistent with its transfer obligations.

---

Red flags in vendor agreements

Not all vendor contracts reflect these requirements. The following terms should prompt a legal review before signature:

• "We may use data to improve our services." This is secondary use of student data. It is not permitted without student consent or a separate FERPA exception. The word "improve" is broad enough to cover model training and benchmarking.
• "Records are retained for [X] years." Retention periods set unilaterally by the vendor, without the institution's ability to delete earlier on request, do not satisfy the institution's obligations under either FERPA or GDPR. The relevant question is not how long the vendor retains records by default, but whether the institution can compel deletion.
• "Anonymized or aggregated data is not subject to these restrictions." Without a technically rigorous definition of anonymization, this clause is a gap. Keystroke data that has been "anonymized" by removing names may still be re-identifiable.
• No jurisdiction clause. If a vendor agreement does not specify where data is processed and stored, assume it is processed in the vendor's default jurisdiction — which may be outside the institution's compliance perimeter.
• Dispute resolution clauses that require arbitration. An institution that cannot seek injunctive relief in court against a data breach or impermissible use cannot adequately protect its students' records.

---

Authmarks is designed around the consent-first framework described above. Each writing session begins with explicit, per-session student consent; that consent record is sealed as part of the process record; and students have access to their own records. The design reflects both the legal requirements that apply to institutions and the epistemic logic that makes consent-gathered records stronger evidence.

Related reading:

• Chain of custody for digital writing evidence
• What forensic-grade means in academic integrity
• Investigating an AI-writing concern: a framework for integrity officers