Third-Party Vendor Risk Assessment Template

Third-party vendors represent one of the most significant and least managed cybersecurity risks in K-12 education. The average school district shares student and staff data with hundreds of technology vendors, many of which have never undergone a formal security assessment by the district. When any one of these vendors suffers a breach, the district bears the liability for the exposure of student records under FERPA, state student privacy laws, and community trust.

Supply chain attack statistics are sobering. Industry analysis indicates that over 60% of data breaches now involve a third-party vendor or supplier, and the education sector is disproportionately affected due to the volume of EdTech integrations and the limited security due diligence resources available to school district IT departments. High-profile vendor breaches affecting education — including incidents involving student information system providers, assessment platforms, and communication tools — have collectively exposed tens of millions of student records.

FERPA's school official exception allows districts to share education records with vendors without parental consent only when the vendor is under direct control of the district with respect to the use and maintenance of education records, uses the data only for the purposes for which it was shared, and meets the criteria specified in the district's annual FERPA notification. This exception requires a written agreement establishing the vendor as a school official — yet many districts share student data with vendors through informal click-through agreements that may not satisfy FERPA requirements.

A structured vendor risk assessment program enables districts to make informed decisions about which vendors to engage, what data to share, and what contractual protections to require. It transforms vendor selection from a purely functional evaluation (does the tool do what we need?) into a holistic assessment that includes security, privacy, and compliance considerations.

The following questionnaire framework contains 40 questions organized across eight security domains. Each question should be scored on a 0-3 scale: 0 (no capability or refusal to answer), 1 (partial implementation), 2 (implemented with minor gaps), 3 (fully implemented with documentation). The questionnaire is designed to be completed by the vendor as a self-assessment, with the district reserving the right to request documentation or conduct verification for high-risk vendors.

Data Handling and Privacy (8 questions): Where is student/staff data processed and stored (geographic location and specific cloud providers)? Is data encrypted at rest and in transit, and with what standards? What is the data retention policy, and can the district request deletion? Is data used for any purpose beyond the contracted service, including analytics, product improvement, or model training? Does the vendor share data with any sub-processors, and if so, who are they? Can the district export its data in a standard format upon termination? What is the vendor's process for responding to parent data access or deletion requests? Does the vendor's privacy policy comply with applicable state student privacy laws?

Access Controls (5 questions): Does the platform support SSO integration via SAML or OIDC? Is multi-factor authentication available and enforced for administrative accounts? How are user roles and permissions structured — does the platform support least-privilege access? What is the process for deprovisioning user accounts, and can it be automated? How is vendor employee access to customer data controlled and audited?

Security Operations (7 questions): Does the vendor maintain a SOC 2 Type II report, ISO 27001 certification, or equivalent? When was the most recent third-party penetration test conducted, and were critical findings remediated? Does the vendor have a documented incident response plan? What is the vendor's vulnerability management and patching cadence? Does the vendor conduct employee security awareness training? Is there a bug bounty or responsible disclosure program? What logging and monitoring capabilities are in place for detecting unauthorized access?

• Incident Response (5 questions): breach notification timeline, communication process, forensic investigation capability, insurance coverage, past breach history
• Business Continuity (5 questions): disaster recovery plan, RTO/RPO commitments, data backup frequency and testing, geographic redundancy, service level agreements
• Compliance (5 questions): FERPA compliance documentation, COPPA compliance (if applicable), state student privacy law compliance, willingness to sign district DPA, regulatory audit history
• Employee Security (3 questions): background check policy, security training requirements, acceptable use policies for access to customer data
• Insurance (2 questions): cyber liability insurance coverage amount, errors and omissions coverage

The scoring methodology converts individual question responses into an overall vendor risk score that maps to a risk tier. Each of the 40 questions is scored 0-3, yielding a maximum possible score of 120. The raw score is normalized to a 0-100 scale for ease of communication with non-technical stakeholders.

Risk Tier Definitions: Score 85-100 is classified as Low Risk — the vendor demonstrates a mature security posture with comprehensive controls and documentation. These vendors are approved for processing sensitive student and staff data with standard contractual protections. Score 70-84 is classified as Medium Risk — the vendor has adequate security controls with some gaps that should be addressed through contractual requirements and compensating controls. These vendors may process student data subject to enhanced monitoring and specific DPA provisions addressing identified gaps. Score 50-69 is classified as High Risk — the vendor has significant security gaps that present material risk to district data. These vendors should not process sensitive student or staff PII until identified deficiencies are remediated. Limited use with non-sensitive data may be permitted with enhanced monitoring. Score below 50 is classified as Critical Risk — the vendor lacks fundamental security capabilities and should not be engaged for any purpose involving district data.

Minimum score thresholds vary by data sensitivity classification. Vendors processing student PII (names, IDs, grades, attendance) must score a minimum of 70 (Medium Risk or better). Vendors processing highly sensitive data (SSNs, medical records, behavioral health, IEP content) must score a minimum of 85 (Low Risk). Vendors processing only de-identified aggregate data or no student data may be engaged at any risk tier with appropriate monitoring.

The scoring rubric includes domain-specific minimum thresholds in addition to the overall score. A vendor must score at least 60% within the Data Handling and Privacy domain and at least 60% within the Incident Response domain regardless of overall score. These domains are weighted as critical because deficiencies in data handling and incident response directly impact the district's ability to meet its FERPA obligations and breach notification requirements.

Certain vendor responses or characteristics should be treated as automatic disqualifiers regardless of the overall assessment score. These red flags indicate fundamental security or privacy deficiencies that cannot be adequately mitigated through contractual provisions or compensating controls.

No encryption at rest: If the vendor does not encrypt stored data at rest using industry-standard algorithms (AES-256 or equivalent), student and staff data is vulnerable to exposure through any breach of the storage infrastructure, insider threat, or physical theft. This is a baseline security control with no acceptable substitute and represents an automatic disqualification for any vendor handling district data.

No documented incident response plan: A vendor that cannot produce a written incident response plan has no structured capability to detect, contain, or notify the district of a breach. Without an incident response plan, the vendor's breach notification timeline is unpredictable and the quality of forensic investigation cannot be assured. This gap directly impacts the district's ability to fulfill its own breach notification obligations.

Student data stored outside the United States without explicit district consent: International data storage introduces jurisdictional complexities that may conflict with FERPA requirements and state student privacy laws. Some foreign jurisdictions have government access provisions that could enable access to student data without the consent or knowledge of the district. Any offshore data storage must be explicitly disclosed, consented to, and addressed in the DPA.

Refusal to sign a Data Processing Agreement: A vendor's unwillingness to enter into a DPA that establishes the vendor as a school official under FERPA, limits data use to the contracted purpose, requires breach notification, and provides audit rights is a disqualifying indicator. Without a DPA, the district lacks the contractual framework required under FERPA to share education records and has no enforceable mechanism to ensure appropriate data handling.

• No encryption at rest for any data store containing student or staff records
• No documented or tested incident response plan
• Data stored outside the United States without explicit district consent and legal review
• Refusal to sign the district's Data Processing Agreement or equivalent
• Terms of service that claim ownership or unrestricted use rights over student data
• No evidence of any third-party security assessment (SOC 2, penetration test, or equivalent) in the past 24 months
• History of a data breach with evidence of inadequate response or delayed notification
• Inability to delete district data upon contract termination within 90 days

The Data Processing Agreement (DPA) is the legal instrument that establishes the terms under which a vendor processes district data. Every vendor that receives student or staff PII must execute a DPA before data sharing begins. The following key clauses should be included in every district DPA, adapted with the guidance of district legal counsel to comply with applicable state requirements.

Purpose Limitation: The vendor shall process district data solely for the purpose of providing the contracted services as described in the service agreement. Data shall not be used for any secondary purpose including but not limited to advertising, marketing, product development, analytics unrelated to the contracted service, or training of artificial intelligence or machine learning models. Any request to use data for purposes beyond the contracted service requires prior written consent from the district.

Data Minimization: The vendor shall collect and process only the minimum data elements necessary to provide the contracted service. The district and vendor shall jointly document the specific data elements to be shared, and the vendor shall not request or retain data elements beyond this documented scope. If the vendor's system collects data elements that are not necessary for the contracted service, those elements shall not be stored or shall be immediately deleted.

Breach Notification: The vendor shall notify the district within 72 hours of discovering any confirmed or suspected security incident involving district data. The notification shall include: a description of the incident, the categories and approximate number of records affected, the likely consequences of the breach, the measures taken or proposed to address the breach, and a designated point of contact for ongoing communication. The vendor shall cooperate fully with the district's investigation and provide forensic analysis results.

Audit Rights and Data Deletion: The district retains the right to audit the vendor's data handling practices upon reasonable notice. Upon termination of the service agreement, the vendor shall delete all district data within 30 days and provide written certification of deletion. The vendor shall not retain any copies of district data in any form, including backups, after the deletion certification is provided, unless retention is required by law (in which case the specific legal requirement must be documented).

Initial vendor assessment establishes a security baseline, but vendor risk is dynamic. Security postures change as vendors modify their infrastructure, acquire new sub-processors, update terms of service, and experience personnel changes. Effective vendor risk management requires continuous monitoring supplemented by periodic formal re-assessment.

Annual re-assessment should be conducted for all vendors classified as High or Medium Risk, and for any vendor processing highly sensitive data regardless of risk tier. The re-assessment uses the same questionnaire framework as the initial assessment, enabling year-over-year comparison. Key triggers for unscheduled re-assessment include: the vendor reports a security incident, the vendor is acquired or merges with another company, the vendor materially changes its terms of service or privacy policy, the vendor changes its hosting infrastructure or introduces new sub-processors, or the district plans to expand the scope of data shared with the vendor.

Continuous monitoring with iboss CASB provides real-time visibility into how district data is flowing to and from vendor platforms. CASB monitoring can detect unauthorized data sharing — for example, a vendor platform that begins transmitting data to new third-party domains that were not part of the original assessment. Automated alerts for vendor domain changes (such as a vendor migrating to a new domain or being redirected through a CDN change) trigger review by the IT security team to verify the change is legitimate.

iboss network telemetry also supports vendor monitoring by tracking data volume patterns. A sudden increase in data transfer to a vendor platform outside of normal usage patterns may indicate unauthorized bulk data access. Baseline data flow profiles should be established for each critical vendor during the initial onboarding period and monitored for deviations. Anomalous vendor traffic patterns should be investigated before assuming benign causes.

The iboss SASE platform provides technical enforcement capabilities that transform the vendor risk assessment program from a periodic review exercise into a continuously enforced control framework. Three iboss capabilities are central to this integration: CASB shadow IT discovery, DLP policy enforcement, and URL categorization.

iboss CASB shadow IT discovery identifies all cloud applications and SaaS services in use across the district by analyzing web traffic patterns. This discovery process reveals the complete picture of vendor usage — including applications adopted by individual teachers or departments without going through the district's technology review process. Shadow IT discovery reports should be generated monthly and cross-referenced against the district's approved vendor list. Any unapproved vendor usage involving student data is a policy violation that requires immediate review and either formal assessment and approval or access termination.

iboss DLP policies prevent data flow to vendors that have not been assessed or have failed the assessment. DLP rules can be configured to block the upload or transmission of student PII patterns (names, IDs, SSNs) to vendor domains that are not on the district's approved list. This provides a technical backstop that prevents well-intentioned staff from sharing student data with unapproved tools, even when the staff member does not realize the data privacy implications. For vendors that pass assessment but are classified as Medium Risk, DLP policies can be configured to allow data sharing while logging all transmissions for audit purposes.

URL categorization for vendor domains enables policy-based access control at the domain level. Approved vendors are categorized as permitted, vendors under assessment are categorized as monitored (access allowed with logging and user notification), and rejected or unassessed vendors are categorized as blocked. When a vendor's risk classification changes — for example, if a previously approved vendor suffers a breach — the URL categorization can be updated immediately to restrict or block access district-wide within minutes. This rapid response capability is essential for protecting district data when a vendor compromise is reported, as the window between vendor breach disclosure and attacker exploitation of the shared data can be extremely narrow.