EdTech Security Questions for District Procurement 2026

Choosing new technology for a school district is a huge responsibility. It’s not just about finding the most exciting new app; it’s about safeguarding student data and ensuring every tool is secure, private, and legally compliant. This process involves asking the right edtech security questions for district procurement to properly vet potential vendors. Critically, districts must ask vendors to verify their legal compliance with laws like FERPA, detail their technical security measures like encryption, and commit to a binding Data Privacy Agreement (DPA). With so many acronyms and technical terms, it can feel like navigating a maze.

This guide breaks down the essential concepts and questions you need to ask. We’ll walk through the entire process, from initial planning to ongoing monitoring, so you can confidently choose partners who prioritize student safety. A vendor like TeachTools, for example, builds its AI platform with a strong emphasis on privacy and security, making the vetting process smoother for schools.

Understanding the Vendor Vetting Process

Before diving into specific compliance rules, it’s crucial to understand the framework for evaluating vendors. This journey, from identifying a need to managing a long term partnership, is where you’ll apply the critical edtech security questions for district procurement.

What is Vendor Risk Assessment?

Vendor risk assessment is the process of figuring out how a third party provider could potentially harm your district’s data, finances, or reputation. For schools, this means digging into an edtech vendor’s security practices and privacy policies before they ever touch sensitive student information. Given that over 80% of businesses grant third party vendors access to their cloud environments, this step is non negotiable. A thorough assessment helps you identify weaknesses and ensure you only partner with trustworthy and secure companies.

What is the Procurement Lifecycle?

The procurement lifecycle covers all the stages a district goes through to plan, purchase, and manage a product. It’s more than just a one time purchase. The lifecycle includes pre procurement planning, the actual procurement and contracting, and post procurement monitoring. Managing the entire lifecycle ensures the technology you choose remains valuable and safe long after the initial contract is signed.

Pre Procurement Planning

This is the homework phase. Before you even talk to vendors, your team needs to define exactly what you need and how you’ll evaluate it. This involves setting educational goals, technical requirements, and a budget. You’ll also outline your non‑negotiable privacy and security criteria, like FERPA compliance or specific data encryption standards. A good plan produces a clear requirements document that acts as a checklist, helping you avoid costly changes and compliance headaches down the road.

Procurement and Contracting

Now it’s time to engage with vendors. In this phase, your district will evaluate different solutions, watch demos, check references, and review the vendor’s background and leadership. A critical piece of this stage is negotiating the contract. This legal document must include specific clauses and a Data Privacy Agreement (DPA) that clearly outlines the vendor’s responsibilities for protecting student data. Many districts now require a signed DPA before even starting a pilot program, making this a key hurdle for any potential partner.

Post Procurement Monitoring

Once a contract is signed, the work isn’t over. Post procurement monitoring, or vendor management, involves ongoing oversight to ensure the vendor continues to meet its promises. This could include annual security reviews, checking for compliance updates, and monitoring performance. A significant number of vendor related security incidents happen after the initial onboarding, making continuous monitoring essential for protecting your district’s investment and data.

Key Frameworks and Agreements

To streamline the vetting process, several standardized tools and agreements have been developed specifically for education. These are central to asking the right edtech security questions for district procurement.

What is the K–12 CVAT (Vendor Assessment Tool)?

The K–12 Community Vendor Assessment Tool, or K–12 CVAT, is a standardized questionnaire designed to measure vendor risk in education. Developed by the Consortium for School Networking (CoSN), it gives districts a ready made set of questions covering information security, data protection, and legal compliance. Instead of creating your own assessment from scratch, you can ask vendors to complete the K–12 CVAT. Its summary report makes it easy to spot a vendor’s security strengths and weaknesses, helping you make an informed decision.

What is the National Data Privacy Agreement (NDPA)?

The National Data Privacy Agreement (NDPA) is a standardized contract template created to simplify data privacy agreements between schools and edtech vendors. Led by the Student Data Privacy Consortium (SDPC), the NDPA provides a common legal framework that addresses major student privacy laws, saving everyone time and legal fees. It covers data usage rules, security requirements, and breach notification duties. Because so many states have adopted it, vendors who proactively sign the NDPA demonstrate a serious commitment to privacy and can speed up the procurement process significantly.

Navigating the Web of Compliance Laws

Federal and state laws form the bedrock of student data privacy. A vendor’s ability to comply with these regulations is a foundational component of any security review.

FERPA Compliance

The Family Educational Rights and Privacy Act (FERPA) is a federal law protecting the privacy of student education records. For vendors, being FERPA compliant means they treat student data with the same level of care as the school itself. They cannot misuse or re disclose student records and must have reasonable security measures in place. While the U.S. Department of Education enforces FERPA with schools, districts will not risk their federal funding by working with a non compliant vendor. Today, proving FERPA compliance is considered table stakes for any edtech company.

COPPA Compliance

The Children’s Online Privacy Protection Act (COPPA) places strict rules on online services directed at children under 13. To be COPPA compliant, a vendor cannot collect personal information from young children without verifiable parental (or school) consent. The law also mandates a clear privacy policy and robust data security. Violating COPPA can result in massive fines from the Federal Trade Commission (FTC). For example, Google and YouTube were fined a record $170 million for illegally collecting children’s data without consent. Districts will quickly disqualify any tool for elementary students that cannot demonstrate clear COPPA compliance.

CIPA Compliance

The Children’s Internet Protection Act (CIPA) helps protect students from harmful online content. It applies to schools and libraries that receive E-rate funding for internet access. To comply, schools must have an internet safety policy that includes technology for filtering or blocking obscene and harmful content. While the school is primarily responsible, edtech vendors, especially those providing broad internet access or curated content, are often asked how their platforms support a district’s CIPA obligations.

State Student Privacy Law Compliance

Beyond federal laws, nearly all 50 states have passed their own student data privacy laws, which often impose even stricter requirements than FERPA or COPPA. For example, California’s SOPIPA bans using student data for targeted advertising, while New York’s Education Law 2 D requires data encryption and a Parent’s Bill of Rights. Vendors must navigate this complex patchwork of state specific rules. Districts will always prioritize vendors who can demonstrate they understand and comply with their state’s unique laws.

GDPR Applicability

The General Data Protection Regulation (GDPR) is Europe’s sweeping data privacy law. While it’s an EU law, it can apply to U.S. based companies if they offer services to people in the EU. For edtech, this could impact vendors with a global user base or those serving international schools. GDPR sets a very high standard for data protection, especially for children’s data, and comes with severe fines for violations. Some U.S. districts ask about GDPR compliance as a benchmark for strong privacy practices, even if it doesn’t legally apply to them directly.

PCI DSS Applicability

The Payment Card Industry Data Security Standard (PCI DSS) applies to any organization that processes credit or debit card transactions. If an edtech tool involves payments, such as for subscriptions or school fees, the vendor must handle that card data in a PCI compliant manner. This industry standard, not a law, includes strict security controls to prevent credit card fraud. Vendors can meet this by using a third party payment processor like Stripe, which handles the compliance burden for them.

Understanding Security Frameworks and Audits

Certifications and adherence to established frameworks provide third party validation of a vendor’s security posture. These are excellent topics to include in your edtech security questions for district procurement.

Security Audit (SOC 2)

A SOC 2 report is an independent audit of a company’s security, availability, confidentiality, and privacy controls. Governed by the American Institute of CPAs (AICPA), a SOC 2 report has become a gold standard for cloud companies to prove they safeguard customer data. A SOC 2 Type II report, which covers a period of time, is particularly valuable as it shows a vendor has not only designed good controls but also operates them effectively.

ISO 27001 Certification

ISO 27001 is an international standard for managing information security. A vendor with an ISO 27001 certification has undergone a formal audit to verify they have a comprehensive Information Security Management System (ISMS). This globally respected certification provides strong assurance that the vendor follows a systematic and rigorous approach to protecting data.

NIST Cybersecurity Framework Adherence

The NIST Cybersecurity Framework (CSF) provides a set of best practices to manage cybersecurity risk. It’s organized around six core functions: Identify, Protect, Detect, Respond, Recover, and Govern. While not a certification, a vendor’s adherence to the NIST CSF signals a mature, holistic approach to security that many school IT leaders recognize and trust.

NIST SP 800-53 or 800-171 Alignment

Alignment with NIST Special Publication 800 53 or 800 171 indicates a vendor’s security controls meet rigorous federal standards. NIST SP 800 53 is a comprehensive catalog of controls for federal agencies, while 800 171 is a subset for non federal organizations handling sensitive information. A vendor aligning with these standards demonstrates a commitment to government grade security.

CIS Control Alignment

The CIS Critical Security Controls are a prioritized set of actions to protect against the most common cyberattacks. Maintained by the Center for Internet Security (CIS), these controls are a practical roadmap for security hygiene. Because they are prioritized, they help organizations focus on the highest impact defenses first, which is a reassuring sign for any risk averse school district.

Key Contractual and Technical Safeguards

The fine print matters. A vendor’s commitments must be backed by strong contractual clauses and modern technical security measures. These are some of the most important edtech security questions for district procurement you can ask.

Secure by Design Commitment

A vendor that is “secure by design” has built its product with security in mind from the very beginning, rather than adding it as an afterthought. This philosophy means security and privacy are part of every stage, from coding and testing to deployment. For example, a platform like TeachTools was designed to be FERPA supportive, using strong encryption and ensuring user data is never used for training AI models.

Privacy and Security Contract Clause

These are the legally binding provisions in a contract that detail a vendor’s obligations for protecting data. Clauses should cover compliance with all relevant laws, require industry standard security controls, and define what happens in the event of a breach. Strong, clear clauses transform a vendor’s marketing promises into enforceable commitments.

Data Usage Limitations

This defines exactly how a vendor is allowed to use school data. The universal expectation is that student data will be used only for educational purposes authorized by the school. This means no selling data, no using it for targeted advertising, and no repurposing it for other commercial ventures.

MFA Requirement

Multi factor authentication (MFA) is a critical security measure that requires users to provide more than one form of verification to log in. An MFA requirement significantly reduces the risk of unauthorized access from stolen passwords. MFA can block over 99.9 percent of account compromise attacks, making it a modern security standard that districts should expect.

Encryption at Rest and in Transit

This is a non negotiable security baseline. Encryption at rest protects data when it is stored on servers or in backups. Encryption in transit protects data as it moves over the internet. New York’s Ed Law 2 D, for example, legally requires that student data be encrypted both at rest and in transit. A vendor should be able to confirm they use strong encryption standards, like AES 256.

Backup Responsibility

This clarifies who is responsible for backing up data to prevent loss. For cloud based tools, the vendor is typically responsible. The district should verify the vendor’s backup frequency, retention period, and disaster recovery plan to ensure that important instructional content and student work won’t be lost in a technical failure.

Subprocessor Disclosure and Oversight

A vendor must disclose any third party companies (subprocessors), like cloud hosting providers, that they use to process data. The vendor is also responsible for ensuring these subprocessors meet the same high security and privacy standards. This transparency allows schools to understand the entire chain of data handling.

Data Deletion Upon Contract End

When a contract ends, the vendor must be able to securely delete all school data. This is a critical part of the data lifecycle, ensuring student information doesn’t remain on a vendor’s servers indefinitely. Many state laws give districts the right to request data deletion, and vendors must be prepared to comply.

Breach Notification Timeframe

This is the contractually defined window a vendor has to notify the district after discovering a data breach. Prompt notification is critical so the school can respond quickly to mitigate damage. State laws vary, but many require notification within a specific timeframe, with some regulations requiring notification in no more than seven calendar days after the discovery of such breach.

Incident Response Plan

An Incident Response Plan (IRP) is a vendor’s documented playbook for how to handle a cybersecurity incident. It shows they are prepared to identify, contain, and recover from a breach. Asking if a vendor has a tested IRP is a key due diligence question.

Vendor Liability and Jurisdiction

This contractual language defines who is responsible if something goes wrong and which state’s laws will govern the agreement. Districts typically require vendors to accept liability for breaches caused by their negligence and insist that any legal disputes be handled in the district’s home state.

Right to Audit

A right to audit clause gives the district the right to inspect a vendor’s practices to verify compliance with security and privacy commitments. While schools rarely perform full audits themselves, this clause is often satisfied by the vendor providing a recent third party report, like a SOC 2.

Cyber Insurance Coverage

This is an insurance policy a vendor holds to cover losses from a cyber incident. It provides a financial backstop to pay for things like notification costs, credit monitoring, and legal fees. Requiring vendors to carry cyber insurance helps protect the district from financial fallout if a breach occurs.

Data Governance Policy Review

This is when a district reviews a vendor’s internal policies for managing data. It provides a look “under the hood” to ensure the vendor has formalized procedures for data classification, access control, and retention, proving they have a mature and organized approach to data protection.

Data Storage Location

This requirement specifies where a vendor can physically store school data. Many districts require that all data be stored within the United States to ensure it remains under the jurisdiction of U.S. privacy laws like FERPA.

Data Export and Portability

This ensures a district can retrieve its data in a usable format if it decides to switch vendors. It prevents “vendor lock‑in” and guarantees that schools always maintain control and ownership of their valuable information. For example, migrating full lesson plans is straightforward when exports are standardized. Tools like TeachTools facilitate this by allowing easy exports to Google Docs and PDF.

Vulnerability Disclosure Program

A Vulnerability Disclosure Program (VDP) is a process that allows security researchers to safely report security flaws they find in a vendor’s product. Having a VDP is a sign of security maturity and transparency, showing the vendor is proactive about finding and fixing weaknesses.

Annual Penetration Test

An annual penetration test is an authorized, simulated cyberattack on a vendor’s systems performed by security experts to find vulnerabilities. It’s like a yearly check up for the system’s security health and demonstrates a vendor’s commitment to actively testing and improving their defenses.

Role Based Access Control (RBAC)

RBAC is a system that restricts access to data and features based on a user’s role (e.g., teacher, student, admin). It enforces the principle of least privilege, ensuring users can only see and do what is appropriate for their position, which is a critical feature for protecting data in a multi user environment.

Ongoing Monitoring and Annual Review

This is the practice of continuously checking a vendor’s compliance and performance throughout the life of a contract. Risk is not static, so an annual review ensures the vendor continues to meet security requirements and adapt to new threats or laws.

Having a DPA (Data Privacy Agreement) in Place

Having a DPA in place means a formal, signed legal agreement exists that governs how the vendor will protect student data. In many states, this is a legal requirement. It moves a vendor from being “under consideration” to being “approved for use,” as it solidifies all their privacy promises into a binding contract.

No Student Data Sale or Advertising

This is a core ethical and legal line that reputable edtech vendors do not cross. It means the vendor pledges to never sell students’ personal information or use that data to target them with ads. This promise ensures the classroom remains a protected, non commercial space focused on learning.

Choosing the right technology partner requires a deep dive into their security and privacy practices. By using this guide and asking these detailed edtech security questions for district procurement, you can build a portfolio of digital tools that are not only effective but also safe, secure, and worthy of your students’ trust.

For educators looking for a powerful AI assistant that was built with these principles in mind, check out TeachTools. With a firm commitment to privacy, strong encryption, and a clear DPA for districts, it’s designed to save teachers time without compromising on data protection. To see secure, classroom‑ready assessments in action, try the Quiz Generator. You can also explore free, printable resources to evaluate output quality before engaging procurement.

---

Frequently Asked Questions

1. What are the most important edtech security questions for district procurement?
The most critical questions revolve around legal compliance (FERPA, COPPA, state laws), data handling (encryption, data deletion), and third party verification. Always ask for proof of compliance, inquire about their security audit results (like a SOC 2 report), and demand a comprehensive Data Privacy Agreement (DPA).

2. Why is a Data Privacy Agreement (DPA) so critical?
A DPA is a legally binding contract that holds a vendor accountable for protecting student data. It translates their privacy policy and marketing claims into enforceable obligations. Without a signed DPA in place, a district has little legal recourse if the vendor mishandles data. Many states now legally require a DPA for any tool that accesses student information.

3. How can our district simplify the vendor risk assessment process?
You can simplify the process by using standardized tools. Instead of creating a unique security questionnaire for every vendor, ask them to complete the K–12 CVAT. For contracts, start with the National Data Privacy Agreement (NDPA) template and add any state specific amendments. This saves time and ensures you cover all the critical areas.

4. What is the main difference between FERPA and COPPA?
FERPA protects the privacy of a student’s official education records and is aimed at schools and the vendors they work with. COPPA focuses on the online collection of personal information from children under 13 and is aimed directly at the operators of websites and online services. Both are crucial for K–12 edtech compliance.

5. Is it safe to use an edtech tool that isn’t SOC 2 certified?
While a SOC 2 report is a strong indicator of security maturity, its absence isn’t an automatic disqualifier, especially for newer or smaller companies. If a vendor doesn’t have a SOC 2, you should conduct a more detailed review of their security practices. Ask for results from a recent penetration test, review their internal data governance policies, and ensure they can contractually commit to strong security controls in your DPA.

6. What does “no training on your data” mean for an AI tool?
This means the AI vendor commits to not using your specific inputs (like lesson plans or student work) to train or improve their underlying AI models. This is a crucial privacy protection that prevents your proprietary or sensitive classroom information from being absorbed into a global model. A secure platform like TeachTools makes this promise to ensure teacher and student data remains private.

7. How do we ensure a vendor will delete our data when we stop using them?
This must be explicitly stated in your contract or DPA. The agreement should include a “Data Deletion Upon Contract End” clause that requires the vendor to securely destroy all your district’s data within a specified timeframe (e.g., 30 or 60 days) after the contract terminates. You can also request a written certification from the vendor confirming the deletion has been completed.

8. What should we do if a potential vendor resists signing our district’s DPA?
If a vendor is unwilling to sign your standard DPA or negotiate reasonable security and privacy terms, it is a significant red flag. It may indicate they cannot meet your requirements or are not prioritizing student data protection. In most cases, it is best to disqualify that vendor and seek a partner who is transparent and willing to make the necessary contractual commitments to safety.