ChatGPT
Google AI
Claude
Perplexity
Grok
When your school selects an AI-powered EdTech tool, you're not just choosing a product—you're choosing a data partner. That vendor will access some of your most sensitive information: student data.
Not all vendors treat student data with the care it deserves. This guide provides a practical framework for evaluating AI vendors through a data protection lens.
For foundational context, see our guide on student data protection in the age of AI.
Executive Summary
- Schools are responsible for vendor compliance with data protection requirements—due diligence is essential
- Key evaluation areas: data collection, processing, storage, security, and retention practices
- Contract terms matter as much as vendor claims—get commitments in writing
- Red flags include vague privacy policies, refusal to sign data processing agreements, and resistance to security audits
- Smaller vendors may lack mature data protection programs; evaluate capability, not just intent
- Regional considerations: verify compliance with PDPA requirements in Singapore, Malaysia, and Thailand
- Document your due diligence process to demonstrate accountability
Why This Matters Now
AI features are proliferating. EdTech vendors are adding AI capabilities rapidly—sometimes without clear communication about new data processing.
Data requirements are expanding. AI tools often need more data than traditional software.
Regulatory scrutiny is increasing. Privacy regulators are paying attention to children's data in educational technology.
Vendor maturity varies widely. Some vendors have robust data protection programs; others are startups learning as they go.
Schools bear accountability. Under PDPA frameworks (Singapore PDPA, Malaysia PDPA 2010, Thailand PDPA), schools remain responsible for data protection even when vendors process the data.
Vendor Evaluation Framework
Category 1: Data Collection and Access
Questions to ask:
- What specific student data will the tool collect or access?
- Why is each data element necessary?
- Can we limit the data shared without losing core functionality?
- Does the tool collect behavioral or biometric data?
Red flags:
- Vague statements about data collection
- Excessive data requirements for simple functionality
- Collecting biometric data without clear necessity
Category 2: Data Processing and AI Use
Questions to ask:
- How does the AI process student data?
- Is student data used to train machine learning models?
- Does the AI create profiles of students?
- Can we opt out of certain AI features?
Red flags:
- Refusal to explain how AI works
- Using student data to train models sold to other schools
- No human oversight in consequential decisions
Category 3: Data Storage and Security
Questions to ask:
- Where is student data stored?
- What security certifications does the vendor hold?
- Has the vendor had security incidents?
- What is the vendor's incident response process?
Red flags:
- No security certifications
- Storing data in jurisdictions with weak privacy laws
- No documented incident response plan
Category 4: Data Sharing and Sub-processors
Questions to ask:
- Does the vendor share student data with third parties?
- Who are the sub-processors?
- Can we approve or veto sub-processor changes?
Red flags:
- Refusal to disclose sub-processors
- Sub-processors in high-risk jurisdictions
- No contractual data protection requirements for sub-processors
Category 5: Data Retention and Deletion
Questions to ask:
- How long is student data retained?
- What happens to data if we terminate the contract?
- Can we request data deletion?
Red flags:
- No defined retention periods
- Retaining data indefinitely
- Data retained after contract termination
Category 6: Contract and Compliance
Questions to ask:
- Will the vendor sign a Data Processing Agreement (DPA)?
- Does the contract allow you to audit the vendor's data practices?
- Is the vendor compliant with PDPA?
Red flags:
- Refusal to sign a DPA
- Complete exclusion of liability for data issues
- Take-it-or-leave-it contract with no negotiation
Vendor Due Diligence Checklist
Before First Contact
- Defined your data protection requirements
- Identified what data you're willing to share
- Understood your regulatory obligations
- Prepared key questions for vendor
Initial Evaluation
- Reviewed vendor privacy policy
- Reviewed vendor security documentation
- Identified data collection scope
- Confirmed AI features and data usage
- Verified security certifications
Deep Dive
- Received complete sub-processor list
- Reviewed sample DPA terms
- Confirmed data storage locations
- Assessed retention and deletion practices
- Checked references from other schools
Contract Negotiation
- Negotiated DPA with appropriate terms
- Secured audit rights
- Confirmed liability allocation
- Specified data deletion requirements
- Established sub-processor approval process
Ongoing Governance
- Scheduled periodic vendor reviews
- Created process for new feature assessment
- Established incident notification procedure
- Documented due diligence for records
Sample DPA Requirements
Your Data Processing Agreement should include (the SDPC National Data Privacy Agreement provides a model template used by 275,000+ school-vendor agreements):
Scope and Purpose
- Specific data elements being processed
- Permitted purposes (and prohibited uses)
- Duration of processing
Security Requirements
- Minimum security standards
- Required certifications
- Incident notification timeline
Sub-processor Controls
- List of approved sub-processors
- Notification requirement for changes
- Right to object to new sub-processors
Audit Rights
- Right to audit or receive audit reports
Data Subject Rights
- Vendor's obligations to assist with access requests
Termination
- Data return or deletion on termination
- Certification of deletion
Common Failure Modes
Failure 1: Accepting boilerplate terms Prevention: Negotiate. Even small vendors will often modify terms for school customers.
Failure 2: Trusting marketing claims Prevention: Get specifics in writing. Ask for certification evidence.
Failure 3: Ignoring sub-processors Prevention: Require sub-processor disclosure. Assess key sub-processors.
Failure 4: No ongoing monitoring Prevention: Annual vendor reviews. Monitor for feature changes.
Failure 5: Inadequate documentation Prevention: Document everything. You may need to demonstrate accountability later.
Metrics to Track
- Vendors with completed due diligence assessments
- Vendors with signed DPAs
- Vendor security certification status
- Average time to complete vendor assessment
- Vendors requiring remediation
Next Steps
Vendor evaluation isn't a one-time event—it's an ongoing relationship. Start with your highest-risk vendors and work through the framework systematically.
Need help establishing vendor evaluation processes?
→ Book an AI Readiness Audit with Pertama Partners. We'll assess your vendor landscape, identify gaps in current agreements, and help you build robust due diligence procedures.
Disclaimer
This article provides general guidance on vendor evaluation for student data protection. It does not constitute legal advice. Consult qualified legal counsel for specific contractual and regulatory guidance.
Related Articles
- Student Data Protection in the Age of AI
- Parental Consent for AI in Schools
- Data Minimization in School AI
Common Questions
Schools should include several critical contractual provisions when engaging AI vendors that process student data. First, a data processing addendum that explicitly prohibits the vendor from using student data for any purpose beyond providing the contracted service, including model training, product improvement, or sale to third parties. Second, data deletion obligations specifying that all student data must be permanently deleted within 30 days of contract termination, with written certification of deletion provided. Third, breach notification requirements mandating that the vendor notify the school within 24 to 48 hours of discovering any unauthorized access to student data, with specific information required in the notification including the scope of affected data and remediation steps taken. Fourth, audit rights allowing the school or its designated third party to inspect the vendor's data handling practices annually. Fifth, sub-processor restrictions requiring prior written approval before the vendor engages any additional processors who will access student data.
Schools should verify vendor data protection claims through multiple validation methods rather than accepting marketing statements at face value. Request and review the vendor's most recent SOC 2 Type II audit report, which provides independent verification of security controls over a sustained period rather than a single point in time. Ask for references from other educational institutions of similar size and type, and contact those references to inquire specifically about data protection practices, incident history, and the vendor's responsiveness to security concerns. Review the vendor's public privacy policy and terms of service for consistency with their sales representations, as discrepancies between marketing claims and legal documents often indicate weaker actual protections than advertised. Finally, conduct a technical assessment of the vendor's platform during a trial period to verify that access controls, encryption, and data handling match documented capabilities.
References
- National Data Privacy Agreement (NDPA). Student Data Privacy Consortium (SDPC) (2024). View source
- Student Privacy Pledge. Future of Privacy Forum (2014). View source
- Personal Data Protection Act (PDPA) — Overview. PDPC Singapore (2012). View source
- Advisory Guidelines on Use of Personal Data in AI Recommendation and Decision Systems. PDPC Singapore (2024). View source
- Guidance for Generative AI in Education and Research. UNESCO (2023). View source
- The First National Model Student Data Privacy Agreement Launches. Future of Privacy Forum (2018). View source
- Student Data Privacy Consortium — Resources. SDPC / A4L Community (2025). View source
