Due Diligence on Free Software in Higher Education

Security teams should treat free software in higher education the same way they treat any other vendor: identify how it is funded, map exactly what happens to the data, model what happens if the service disappears, and insist on a practical exit path with tested exports and documentation.

1. Follow the money: what funds a free product

“Free” only describes the price to the institution, not the risk profile. The funding model usually tells you where the real incentives sit.

Common funding models you will see

• Ad-supported platforms: Revenue comes from advertising, often based on user behavior or metadata. Student and employer data may become part of ad targeting, even if not sold outright.
• Freemium products: A free tier subsidized by paid features or enterprise contracts. Risk is lower if there is a visible, paying customer base and audited security practices.
• Grant or foundation funded: Development and hosting are covered by time-limited grants. Sustainability risk rises sharply when the grant cycle ends.
• Institution-backed consortia: Costs are pooled across institutions. Governance is usually stronger, but decision-making can be slow.
• Data monetization: The product is free because user data is a revenue source, often via analytics, enrichment services, or resale.

From a security perspective, the questions are straightforward:

1. Who pays for infrastructure and staff, and for how long. If the answer is “a 2‑year grant,” you should assume higher discontinuation risk.
2. Is there a public revenue model you can point to. If the vendor cannot explain how they stay afloat, assume the data is the asset.
3. Are there concrete, recurring costs on their side, like cloud hosting or support. If so, you want to see sustainable cash flow to cover them.

How we are funded

Champlin Enterprises funds the Career Readiness Report as a free service to institutions. Revenue comes from separate, paid consulting and analytics work with employers and state systems, not from selling or exploiting student or employer data inside the platform. There are no ads, no data broker relationships, and no paid feature tiers inside the product.

This model still has risk: if those other revenue lines shrank, we would have to re-evaluate what we offer for free. That is why the questions about data handling, disappearance, and exit need precise answers, not reassurances.

2. What happens to the data

Security offices are usually comfortable with “where is it hosted” and “is data encrypted.” The harder questions are about purpose, secondary use, and lock-in.

Key questions to ask any free vendor:

• What data is collected, and what is optional. You want a data inventory that distinguishes required fields from “nice to have” profile data.
• Who can see which data. Separate student, employer, faculty, and administrator roles, and ask for examples of role-based views.
• Is data used beyond the immediate service. For training models, product research, marketing, or resale. Ask for explicit statements in the DPA.
• How long is data retained, and can retention be configured per institution. Storage is cheap, but risk grows over time.
• Is data segregated by institution. Logical or physical separation matters for incident response and legal process.

From a compliance angle, you also want to know whether the platform is a FERPA school official with legitimate educational interest, what is in their incident response plan, and how they notify you of a breach.

What happens to data in the Career Readiness Report

Concretely, here is how data is handled in our platform:

• Scope of data: Students self-report on the eight NACE Career Readiness Competencies and basic identifiers, and supervisors provide 360‑degree feedback. We do not collect Social Security Numbers, financial aid data, or academic transcripts.
• Purpose limitation: Data is used to generate individual reports for students, feedback reports for supervisors, and aggregate benchmarks and accreditation-ready reporting for the institution. It is not used for advertising or sold to third parties.
• Access control: Student-level data is visible only to the student and institution-authorized users with appropriate roles. Employers and faculty see only the evaluations they submit or are tied to. Champlin staff access is limited to support and maintenance and logged.
• Hosting and security: Data is hosted in a major US cloud provider, encrypted in transit and at rest, with institution-level logical separation. Incident response and breach notification terms are documented and shared during onboarding.

These controls are not unique, and other vendors can and should meet similar standards. What matters for your review is that they are documented, contractually committed, and technically verifiable.

3. If the product disappears: model the failure

The most under-examined risk with free software is not a breach, it is abandonment. The service goes offline, the team is reassigned, or the company is acquired and shut down.

Security offices should treat disappearance as a scenario to model, not a hypothetical. Questions to include in your due diligence:

• What is the vendor’s minimum notice period if they wind down the service. A specific number of days beats vague promises.
• How will they communicate shutdown to your institution. You want designated contacts and more than a banner on the login screen.
• Is the product dependent on third-party services with their own shutdown risk. For example, a free tool that is just a thin wrapper over another free API.
• Does the contract specify how long your data will remain available after termination, and in what form. This ties directly into exit.

There is always a real risk that a free product will be discontinued if it stops fitting the sponsor’s business or funding priorities. No policy language can eliminate that. Your mitigation is clear commitments around notice, data access, and export format, and an internal understanding of what a rapid transition would look like for your campus.

4. What exit looks like, in practice

Exit is only as good as the exports you receive and your ability to use them. For any free platform, you should ask for details at the level your IT staff would need to build a replacement.

Questions to require concrete answers to:

• What export formats are supported. CSV, JSON, and PDF are common. Proprietary binary formats are a red flag.
• Is there complete schema documentation. Column definitions, enumerations, and relationships between tables.
• Can you perform exports on demand, without vendor assistance. Depending on a support queue during a shutdown is risky.
• How often can you export. Regular scheduled exports reduce dependency on the live system.
• Does the vendor commit to a defined export period after termination. This ties to the disappearance model above.

Our ninety-day export commitment

For the Career Readiness Report, we commit to the following exit terms for institutions:

• Ninety days of export access after termination or announced shutdown: Institutions retain access to the administrative interface for at least 90 days after the effective termination date or formal shutdown notice.
• Self-service, full data export: During that window, authorized administrators can export all student, employer, faculty, and assessment data in non-proprietary formats such as CSV and JSON, with schema documentation.
• No export fees: There is no charge for exporting your data during the ninety-day period.
• Post-export deletion: After the export window closes and any legal hold periods are satisfied, institutional data is deleted from production systems according to documented retention policies.

The weakness in this approach is obvious: if an institution ignores exports until the end of the ninety-day window, a rushed transition is still possible. The practical mitigation is operational rather than contractual: schedule periodic exports during normal operations, test restoring them into your own data warehouse or reporting tools, and document the process alongside other critical vendor contingency plans.

How security offices can standardize this review

You do not need a separate standard for “free” tools. You need your existing vendor security review, slightly sharpened for sustainability and exit:

• Add a short section on funding model to your intake form, including expected time horizon and primary revenue source.
• Require a data inventory and a simple architecture diagram that shows where data is stored and who can access it.
• Include explicit questions about shutdown notice, export format, and export window, and push for concrete numbers.
• Encourage functional owners of free tools to maintain a brief exit playbook: where exports are stored, who can run them, and what “day 30” after a shutdown would look like.

Handled this way, “free” does not mean “less secure,” it just shifts the questions you ask: from price and discount schedules to sustainability, data use, and your ability to walk away without stranding student records or compromising trust.