Writing Provenance Software Privacy and Security: University Vendor Due Diligence

A writing-provenance product can handle much more than a student's final assignment. Depending on its design, it may process writing events, timing information, pasted material, revision history, account identifiers, AI-tool interactions and reviewer comments. That can make the information sensitive even when a final essay would ordinarily be shareable with a lecturer.

Universities evaluating authorship-verification software need to answer three questions before an institution-wide rollout: What does the tool collect? Who can use the information? How long is it retained—and under whose authority? This guide turns those questions into an actionable procurement review, while distinguishing student consent to recording from a university's separate legal and contractual obligations.

Disclosure: AuthMarks publishes this guide and supplies writing-provenance technology. This material is an evaluation framework, not legal advice or a certification that any vendor—including AuthMarks—meets a particular institution's legal requirements. Consult your data protection, records and legal teams.

For the broader purchase decision, read the university authorship verification software buyer's guide. For vendor selection paperwork, use the procurement checklist.

Why writing-process evidence needs its own privacy assessment

The submitted essay and the record of how it was produced are different data assets. An ordinary essay might contain 1,500 words and a submission timestamp. A process record might also contain observations about what was added or removed, when typing occurred, which material was pasted, whether capture was paused, and which person attested to the final artifact.

Even if content is pseudonymized or reduced to summaries, combinations of events and timestamps may remain linkable to a student. A university should not assume that "only metadata" means "not personal information." Define precisely which event types are collected, which derived categories are generated, and whether the raw events survive beyond a sealed record.

Build a data inventory before a demo

Data category	Example	Procurement question
Identity and role	Student account identifier, course or reviewer role	Is a personal email necessary, or can the institution use a pseudonymous ID?
Writing events	Insertions, deletions, paste events, timing	Which events are stored; at what granularity; for how long?
Text content	Full passage, excerpt, document hash	Does the service retain full text, snippets, or hashes?
Derived classifications	Typed, pasted, suggested, untracked	Can users contest or contextualize a classification?
Authentication and access	LMS launch, report opens, audit event	Who can see access logs and for how long?
Review and attestation	Named review, student explanation	Can later amendments or appeals be appended without falsifying the original record?
Sealed record	Signature, manifest, exported package	What does validation verify and who can validate it?

The inventory needs to cover the student's device, any browser extension or native app, the vendor's servers, LMS data passed during launch, exports, and retained backups—not only the final dashboard.

Student consent and institutional authority are separate decisions

A product may allow a student to grant permission for a particular document to be recorded. That is an important design choice, but it does not settle the university's legal basis for processing or whether mandatory recording is appropriate in a particular course.

Ask different questions of different stakeholders:

• Student: Is recording clearly explained, optional where policy allows, easy to pause and understandable when revoked?
• Instructor: What assignment policy applies? What alternative exists if a student cannot use the tool?
• University DPO/legal team: What is the applicable lawful basis, controller/processor relationship and proportionality assessment?
• Vendor: What happens to local unsealed evidence when consent is withdrawn? What happens to already shared or sealed records?

If an institution proposes mandatory processing, a checkbox alone should not be treated as proof of freely given GDPR consent. The university should determine its proper lawful basis and communicate it clearly.

FERPA: what U.S. universities should verify

The U.S. Department of Education's student privacy guidance explains conditions under which schools may disclose protected education-record information to a contractor under the school official exception, including direct institutional control of the information, limited use and restrictions on redisclosure. Its guidance on classroom apps advises educators to check institutional approval and involve IT staff.

Do not assume that purchasing an educational tool makes every data disclosure permissible. Ask the university's FERPA specialist to determine whether records or personally identifiable information from education records are involved, which lawful route applies, and how the school will exercise the necessary control.

Useful contractual questions include:

1. Can the vendor use information only to provide the institution's agreed educational service?
2. Is redisclosure limited and documented?
3. Can the university access records needed to respond to an eligible student's records request?
4. Are subcontractor obligations and breach responses written into the agreement?
5. What happens to the records when the contract expires or a student leaves?

A written agreement is a strong governance practice even where a specific FERPA exception does not independently mandate one. Legal teams should examine the actual arrangement rather than apply a generic "FERPA compliant" label.

GDPR: DPIA, data minimization and retention

For universities subject to the GDPR or UK GDPR, the processing may require particular scrutiny because writing activity can be granular and continuous during a session. The European Commission's guidance explains that a data protection impact assessment (DPIA) is required for processing likely to result in a high risk to individuals' rights and freedoms. Whether a particular deployment meets that threshold depends on the facts and relevant regulator guidance; it should not be automatically assumed either way.

The institution's review should record:

• Purpose: Why is process monitoring necessary for a given assessment or academic-integrity workflow?
• Necessity: Could a less intrusive approach meet the same objective?
• Proportionality: Are all captured event types required for the claimed benefit?
• Transparency: Can a student understand what is observed and what is inferred?
• Rights: How are access, correction, objection and deletion requests assessed, including lawful exceptions?
• Transfers: Which countries and subprocessors handle which data categories?
• Retention: What is the justified period for unsealed drafts, sealed records, logs and backups?
• Fairness: Could an observed gap reflect accessibility or technical limitations rather than misconduct?

A DPIA is useful only if it changes design, controls or scope where needed. A vendor's privacy page is evidence to review, not a replacement for the university's assessment.

What AuthMarks publicly discloses—and what still requires a contract

AuthMarks' privacy policy, effective 17 September 2026, describes explicit document-level consent and standard hosting in Finland (EU), subject to enterprise arrangements. It discloses that recording telemetry may include typing patterns, timing, editing, copy/paste events, focus/idle metadata and other session information when the relevant features are enabled.

The public policy also lists different default retention categories for standard accounts: 90 days for unsealed session telemetry, a typical seven years for sealed provenance records and manifests, and other periods for logs and support data, subject to documented exceptions and enterprise agreements. Those periods are not automatically appropriate for every university. In particular, the institution must confirm how erasure requests, litigation holds, recordkeeping requirements and contract termination interact with the integrity of sealed evidence.

Public AuthMarks statement	What an institutional purchaser should confirm
Recording is off by default and document-level opt-in	User-facing consent states and policy treatment for mandatory coursework
Standard hosting is in the EU	Exact storage, backup and subprocessor locations for the proposed institution
Sealed records are tamper-evident and independently checkable	Validation demonstration, key management and independent verification after contract exit
Unsealed and sealed records have different retention rules	Negotiated retention periods, deletion mechanisms and lawful preservation grounds
Institutional roles and policies can be configured	Actual role matrix, access logs, incident response and availability under the purchased tier
LTI 1.3 integration is publicly documented	Which identity/role, roster and grade fields are requested and why

The public material does not replace a security questionnaire, executed data-processing agreement, third-party assurance evidence or an approved university deployment design. Do not represent this guide as a SOC 2, ISO 27001, GDPR, FERPA or 1EdTech certification. Request evidence for any specific certification separately.

Review the meaning of independent verification

A cryptographic integrity check and a writing-process interpretation are not interchangeable.

A successful seal check may establish that the retained record has not changed since it was sealed. It does not, on its own, prove that the physical user at the keyboard was the named student, that every external writing action was observed, or that a statement in the record is true.

Ask the vendor for a normal-user demonstration that answers:

1. What exact artifact is sealed?
2. Which parts of it can an independent recipient verify without a vendor login?
3. What does a successful check show—and what does it not show?
4. Can the institution preserve records during an appeal after a vendor contract ends?
5. Can a reviewer append a note without altering the originally signed evidence?

This can be demonstrated at the product behavior level without disclosing proprietary capture algorithms, security defenses or private signing materials.

A security questionnaire procurement teams can actually use

Request written evidence rather than checkmarks:

Area	Ask for	Minimum demonstration
Authentication	Account/MFA and institutional identity options	Student and staff role separation
Authorization	Role permissions and access-control testing	Attempted access to another course's record denied
Transmission and storage	Encryption architecture and key responsibility	Approved security documentation and contractual guarantees
Audit logging	Access-event coverage, retention and export	Example record-access audit trail
Incident handling	Notification process, escalation contacts and response commitments	Written incident-response agreement
Subprocessors	Current list, functions, geography and change notices	Vendor-provided subprocessor register
Data deletion	Deletion versus preservation rules; backup treatment	Test record lifecycle and termination export
Resilience	Availability expectations, backups and recovery objectives	Operational continuity plan or documented service commitments
Assurance	Pen-test summary, independent assessment or certifications if held	Current supporting evidence, not a generic logo
Accessibility	Supported assistive technologies and alternate paths	Participatory tests on real student workflows

Do not request disclosure of exploit details or proprietary internals. Universities can receive credible assurance through independent reports, scoped demonstrations, clear contractual controls and security summaries.

What a fair student-appeal workflow should look like

A provenance tool should support an academic process, not secretly replace one. Before production launch, document what happens when a student disputes an interpretation:

1. Preserve the original submitted artifact and the relevant evidence state.
2. Confirm that an authorized reviewer understands the observed actions and untracked gaps.
3. Give the student a meaningful opportunity to explain the writing workflow, accessibility accommodations, technical failures or permitted sources.
4. Record whether additional evidence—drafts, oral discussion, citations, version history—supports or contradicts an initial concern.
5. Apply established institutional rules through authorized decision-makers.
6. Retain or remove records under an approved policy, documenting legal holds and rights requests where relevant.

An "automated," "pasted," or "unknown" label does not itself establish cheating. This is both a fairness principle and an important procurement test of whether a vendor's interface encourages overinterpretation.

Suggested 30-day privacy and security review plan

Week 1: Data map. Define pilot cohort, data categories, student notice, processing role, local law, intended retention and purpose. Agree on one institution-approved test assignment.

Week 2: Technical controls. Demonstrate capture opt-in, pause/stop behavior, role separation, LMS launch data, report sharing and access logs. Use synthetic student records.

Week 3: Operational controls. Test export, deletion or restriction workflow, interrupted sessions, accessibility alternatives, a mock breach communication path and reviewer training.

Week 4: Decision. Finalize DPIA or other privacy assessment as required, remediation list, written vendor responses, procurement criteria and a decision on limited rollout versus further testing.

The purpose is to identify whether the vendor and institution can responsibly run the workflow—not to certify legal compliance in 30 days.

Validate the actual deployment environment

The privacy assessment should use the same identity and record-sharing settings that will be used in Canvas, Blackboard or Moodle.

Frequently asked questions

Is writing provenance software automatically FERPA compliant?

No. A U.S. institution must examine its own data flows, contracts and permitted disclosures under FERPA, including whether and how the vendor operates under institutional control.

Does student consent alone resolve GDPR requirements?

No. Where GDPR applies, an institution must establish an appropriate lawful basis and meet all applicable processing, transparency, security and rights obligations. The proper approach depends on the specific deployment.

Does a cryptographic seal prove who wrote the document?

No. It provides a means to verify integrity of the sealed record. Person-level identity, capture coverage and academic-intent questions require additional evidence.

Can a university set its own retention periods?

That depends on the vendor's actual product, tier and contract as well as legal recordkeeping requirements. AuthMarks says institutional retention controls and enterprise agreements are available; obtain the exact terms in writing.

What should happen when recording was off?

The gap should be acknowledged as missing observation, not silently presented as verified human writing or treated as automatic misconduct. Academic staff should assess it in context.

Bring privacy and security into the purchasing decision early

By the time a university asks for a live pilot, it should already have a preliminary data inventory and the right stakeholders involved. Privacy, accessibility and evidence limitations directly affect whether the technology can be used fairly and sustainably.

Use the university authorship verification procurement checklist and 30-day pilot guide to structure that discussion. For an AuthMarks-specific deployment and contract, contact AuthMarks for institutions.

Related: Procurement checklist · 30-day pilot playbook · Pricing guide · Canvas integration guide · Blackboard integration guide · Moodle integration guide