FERPA Sub-Processor Compliance Assessment

TheAccessible.Org — AnglinAI Prepared: April 2026 | Classification: Confidential — Internal Use Only

Purpose & Scope

This document assesses the FERPA compliance posture of each third-party vendor (sub-processor) used in TheAccessible.Org product suite. It is intended to inform the vendor sub-processor disclosure list, guide architecture decisions around sensitive data flows, and support the pre-drafted FERPA Data Processing Addendum (DPA) offered to university customers.

TheAccessible.Org products — including Accessible PDF, AccessibleShots, LinkReach, Accessible Music, and Accessible Org Charts — target universities, government agencies, and compliance consultants. Documents processed through these tools may contain student Personally Identifiable Information (PII) covered by FERPA. Each sub-processor in the call chain therefore requires evaluation.

FERPA Compliance Background

FERPA (Family Educational Rights and Privacy Act, 20 U.S.C. § 1232g) governs the privacy of student education records at institutions receiving federal funding — effectively all U.S. public and private universities. Key points relevant to vendor selection:

FERPA does not certify vendors. There is no official FERPA certification. Each institution must assess whether its vendor relationships satisfy the law.
The School Official Exception permits universities to share student data with third-party vendors, provided the vendor: performs an institutional service, is under direct control of the institution regarding data use, is designated as a school official in the institution’s annual FERPA notification, and agrees not to re-disclose records.
The legal burden falls on the institution, not the vendor. However, vendors with documented compliance commitments dramatically reduce procurement friction.
No AI training on student data is the single most important commitment a vendor can make. University IT and legal teams flag this first.
Data must remain in the United States. Standard contractual expectation from university legal teams.

Summary: Vendor Compliance Status

Vendor	FERPA Status	Key Risk	Mitigation
AWS	✅ Strong	Shared responsibility model	Configure per FERPA whitepaper
Google Gemini	✅ Strong*	Requires Google Cloud / Workspace agreement	Sign Cloud DPA; use Workspace for Education
Cloudflare	✅ Adequate	Not FERPA-specific; CDN/proxy role only	Sign their standard DPA
Supabase	✅ Adequate	No explicit FERPA page; US region required	Enterprise plan + DPA; list as sub-processor
Anthropic API	⚠️ Conditional	Not compliant by default; prompts may be retained	Zero Data Retention agreement required
Datalab / Marker	🔴 Gap	No compliance program; no published DPA	Use Marker on-prem / open-source locally
Mathpix	🔴 Gap	Default 30-day retention; human QA review of images	Enable data retention opt-out; no formal DPA

* Google Gemini FERPA support applies within Google Workspace for Education or under a Google Cloud DPA. Raw API usage without a signed agreement does not carry these protections.

Vendor Detail Findings

Amazon Web Services (AWS)

✅ Strong

AWS has a dedicated FERPA compliance page and publishes a detailed FERPA compliance whitepaper covering 24 AWS services. AWS implements physical and logical controls and provides customers security, identity, and compliance tooling to build FERPA-compliant solutions.

AWS operates under a shared responsibility model: AWS secures the infrastructure; the customer is responsible for securing what is deployed on it. AWS offers AES-256 encryption at rest, TLS in transit, AWS KMS for key management, CloudTrail for audit logging, and US-only data residency configuration.

Action required:

Configure all S3 buckets, RDS instances, and compute for least privilege.
Enable CloudTrail and VPC Flow Logs.
Select US East/West regions only for any FERPA-covered data.
Reference AWS FERPA whitepaper when completing university vendor questionnaires.

Google Gemini API

✅ Strong (conditional)

Gemini has attained SOC 1/2/3, ISO 27001, ISO 27701, ISO 42001 certifications, and FedRAMP High authorization. Within Google Workspace for Education, Gemini explicitly supports FERPA and COPPA compliance, with chats not reviewed by humans and not used for model training.

However, these protections are tied to a Google Workspace for Education agreement or a Google Cloud Data Processing Addendum. Using the Gemini API via AI Studio or a raw API key without a signed DPA does not carry FERPA protections.

Action required:

Sign a Google Cloud Customer DPA that includes FERPA obligations.
Process any FERPA-covered documents through a properly provisioned Google Cloud project — not AI Studio or personal API keys.
Confirm sub-processor data stays in US regions within Google Cloud settings.

Cloudflare

✅ Adequate

Cloudflare holds ISO 27001, ISO 27701, SOC 2 Type II, and PCI DSS Level 1 certifications. It offers a standard Data Processing Addendum covering personal data handling obligations.

Cloudflare’s role in TheAccessible.Org stack is primarily CDN, DNS, and reverse proxy. In this role it routes traffic but does not store student document content. It is not a primary data processor for FERPA-covered records.

Action required:

Execute Cloudflare’s standard Customer DPA.
List Cloudflare on the sub-processor disclosure page.
Confirm that Cloudflare Workers, if used, do not persist student document content.

Supabase

✅ Adequate

Supabase is SOC 2 Type 2 certified and HIPAA-eligible under a Business Associate Agreement (available on Enterprise and Team plans). All data is encrypted at rest with AES-256 and in transit via TLS. Supabase does not publish a dedicated FERPA page but is used as infrastructure by multiple iKeepSafe-certified EdTech platforms.

Supabase supports US-region deployments (us-east-1, us-west-1), satisfying the data residency requirement. Fine-grained row-level security (RLS) supports access control requirements.

Action required:

Upgrade to Enterprise or Team plan to access the BAA/DPA.
Execute a Data Processing Agreement with Supabase.
Specify US regions only for all FERPA-covered data.
List Supabase on the sub-processor disclosure with data center region noted.
Enable RLS on all tables that could store student data.

Anthropic API (Claude)

⚠️ Conditional

The Anthropic API is not FERPA compliant by default. Under standard API terms, Anthropic may retain prompts and outputs for a period of time. Third-party assessments have noted that standard Claude usage in an education context — such as processing student documents — could constitute a FERPA violation without proper contractual controls.

Anthropic offers a Zero Data Retention (ZDR) agreement for API customers, under which prompts and outputs are not stored after processing. Anthropic also offers a HIPAA-ready Business Associate Agreement for enterprise customers with ZDR in place.

The ZDR configuration is the critical control that makes the Anthropic API viable for FERPA-covered workflows.

Action required:

Negotiate a Zero Data Retention (ZDR) agreement with Anthropic.
Pursue the HIPAA BAA as a parallel commitment (strengthens the overall compliance posture).
Do not process student PII through the Anthropic API until ZDR is in place.
List Anthropic as a sub-processor with a note that ZDR applies.
Avoid using Claude.ai (the consumer product) for any student data — ZDR and BAA apply only to the API.

Datalab / Marker (Hosted API)

🔴 Gap

Datalab’s hosted API at datalab.to has no published FERPA compliance documentation, no Data Processing Addendum, and no sub-processor disclosure list. There is no documented data retention policy, no prohibition on model training with uploaded content, and no school official commitment.

Marker is the PDF-to-markdown conversion engine underlying the Accessible PDF pipeline. The hosted API sends documents to Datalab’s servers, creating an undisclosed and uncontrolled sub-processor relationship for any FERPA-covered content.

Datalab does offer an on-premises enterprise license, and Marker is also available as open-source software under an AGPL/commercial license. Running Marker locally eliminates the sub-processor risk entirely.

Recommended action:

Do not use the Datalab hosted API for any documents that may contain student PII.
Deploy Marker locally within the TheAccessible.Org infrastructure (Docker container or dedicated server). This is architecturally preferable regardless of compliance — it reduces API costs, latency, and external dependencies.
For on-prem customer deployments, bundle local Marker as part of the Docker compose stack.
If the hosted API must be used for non-FERPA workloads, contact Datalab to request a DPA and confirm data handling terms.

Mathpix (Convert API)

🔴 Gap

Mathpix has SOC 2 Type 2 certification and is hosted on AWS. However, its default data handling practices create significant FERPA exposure: images submitted to the API are retained for up to 30 days in a QA database and may be reviewed by Mathpix’s quality assurance team — a disclosure to a third party that FERPA directly controls.

Additionally, Mathpix Snip integrates with OpenAI and Anthropic APIs for generative features, routing document content through those systems. There is no published FERPA DPA, no school official commitment, and no prohibition on data use for model training in the standard terms.

Mathpix does offer a Data Retention Opt-Out, which deletes images within 24 hours and prevents them from being saved to disk. This significantly reduces risk but does not constitute a FERPA compliance commitment. A formal DPA does not exist.

Recommended action:

Do not use Mathpix for any documents that may contain student PII without a signed DPA.
If Mathpix is used for math OCR on non-FERPA content, enable the Data Retention Opt-Out in Convert API settings immediately.
Contact Mathpix to request a formal FERPA Data Processing Agreement. As of this writing, none is published.
Evaluate replacing Mathpix with local Marker + use_llm (which uses Gemini via a properly credentialed Google Cloud account) for the math-heavy document pipeline. This consolidates sub-processors and removes Mathpix from the chain.
For the Accessible Music product (sheet music conversion), assess whether Mathpix is in the data path and whether student data could flow through it.

Architecture Recommendations

The following changes are recommended to achieve a defensible FERPA sub-processor posture across all TheAccessible.Org products:

1. Run Marker Locally

Replace the Datalab hosted API with a locally deployed Marker instance. Marker is open source, runs on GPU or CPU, and produces equivalent or superior output to the hosted API for most document types. This eliminates the most critical gap in the sub-processor chain and improves the on-prem deployment story for university customers.

2. Secure a Zero Data Retention Agreement with Anthropic

Before processing any student documents through the Anthropic API, a ZDR agreement must be in place. Engage Anthropic’s sales team to initiate this process. The ZDR agreement, combined with a DPA, transforms the Anthropic API from a compliance gap into a defensible sub-processor.

3. Execute DPAs with All Remaining Vendors

Formal Data Processing Agreements should be executed with: AWS (available via AWS artifact/standard), Google Cloud (Cloud DPA), Cloudflare (standard DPA), and Supabase (Enterprise plan). Maintain a sub-processor list that includes vendor name, data center region, data type processed, and DPA status.

4. Publish a Sub-Processor Disclosure Page

TheAccessible.Org’s trust/compliance page should include a current sub-processor list. This is a standard expectation from university procurement teams and reduces back-and-forth during vendor review. The list should be updated whenever sub-processors change.

5. Implement Zero Retention at the Application Layer

Even with vendor DPAs in place, TheAccessible.Org should implement document processing with zero persistence: documents are processed in memory, converted, and immediately discarded. No student document content should be stored in Supabase or any persistent store. This architectural commitment is a strong selling point and reduces vendor compliance dependency.

6. On-Premises Deployment Option

For university customers with strict data governance requirements, the Docker-based on-premises deployment option eliminates all sub-processor concerns. The on-prem stack should include local Marker, local inference where needed, and a local Supabase instance or PostgreSQL alternative. This is the primary answer to air-gapped and FISMA environments.

Next Steps

Immediate: Engage Anthropic sales for Zero Data Retention agreement
Immediate: Enable Mathpix Data Retention Opt-Out for all existing API keys
Short-term: Deploy local Marker instance; retire Datalab hosted API from FERPA workflows
Short-term: Execute Google Cloud DPA covering Gemini API usage
Short-term: Execute Supabase Enterprise DPA; upgrade plan if needed
Short-term: Publish sub-processor disclosure list on theaccessible.org/security
Medium-term: Have attorney draft FERPA DPA template for university customers
Medium-term: Complete SOC 2 Type 2 readiness assessment for AnglinAI
Medium-term: Document on-prem Docker deployment guide with FERPA compliance notes

Document Information Prepared by: AnglinAI / TheAccessible.Org | Date: April 2026 | Review cycle: Quarterly

This document is based on publicly available vendor documentation and privacy policies as of the preparation date. Compliance postures may change. Re-evaluate whenever a vendor updates its terms, privacy policy, or certifications.