A product team adds an analytics SDK to understand where students are abandoning an online lesson.
Technically, it is a small maintenance release.
But the change may alter far more than the application code. New interaction data could now leave the platform. A third party may process student identifiers or device information. Data-retention assumptions may change. Privacy notices or contractual disclosures may need reviewing.
Now imagine the next release replaces the quiz component with a more modern interface. Visually, it looks better. For a student navigating by keyboard or screen reader, however, the new version may be harder—or impossible—to complete.
Neither release was intended to change the application's privacy or accessibility posture.
Both could.
That is what makes maintaining EdTech applications different from treating privacy, accessibility and compliance as launch checklists.
Every meaningful change to an EdTech application can alter who has access to data, what information is collected, which third parties receive it, how students interact with the product and which legal or contractual obligations apply.
The exact requirements depend on where the product operates, who uses it, the age of those users, whether customers are schools or individuals, what data is processed and the contracts in place. A US K–12 product may encounter FERPA and COPPA considerations, while a service used by children in the UK may need to consider the Children's Code. Public educational institutions may also operate under accessibility requirements that differ from those applying to private organizations.
The maintenance principle, however, is consistent: compliance has to be preserved as the product changes.
For Levelworks, this connects most directly to Compliant, alongside Secure, User Friendly & Delightful and Tested App Health.
Privacy maintenance becomes difficult when nobody can confidently answer:
What student information does this application currently collect, where does it go and why do we still have it?
The answer often changes gradually after launch.
A product begins with:
Later releases add:
Each addition can create a new data flow.
Maintain an inventory covering important categories such as:
Question
What should be known
What data is collected?
Student, parent, teacher and device information
Why is it collected?
Learning function, administration, support, analytics, security
Where is it stored?
Application databases, logs, vendors, backups
Who receives it?
Internal roles and third parties
How long is it retained?
Active-use and deletion periods
How is it deleted?
Account, contract and retention workflows
Which customers/users are affected?
School, district, individual, age group, geography
This does not need to become a giant spreadsheet documenting every database column.
It needs enough fidelity that a maintenance change can be compared against the application's existing data practices.
If adding a feature introduces a new data category or recipient, the team should notice before the release reaches production.
For US educational institutions, FERPA is one of the laws that can affect how student education records are disclosed and handled.
FERPA directly regulates educational agencies and institutions receiving applicable federal funding, but EdTech providers can become part of the school's compliance model.
Under the FERPA school official exception, a contractor or other third party may receive personally identifiable information from education records without individual consent when specific requirements are satisfied. Among other conditions, the provider must perform a function the institution would otherwise use employees for, remain under the institution's direct control regarding the use and maintenance of education records, and comply with restrictions on use and redisclosure. US Department of Education: FERPA and the school official exception
For maintenance teams, that has practical consequences.
Suppose a school-approved learning platform begins sending student activity to a newly added analytics provider. The technical question may be whether the SDK works.
The privacy question is whether this new disclosure is consistent with the purposes and controls under which the school provided the information in the first place.
The US Department of Education specifically advises schools to evaluate online educational services that collect student PII, including whether information is being used or redisclosed for unauthorized purposes. US Department of Education: Using online tools under FERPA
That is why third-party changes deserve privacy review even when the application's own database schema has not changed.
For US services within scope, COPPA applies to operators of commercial websites and online services directed to children under 13, as well as certain operators with actual knowledge that they collect personal information from children under 13.
The FTC's amended COPPA Rule became effective on June 23, 2025, with most regulated entities required to comply with the amended provisions by April 22, 2026. The revisions strengthened requirements around areas including data retention and deletion, security and certain disclosures to third parties. FTC: COPPA Final Rule Amendments
For EdTech providers, one nuance matters: the FTC did not finalize its proposed 2025 changes specifically addressing school authorization in EdTech. It said it would continue applying COPPA to EdTech under its existing guidance while potential FERPA changes were considered.
The FTC's broader EdTech policy has also emphasized that covered providers have their own COPPA responsibilities; schools cannot simply absorb those obligations on the provider's behalf. FTC: Policy Statement on Education Technology and COPPA
From a maintenance perspective, COPPA should therefore trigger questions whenever a release changes:
Adding “just one more analytics event” can still be a privacy change.
Applications are very good at accumulating information.
They are usually less naturally good at deleting it.
A retention policy might say:
Delete student information after the contractual relationship ends.
The application then evolves.
A reporting database is introduced. Logs are moved to another platform. A search index receives copied records. An analytics provider retains its own event history.
The original deletion workflow may remove the primary account while leaving data elsewhere.
The FTC's amended COPPA Rule now expressly addresses retention and deletion protocols for covered children's information, including retaining personal information only for as long as reasonably necessary for the purpose for which it was collected.
Good maintenance therefore tests deletion as a system behavior, not merely a database operation.
When new storage locations or vendors are introduced, the deletion path should be revisited as well.
EdTech platforms commonly have several user types:
A seemingly ordinary feature can alter which information those roles can see.
For example, adding a district-level reporting dashboard could unintentionally expose student-level information more broadly than the previous product did.
Maintenance testing should therefore include authorization questions:
Can this user access information they should not?
not only:
Does the page load?
FERPA itself requires educational agencies and institutions relying on the school-official exception to use reasonable methods to ensure officials access only education records in which they have legitimate educational interests.
For the technology provider, maintaining reliable role and permission boundaries helps customers enforce that model.
Security testing and privacy maintenance overlap heavily here, although the wider security program deserves separate treatment.
[Internal Link: “Application Security Maintenance: What Needs to Happen After Launch?”]
EdTech applications often rely on outside services for:
Maintaining privacy therefore requires keeping a current view of the data-processing chain, not merely the application's direct database.
When introducing or replacing a third party, establish:
This review should happen again if the provider changes its own service terms or functionality in ways relevant to your use.
A vendor originally used only for error reporting, for example, may later offer session analytics that collect a much richer set of user interactions. Enabling the new functionality changes the privacy question even if the vendor name does not change.
EdTech products serving users in multiple countries need to map obligations by market rather than assuming one privacy design works everywhere.
In the UK, the Information Commissioner's Office's Children's Code applies to online services within its scope that are likely to be accessed by children. The Code contains 15 standards addressing issues including transparency, data minimisation, sharing, geolocation, profiling and privacy settings. ICO: Children's Code
The ICO specifically states that these standards should be built not only into initial design but also into subsequent upgrades and service-development processes.
That is exactly the maintenance problem.
A privacy-respecting default can be weakened later by an apparently unrelated product change.
For example, a new social feature could make profiles more discoverable. A new map function could introduce geolocation. A personalization feature could introduce additional profiling.
The original privacy review does not cover those decisions forever.
An inaccessible button on an ordinary consumer site is a usability problem.
An inaccessible Submit assignment button can prevent a student from completing schoolwork.
That makes accessibility maintenance particularly important in EdTech.
Common regressions appear when teams replace or modify:
A component may look better while losing keyboard operation, correct labeling, visible focus or appropriate screen-reader behavior.
Accessibility should therefore be included in regression testing for changed learning journeys rather than being treated as a separate annual audit.
[Internal Link: “Accessibility Maintenance: Keeping Your App Usable as It Evolves”]
WCAG remains the central technical reference for web accessibility. W3C currently recommends using WCAG 2.2, which adds requirements beyond WCAG 2.1 while retaining its earlier success criteria. W3C: WCAG Overview
However, legal requirements may reference a particular version.
A current US example is especially relevant to EdTech.
The US Department of Justice's Title II web and mobile accessibility rule requires covered state and local government entities to make applicable web content and mobile apps conform to WCAG 2.1 Level AA. This can include content and applications provided through contractual or licensing arrangements, making the rule relevant to technology supplied to public entities.
The timetable has also changed since the original rule was issued. In April 2026, the DOJ extended the compliance dates: covered public entities with populations of 50,000 or more generally have until April 26, 2027, while smaller public entities and special district governments generally have until April 26, 2028. School-district treatment depends on how the public entity is categorized and its relevant population. ADA.gov: Title II Web and Mobile Accessibility Rule
For maintenance teams, the broader lesson is more important than memorizing one deadline:
know which accessibility standard is contractual or legally relevant to each market and customer category, and preserve it release after release.
Automated checks can catch recurring problems such as missing labels, invalid ARIA usage and some contrast issues.
They cannot reliably determine whether:
Accessibility maintenance should therefore combine automation with targeted manual testing.
The depth should follow the change.
Updating a backend query may need no meaningful accessibility review.
Replacing the application's entire assessment component clearly does.
The goal is proportional testing, not running the same exhaustive audit after every release.
EdTech applications frequently combine software with educational content.
That creates another maintenance surface.
An application interface may remain technically accessible while newly uploaded content introduces:
Teams therefore need to distinguish responsibility for platform accessibility from responsibility for content accessibility.
If customers create their own learning materials, the product may also need accessible authoring workflows that help them avoid obvious mistakes.
Otherwise, the platform can pass an accessibility review while students still encounter inaccessible lessons inside it.
Not every maintenance ticket needs legal or compliance review.
That would slow routine development without improving outcomes.
Instead, establish triggers.
For example:
Change
Additional maintenance review
New analytics/advertising SDK
Privacy and data-flow review
New student-data field
Purpose, access and retention review
New external AI/vendor integration
Data-sharing/vendor review
New user role
Authorization/privacy review
New quiz or interaction component
Accessibility regression testing
New geography/customer segment
Applicable obligations review
Changed retention/deletion process
Privacy/compliance verification
Major accessibility component update
Keyboard and assistive-technology testing
This is much more practical than sending every pull request through a compliance committee.
The release process becomes sensitive to the kinds of change that actually alter risk.
A maintenance team should be able to show what it has done.
Useful evidence might include:
This matters because a policy stating that data is deleted after a defined period is less useful if nobody has verified that the current system actually performs the deletion.
Similarly, stating that an application is accessible is weaker than maintaining repeatable tests around critical learning workflows.
For Levelworks, this is where Compliant App Health overlaps with Tested and Well Documented. Controls become far more durable when they are observable, repeatable and supported by evidence.
[Internal Link: “Application Compliance Maintenance: Why Compliance Is Not a One-Time Project”]
Release-triggered review catches risks introduced by individual changes.
Periodic review catches gradual drift.
A quarterly or semiannual EdTech review might examine:
This should not become a ceremonial audit where every control receives a green checkbox.
Look specifically for differences between the product that was originally reviewed and the product that exists today.
Those differences are where maintenance risk accumulates.
A developer can finish a feature.
QA can verify that it behaves exactly as designed.
The release can deploy successfully.
For an EdTech application, that may still not be enough.
A stronger definition of done asks three additional questions before a meaningful change is closed:
Did this change alter what student data we collect, share, retain or expose?
Can the students who could use this workflow before still use it accessibly now?
Did the change alter any legal, contractual or compliance assumption under which the product is being provided?
Those questions do not require every engineer to become a privacy lawyer or accessibility specialist.
They require the maintenance process to recognize when those specialists need to become involved.
That is the practical meaning of maintaining Compliant App Health in EdTech: privacy, accessibility and compliance remain properties of the application as it exists today—not properties of the version that originally passed review.
