FERPA-Compliant Customer Support: A Guide for Edtech

Most edtech companies know FERPA applies to them. Fewer think carefully about what happens when a support agent accesses a student account to resolve a ticket.

That agent is touching education records. The conversation is logged. The ticket contains a student name, enrollment status, and possibly academic performance data. If the agent works for an outsourced support provider, the institution has shared protected student information with a third party. Whether that sharing is legal under FERPA depends entirely on how the outsourcing relationship is structured.

The generic "what is FERPA" guides cover the basics. This article covers the operational question those guides skip: how to outsource support for an edtech platform, online-learning provider, or education-services company without creating FERPA compliance exposure.

Key takeaways

• FERPA covers any vendor whose agents access student education records, including outsourced support teams handling account queries, enrollment issues, or academic data.
• The "school official" exception under 34 CFR §99.31 is the legal basis for outsourcing support. It permits sharing without extra consent under specific conditions.
• FERPA compliance is not a product feature. It is a governance model: training, access controls, data processing agreements, and audit trails all have to be in place.
• No tool is FERPA compliant by itself. ChatGPT, Zendesk, and Salesforce are neutral; compliance depends on configuration, data handling, and the policies governing use.
• The most common FERPA failures in outsourced support are untrained agents, missing DPAs, and incorrect handling of parental rights after a student turns 18.

What FERPA compliance requires

The Family Educational Rights and Privacy Act (FERPA) protects the education records of students at institutions that receive federal funding. It applies to K-12 schools, universities, and any edtech or education-services company that handles education records on behalf of those institutions.

FERPA compliance requires four things at the operational level:

• What it protects. Education records include any record directly related to a student that the institution maintains: grades, enrollment data, disciplinary records, financial aid information, and any personally identifiable information (PII) linked to a student. Support tickets containing student account data fall within this definition when they are maintained by the institution or its vendors.
• Consent as the default. Institutions generally cannot disclose education records without written consent from the student (or parent, if the student is under 18). There are exceptions, but they are specific and conditions-bound.
• Annual notification. Institutions must notify students annually of their FERPA rights, including the right to inspect and correct their records.
• Secure handling. FERPA does not prescribe specific technical controls, but requires that records be protected from unauthorised access and that data is used only for legitimate educational purposes.

For edtech companies, FERPA compliance is not a checkbox. It is a live operational obligation that extends to every vendor, tool, and support agent that touches student data.

FERPA and third-party vendors: the "school official" exception

he legal basis for outsourcing support that handles student data is 34 CFR §99.31(a)(1), commonly called the "school official" exception. Understanding it precisely matters because getting it wrong is not a technicality. It is a FERPA violation.

Under this exception, an institution may share student education records with an outside vendor without obtaining additional consent, provided four conditions are met:

• The vendor performs a service the institution would otherwise perform itself. Customer support for a student-facing platform qualifies. The institution would handle those contacts in-house if it did not outsource them. A vendor providing unrelated services would not qualify.
• The vendor is under the direct control of the institution. This means the institution sets the rules for how student data is accessed and used. The vendor does not make independent decisions about data handling. In practice, this requires a formal data processing agreement (DPA) that defines the vendor's obligations, the institution's authority, and the permissible uses of student data.
• The vendor uses the data only for the agreed purpose. A support agent accessing a student's enrollment record to resolve a billing query cannot use that information for any other purpose. Re-disclosure is prohibited without separate consent.
• The vendor meets the institution's FERPA compliance standards. The institution cannot simply sign a contract and assume compliance. It must actively verify that the vendor's agents are trained, that access is controlled, and that data handling matches FERPA requirements.
• Legitimate educational interest is the related concept: the vendor's access to student data must be limited to what is necessary to perform the specific service. A support agent handling a password reset does not need access to a student's grade history. Role-based access controls are how this is enforced operationally.

When research data for a third party FERPA situations arise (such as an edtech vendor using aggregated student data for product analytics) separate de-identification or consent requirements apply. Support operations typically do not involve research use of data, but the distinction matters for edtech companies whose vendors handle data in multiple ways.

What FERPA-compliant support looks like in practice

FERPA compliance in a support operation is a set of operational controls applied consistently across every contact type that could touch student data.

Agent training and background checks

Every agent who handles contacts involving student education records must complete documented FERPA training before accessing live systems. Training should cover: what qualifies as an education record, what agents can and cannot share, how to handle a parent request when a student is over 18 (rights transfer to the student at 18, regardless of who is paying), and what to do when a contact requests information the agent is not authorised to provide.

Training must be renewed periodically and be auditable. The institution needs to be able to demonstrate that agents were trained at a specific date if a compliance review occurs.

Background checks for agents handling sensitive student data are standard practice in regulated support environments, particularly for K-12 platforms where agents may encounter records involving minors.

Role-based access controls

Agents should have access only to the student data necessary for their specific support function. A technical support agent resolving a login issue does not need to see financial aid records. A billing agent does not need to see academic progress data.

Access controls should be configured at the ticket system level, not managed manually. Permission sets should be reviewed when agents change roles, and access should be revoked immediately upon contract end.

Ticket and call handling

Support tickets that contain student PII should be handled within compliant systems only. Copying student data into external tools (including general-purpose AI assistants) is a compliance risk unless those tools are specifically configured and governed for FERPA use.

Call recordings that contain student education records are themselves education records under FERPA. They must be stored in compliant systems with access controls, and they must be included in the institution's records-retention and deletion policies.

Data processing agreements

A signed DPA between the institution and the support vendor is not optional. It is the document that establishes the institution's direct control over data handling, defines permissible use, requires the vendor to maintain appropriate security controls, and sets out breach-notification timelines. Without a DPA, the school official exception does not apply.

Audit logging and breach response

Every access to student records by a support agent should be logged with a timestamp, agent ID, and contact reference. These logs are the evidence trail for any compliance review or breach investigation.

Breach response timelines under FERPA are not prescribed to the day, but prompt notification to affected institutions and students is expected. Support vendors should have documented incident response procedures that include FERPA-specific notification steps.

How to vet a FERPA-compliant support vendor or tool

The due diligence question is not "are you FERPA compliant?" A vendor can say yes to that question regardless of what their actual practices look like. The useful questions are more specific:

Question	What a good answer looks like
Do you sign a FERPA-compliant DPA?	Yes, with specific provisions for direct control, permissible use, and re-disclosure prohibition
How is agent access to student data controlled?	Role-based permissions at the system level, not manual policy
How do you handle agent FERPA training?	Documented, dated, auditable, renewed on a defined schedule
What certifications do you hold?	ISO 27001 (information security), ISO 27701 (privacy), SOC 2 Type II
Where is student data stored and processed?	Data residency within a defined geographic boundary if required
What is your breach notification process?	Documented incident response procedure with notification timelines
How do you handle data deletion at contract end?	Written deletion or return of data within a defined timeframe

On FERPA compliance software and FERPA compliant software: platforms like Zendesk, Salesforce, or Intercom are not inherently FERPA compliant or non-compliant. Compliance depends on how they are configured, which data fields are populated, how access is controlled, and what the governing agreements say. The same applies to AI tools in the support stack.

Is ChatGPT FERPA compliant? In its standard consumer form: no. OpenAI's standard terms do not meet the requirements for direct institutional control, and data entered into ChatGPT may be used for model training by default. For edtech support, AI tools should only be used when the vendor has signed a data processing agreement that addresses FERPA requirements, data is not used for training, and the institution retains control. Enterprise configurations of some AI tools can meet these requirements. The standard consumer version cannot.

COPPA and FERPA compliant requirements arise together for K-12 platforms and any edtech serving users under 13. COPPA requires verifiable parental consent before collecting personal information from children under 13, and its requirements layer on top of FERPA rather than replacing it. A support operation handling contacts from or about students under 13 must address both frameworks simultaneously.

Common FERPA mistakes in outsourced support

FERPA violations in outsourced support rarely happen because a vendor decided to ignore the law. They happen because a specific scenario was not anticipated, an agent was not trained on an edge case, or a process that worked at small scale was never updated as the operation grew. The failure modes below are the ones that appear most often and each one is preventable with the right operating model.

• Disclosing records to the wrong parent after age 18. FERPA rights transfer entirely to the student at 18. A parent calling to ask about their child's account, grades, or enrollment status has no right to that information after the student turns 18, regardless of who is paying tuition. Agents untrained on this point are the most common source of FERPA violations in edtech support.
• Untrained agents over-sharing. An agent who has not been trained on FERPA may answer a reasonable-sounding request with information they should not provide. "Can you confirm my daughter is enrolled?" sounds like a routine question. After age 18, it is a FERPA-protected record and requires student consent to disclose.
• No DPA in place. Operating without a signed data processing agreement means the school official exception technically does not apply. The vendor is handling student data without the legal basis to do so.
• Re-disclosure without consent. Support vendors must not share student data with any third party outside the agreed support function without institution approval. This includes escalation to technology vendors, translation services, or quality monitoring tools not covered by the original DPA.
• Mishandling directory information opt-outs. Institutions can designate certain student information as "directory information" (name, enrollment status, graduation date) and share it more freely, unless the student has opted out. A support agent accessing a student who has opted out of directory information disclosure must apply the same restrictions as for any other protected record.
• COPPA FERPA compliant gaps in K-12 operations. Platforms serving students under 13 that have FERPA controls in place may still have COPPA exposure if consent workflows, data collection practices, or third-party integrations were not reviewed against both frameworks.
• Storing student data in non-compliant tools. Support agents who copy student information into general-purpose tools (shared documents, personal email, non-governed AI assistants) create compliance exposure that the DPA cannot cover.

How can schools stay compliant with FERPA when they outsource

FERPA compliance in outsourced support does not happen at contract signature. It is built through the operational model, starting before the first agent handles a live contact.

• Vendor selection. Require a FERPA-compliant DPA as a pre-condition of engagement. Confirm the vendor holds ISO 27001 and SOC 2 Type II certifications as baseline evidence of information security maturity. Ask for documented FERPA training materials and audit logs as part of the procurement process.
• Onboarding. Every agent handling student-facing contacts should complete FERPA training before system access is granted. Access permissions should be set at the role level from day one, not adjusted after go-live.
• Training cadence. Annual FERPA refresher training is standard practice. When regulations are updated, agent briefings and knowledge base materials should be updated at the same time.
• Monitoring and QA. QA programmes for edtech support should include FERPA-specific review criteria: did the agent verify the caller's identity before sharing information? Did the agent handle a parent request correctly? Was the contact resolved without unnecessary data disclosure?
• Ongoing audit. Access logs, DPA terms, and agent permission sets should be reviewed at least annually. If the vendor adds new AI tools or sub-processors to the support stack, the DPA should require notification and approval before those tools access student data.

Simply Contact operates support programmes for regulated environments including healthcare and financial services under HIPAA, GDPR, ISO 27001, ISO 27701, and PCI DSS frameworks. The compliance operating model (documented agent training, role-based access controls, signed DPAs, audit trails, and QA oversight) transfers directly to FERPA-governed edtech support engagements. The same governance infrastructure that keeps patient data secure keeps student education records protected.

Talk to our team about what FERPA-compliant outsourced support looks like for your edtech platform, or explore compliance-aware customer support outsourcing.

FERPA compliance and outsourcing are not in conflict

The concern that outsourcing support creates FERPA risk is understandable. The answer is that it creates manageable risk, risk that becomes genuine exposure only when the vendor relationship is structured incorrectly.

When the school official exception applies, when the DPA is in place, when agents are trained and access is controlled, outsourced support is as FERPA compliant as in-house support. Often more so, because a specialist provider has built the compliance infrastructure as an organisational capability rather than a one-time project.

The question for edtech companies evaluating outsourced support is whether the specific partner they are evaluating has done it before and can demonstrate that they have.