From the lens of a CTO/CIO using the Shared Responsibility Model
by John Krull
When evaluating family engagement and communications solutions or any edtech product, the K-12 CIO or CTO must lead the Information Technology (IT) team in a technology review. While the ultimate decision on product selection will come from the department owner, usually the district’s Communication, Teaching and Learning, or Family Engagement teams, IT is responsible for reviewing from their lens.
As a former K-12 CIO for Seattle Public Schools and CTO for Oakland Unified and Fremont Unified School Districts, I’ve had the opportunity to review many edtech products. I understand the importance of vetting products K-12 districts and schools bring on board. FERPA (The Family Educational Rights and Privacy Act) permits districts and schools that outsource institutional services or functions to disclose Personally Identifiable Information (PII) to these 3rd parties. This is where schools and districts, at a minimum, need to expect the same protections from their vendors that schools and districts themselves expect internally.
Core protections for districts and schools
IT in K-12 should look at third parties as closely as they protect data directly under their control. With all the recent data breaches and other cybersecurity issues in K-12, the work of K12 SIX, the K-12 Security Information eXchange, has helped define standards of protection in a straightforward and concise manner.
The chart below outlines core protections for schools and districts
Schools and districts can use the K12 SIX matrix or frameworks provided by NIST or their cybersecurity insurance provider to monitor compliance with the best security and data protection practices. But, when evaluating an edtech vendor, what should districts look for? What tools are available?
The Cloud Security Alliance has developed a comprehensive tool that measures tech vendors (Software as a Services (SaaS) suppliers) against the Cloud Security Matrix (CSM). The matrix is derived from best practices from broadly accepted frameworks and standards, including NIST, System and Organization Controls (SOC) as defined by the American Institute of Certified Public Accountants (AICPA), CIS Controls, and others. The CIAQ (the Consensus Assessment Initiative Questionnaire) is a set of 169 questions reflecting the CSM that SaaS vendors answer to document what security controls exist in their services.
While the CAIQ and frameworks like SOC are great tools to measure edtech vendors’ security posture, is there a straightforward matrix like the one from K12 SIX to measure districts and schools? CIOs, CTOs, and their K-12 teams need a quick checklist for getting information from and evaluating edtech vendors.
The Shared Responsibility Model and why it matters
While I’ve seen some more manageable lists to evaluate edtech vendors, I have not seen one that clearly delineates responsibilities when it comes to cloud security. Since I have been focusing on the cloud for the last few years, I have come to appreciate the unique nature of the cloud and how it makes the evaluation more nuanced than measuring an on-premises (on-prem) IT infrastructure. It’s important to understand that some security responsibilities belong to a cloud infrastructure vendor like AWS, while others fall on the SaaS provider themselves. Both edtech vendors and their customers need to understand the Shared Responsibility Model.
All major cloud providers accept The Shared Responsibility Model (Shared responsibilities and shared fate on Google Cloud, Azure Shared responsibility in the cloud, and the AWS Shared Responsibility Model). The model delineates who is responsible for what. For example, data center security is the responsibility of the cloud provider. In contrast, the security of the application and its data are the responsibility of the SaaS vendor, who is the cloud provider’s customer. AWS explains this by saying AWS is responsible for the “security of the cloud,” and the customer (the edtech vendor in our case) is responsible for “security in the cloud.”
AWS provides a great illustration of the Shared Responsibility Model:
Beware of the vendor that simply states that the experts at the cloud provider protect their data. With AWS, they are indeed security experts and provide excellent protection in their data centers worldwide and protect the underlying infrastructure for their managed compute, storage, database, and network. They can provide attestations from 3rd part auditors. But the edtech vendor is responsible for customer data, the application, encryption, network and firewall protections, and – depending on their setup – the operating system.
I’ve developed a checklist working with TalkingPoints to help school district technology teams identify what edtech vendors should provide in the context of the Shared Responsibility Model. While other matrices and frameworks have their place (CAIQ, NIST, CIS, etc.), the idea is to have a checklist more aligned with what K12 SIX designed to measure K-12 cybersecurity quickly yet effectively. This checklist is available for download. I’ll explain it briefly below.
Corporate Governance and Security (edtech vendor)
Initially, we define the core elements of Corporate Governance and Security. This area covers how the edtech vendor runs its business and its application. Look for these key items when you are evaluating an edtech vendor.
Checklist items in this first section include:
- SOC 2 Certification
- Business continuity plan (backup, disaster recovery)
- All operations follow applicable FERPA, HIPAA, NIST, SOC 2 compliance, Privacy Pledge, Children’s Online Privacy Protection Act and state privacy laws, Breach Laws, and Data Residency Laws.
- Zero Trust Security Model for Firewall Protection
- SSO/MFA implemented
- Managed Detection and Response cybersecurity protection
- Email security
- System patching and ransomware protection
- Privileged Access management
- Password policy
- Security Awareness Training
- Cybersecurity insurance
Security and Compliance of the cloud (cloud vendor)
Beyond these core protections, look for vendors that understand the Shared Responsibility Model. First, look at the Security and Compliance protections provided by the cloud provider. Remember, this is “security of the cloud.” Your edtech vendor should outline the protections provided by their cloud provider.
Here’s what to look for:
- Data Center Security
- Compliance attestations:
- Distributed Denial of Service (DDOS) protection
- Managed Intelligent Threat Detection
- Automated and continual vulnerability management
Security and Compliance in the cloud (edtech vendor)
Look for how specifically the vendor protects its application. What is the “security in the cloud?”
- Secure testing, development, and deployment processes
- Change management processes
- Web Application Firewall protection and layered security
- Configuration management
- Secure and centralized access auditing and logging
- PII monitoring and protection
- Encryption in transit and at rest
- Automated processes for deployment, scaling
- Reliability, redundancy, and disaster recovery enablement for network, compute, storage, and data
Finally, check the data handling.
- Data Portability
- Data Deletion and Retention
- Data storage
- Server uptime
- Data security & privacy certifications
- No reselling or commercial use
- Audit rights
- Breach notification
- Accessibility
School district tech teams can use this overview of the Shared Responsibility Model and checklist outlining what to look for when evaluating each facet of an edtech solution’s offering to assess the security and compliance capabilities of potential partners more effectively. Download the checklist and use it to review information provided by your potential vendor.
John Krull is the Founder and President of Tech Reformers. Before founding Tech Reformers, he served as CIO for Seattle Public Schools in Washington State and CTO for Oakland Unified and Fremont Unified in California. Before leading school system technology, John worked at Microsoft and various startups implementing web and video technologies. John began his career as a teacher.
