← Blog

FERPA AI Controls Mapping for the Authenticated LLM Path

Parminder Singh
Parminder Singh··6 min read
Summarize with AI

This FERPA AI controls mapping connects disclosure authority, legitimate educational interest, identity, purpose, destination policy, audit records, retention, and vendor evidence to named owners and repeatable tests. It keeps the authenticated HTTP enforcement boundary separate from consent, contract, student-rights, endpoint, and legal obligations.

Industry Verticalsai-complianceai-governancecomplianceauditidentity-and-authorizationpolicy-enforcement
FERPA AI Controls Mapping for the Authenticated LLM Path

A district control map shows "FERPA compliant" in one wide green cell while a teacher's AI request carries a student name to an unapproved endpoint. The label hides the decision that matters. A FERPA AI controls mapping should connect each disclosure requirement to an owner and enforcement point, while also naming the test and retained artifact, along with the boundary. The U.S. Department of Education's FERPA regulations establish consent and exception rules, access and recordkeeping rules, plus redisclosure rules. The Department's online educational services guidance applies those duties to providers performing school functions.

I would reject any FERPA control map whose evidence column says only "vendor attestation." That phrase records a procurement event. It skips the live disclosure path.

TL;DR

  • Give every mapping row a requirement and owner. Also name its control point and repeatable test, along with the evidence artifact and explicit boundary.
  • Separate disclosure authority and provider governance from request-time identity and purpose controls. Keep destination and classification controls distinct from policy enforcement.
  • Preserve the recipient and legitimate interest for covered disclosures, then test retrieval and record integrity.
  • Assign direct sessions and local models to adjacent controls. Do the same for stolen credentials and opaque vendor inference because a routed HTTP gateway cannot see them.

Build each row around a testable decision

The map should avoid broad rows such as "protect student data." Useful rows describe a decision that an assessor can reproduce. Under 34 CFR 99.30, written consent specifies the records and purpose, plus the party or class of parties; Section 99.31 permits specified disclosures without consent, including qualifying school officials and outsourced parties that meet the rule's conditions. Section 99.32 sets recordkeeping requirements for covered requests and disclosures, including the parties and legitimate interests.

Use six fields for each row: requirement and accountable owner; control point and test procedure; evidence and boundary. Add a stable control identifier so events and tickets, as well as contracts and findings, can refer to the same row. The AI audit trail requirements guide supplies reusable event fields. FERPA adds recipient and legitimate interest, along with disclosure authority, to that base.

The map becomes useful when another reviewer can run the test without interviewing its author.

Disclosure authority and purpose

Requirement: disclose education-record PII under valid consent or a documented FERPA exception, and limit use to the authorized purpose.

Owner: the FERPA privacy officer or counsel, working with the records owner and application owner.

Control point: the consent or exception registry supplies authority and purpose; the calling application attaches those values to the outbound AI request, and a request policy verifies that the purpose is allowed for the selected route.

Test: submit a synthetic tutoring request with an approved school-official purpose, then change the purpose to an unapproved use. Run a request with missing authority. Record the expected result before execution.

Evidence: authority identifier and purpose value; policy version and permit or denial event; reviewer and linked contract or consent record.

Boundary: legal interpretation and consent validity remain with the FERPA owner. A gateway evaluates the values supplied to it.

Identity and legitimate educational interest

Requirement: restrict school-official access to education records in which the official has a legitimate educational interest. Section 99.31 also requires reasonable methods to identify and authenticate parties receiving PII.

Owner: IAM and the application owner, with the records owner defining legitimate-interest rules.

Control point: the identity provider proves the user or workload. The application supplies the originating principal and role, along with the student relationship and workflow; request policy evaluates those attributes before forwarding the LLM call.

Test: run a counselor assigned to the student and an unassigned counselor against the same advising route, then repeat with an expired assertion and a shared relay credential missing the originating user.

Evidence: authentication result and role or relationship attributes; policy version and correlation identifier; resulting events.

Boundary: IAM owns proofing and assignment, plus lifecycle. The enforcement point cannot repair a false identity or relationship asserted upstream.

Destination and information-flow policy

Requirement: keep education-record PII inside authorized uses and recipients, including provider restrictions established under the school-official exception.

Owner: the data owner and privacy office, supported by security engineering alongside vendor management.

Control point: prompt classification and the destination allowlist before the external LLM endpoint. Response inspection applies the policy on returned content.

Test: send synthetic education-record PII to an approved contracted route, then repeat with an unapproved public model and use an approved route with a prohibited purpose. Confirm whether policy plans to permit or redact the request. For a denial, retain that event too.

Evidence: classifier and policy versions; approved-recipient register and test payload description; destination and action; reviewer sign-off.

Boundary: contract terms and provider subprocessors remain vendor-governance responsibilities; the same applies to storage location and deletion, along with redisclosure evidence. The shadow AI governance framework covers direct and embedded paths that bypass the managed route.

Disclosure records, retention, and access

Requirement: maintain the record required by 34 CFR 99.32 for covered requests and disclosures. The record identifies the parties and legitimate interests and stays with the student's education records for as long as those records are maintained.

Owner: records management with the privacy office, supported by security operations.

Control point: the per-decision event writer and protected store, joined to the student record or stable subject reference.

Test: freeze a one-week UTC population and let the reviewer choose a permitted disclosure and a denial. Retrieve each event, join it to the authority and identity records, and confirm the recipient and legitimate interest; alter a copied row and verify the integrity check fails.

Evidence: population manifest and selected events; query and join result; integrity output and storage permissions; retention configuration.

Boundary: the institution owns the official education record and parent or eligible-student access response. The gateway supplies one evidence source.

Provider direct control and redisclosure

Requirement: when an outsourced provider qualifies as a school official, document the institutional function and direct control over use and maintenance. Document restrictions on use and redisclosure as well. Department guidance says a contract is the usual method for establishing that control in practice, although FERPA regulations do not universally require a written agreement for the school-official exception.

Owner: vendor management and procurement, working with the privacy office and service owner.

Control point: contract approval and provider inventory; route allowlist and recurring evidence review.

Test: choose one AI provider and trace its approved function and contract restrictions, continuing through its subprocessor disclosures and destination configuration. Then trace a live request event and the termination or deletion procedure. Record any missing join as a finding with an owner and date.

Evidence: approved provider record and signed terms; subprocessor list and route policy; event sample and review notes; deletion or return evidence.

Boundary: a gateway records routed traffic. It cannot attest to a provider's internal storage or undisclosed model calls.

DeepInspect

DeepInspect operates at the authenticated HTTP boundary between users or agents and LLM endpoints. In this mapping it evaluates supplied identity and purpose, plus data classification and destination context; it applies permit, redact, or deny policy. It also inspects responses and writes a per-decision record tied to the policy version that ran.

The educational agency or institution retains responsibility for FERPA scope and legitimate educational interest. Its responsibility also covers consent and provider direct control, plus student rights and records management. Bypass paths remain its responsibility as well. DeepInspect contributes testable enforcement and evidence for requests routed through its boundary. Book a technical deep dive at deepinspect.ai.

Frequently asked questions

Should one FERPA requirement map to one product?

A complete row usually crosses several systems. Consent and exception records work with IAM and application context; request policy and provider contracts contribute evidence alongside event storage and records management. The map should preserve their joins and assign one accountable owner for the test.

How should shared service accounts appear?

Record the provider credential as the relay identity and preserve the originating user or agent supplied by the application. A shared account may authenticate the integration while leaving legitimate educational interest unresolved unless the event carries the principal and relevant relationship.

What makes a FERPA AI control test repeatable?

The test needs defined inputs and expected actions, a named route and policy version, plus retained event identifiers. Synthetic education-record PII protects students during testing. A second reviewer should be able to run the procedure and compare results.

Where should unresolved gaps appear?

Place each gap in the map with an owner and affected route. Add the risk statement and interim measure, plus the target date and retest evidence. A blank evidence cell hides missing coverage. A dated finding gives privacy and security teams, along with application teams, something concrete to close.

Which controls sit outside the HTTP request path?

Consent administration and FERPA exception interpretation sit outside the routed model call. The same applies to provider contracts and parent or eligible-student access. Endpoint management and credential-theft response need separate controls, as does records disposition. Direct browser use and local models also require separate controls, alongside opaque embedded inference.