01
Already inside the university
MyEducator materials are used in some of the largest universities in the world, in the same LMSes Voshi connects to.
Security and Compliance
Voshi is a product of MyEducator, whose interactive learning resources have run inside university LMSes since 2011.
We ensure that tools built with Voshi follow the same security and compliance practices as our existing learning resources.
Since 2011
MyEducator was started by university instructors who wanted better materials: interactive, online, and priced so students could afford them. MyEducator resources are now used in universities throughout the world.
Along the way, we learned how a university brings a tool into a course: who approves what, which systems run which tools, and what a review asks of a vendor. Our own learning resources have passed those reviews at universities around the world.
Voshi tools are held to the same standard. MyEducator is the vendor for every tool built with Voshi, so there is one company to review, not one for each tool.
What that means for you
01
MyEducator materials are used in some of the largest universities in the world, in the same LMSes Voshi connects to.
02
Tools built with Voshi follow the same security and compliance practices as our learning resources, and every tool is checked for accessibility and security before it is shared.
03
SOC 2 Type II, HECVAT, VPAT, FERPA, and the rest of the 99 requirements. Contact us for anything your review needs.
Already on campus
















































The complete inventory
Everything a university reviews before a tool enters a course: security, privacy, accessibility, the LMS, payments, contracts, and support.
This is the list a university's review covers, and MyEducator handles every item on it for every tool Voshi runs. Select an item for its details.
If your institution asks for something that is not here, contact us.
1–16
01 · Compliance and security
An independent auditor's report that security controls were in place and actually worked over a period of months, not just on one day. Schools ask for it before a tool touches student data.
02 · Compliance and security
Outside security testers attack the platform the way a real attacker would and report what they find. Schools ask for the summary letter.
03 · Compliance and security
Scanning code, servers, and dependencies for known weaknesses, and patching them on a schedule set by how severe they are.
04 · Compliance and security
Stored data (student records, grades, files) is encrypted on disk, so a lost drive or backup reveals nothing.
05 · Compliance and security
Every connection to and from the platform uses TLS, so nothing crosses the network in the clear.
06 · Compliance and security
Anyone with administrative access signs in with a second factor, not just a password.
07 · Compliance and security
A record of who accessed or changed what, and when, kept so an incident can be investigated after the fact.
08 · Compliance and security
Regular checks that each person's access still matches their job, with access removed when it no longer does.
09 · Compliance and security
Background checks, security training, and confidentiality agreements for the people who can reach production systems.
10 · Compliance and security
Backups and a tested plan to restore service and data if a system or a whole region fails.
11 · Compliance and security
A plan for keeping the service running and supported through outages, staff changes, or a supplier failing.
12 · Compliance and security
Student data is stored and processed in the United States, which many schools and state systems require.
13 · Compliance and security
A written commitment to availability that schools can hold the vendor to.
14 · Compliance and security
A public page showing current service health and past incidents, so a school's help desk can check it before opening a ticket.
15 · Compliance and security
A documented, practiced procedure for detecting, containing, and reporting a security incident, including who tells the schools.
16 · Compliance and security
Code and configuration changes are reviewed, tested, and recorded before they reach production.
17–41
17 · Procurement and vendor review
The Higher Education Community Vendor Assessment Toolkit: several hundred security and privacy questions that many universities require answered before they buy.
18 · Procurement and vendor review
The short form of the HECVAT, which some schools accept for lower-risk tools.
19 · Procurement and vendor review
Many schools have their own security and privacy questionnaires on top of the standard ones, and each is answered separately.
20 · Procurement and vendor review
Shared Assessments' Standardized Information Gathering questionnaire, a security review common in corporate and some university purchasing.
21 · Procurement and vendor review
The Cloud Security Alliance's Consensus Assessments Initiative Questionnaire, which maps a cloud service's controls to the CSA's Cloud Controls Matrix.
22 · Procurement and vendor review
A certificate of insurance showing coverage for data breaches and cyber incidents, at the limits a school's contract requires.
23 · Procurement and vendor review
Proof of professional liability coverage, for claims that the service failed to do what it promised.
24 · Procurement and vendor review
Proof of general business liability insurance, which most schools require before a vendor can be paid.
25 · Procurement and vendor review
The US tax form a school needs on file before it can pay a vendor.
26 · Procurement and vendor review
Setting up and maintaining a supplier profile in Jaggaer, the purchasing system many universities use.
27 · Procurement and vendor review
Registering as a supplier in PaymentWorks, which many schools use to verify vendors and their bank details.
28 · Procurement and vendor review
Registering in SAP Ariba, the supplier network some universities and state systems require.
29 · Procurement and vendor review
Statements of who owns and controls the vendor, which some states and schools require.
30 · Procurement and vendor review
Supplier diversity forms (small, minority-, women-, or veteran-owned status) that schools collect for their own reporting.
31 · Procurement and vendor review
Verified bank and remittance details so schools can pay, with checks that guard against payment fraud.
32 · Procurement and vendor review
Negotiating the master services agreement each school or system wants to sign, often written on their own paper.
33 · Procurement and vendor review
Agreeing who pays if a claim arises, such as an intellectual property or data breach claim, in terms a school's counsel will accept.
34 · Procurement and vendor review
Negotiating caps on damages that both the school and the vendor can live with.
35 · Procurement and vendor review
Public universities often must contract under their own state's law and courts, so contracts are adjusted for each one.
36 · Procurement and vendor review
Public schools are subject to open records laws, so contracts must say how confidential vendor information is handled when a request comes in.
37 · Procurement and vendor review
State institutions often can't agree to terms that waive their sovereign immunity, such as some indemnities or arbitration, so those terms are reviewed and adjusted.
38 · Procurement and vendor review
Many schools review their vendors again every year, with fresh questionnaires and evidence.
39 · Procurement and vendor review
A SOC 2 report covers a fixed period, so the audit is repeated every year to keep the report current.
40 · Procurement and vendor review
Updating HECVAT answers as the platform and the questionnaire itself change, and sending them again to the schools that ask.
41 · Procurement and vendor review
Penetration tests are repeated every year and after major changes, so the letter schools see is current.
42–52
42 · Accessibility
The Voluntary Product Accessibility Template, completed as an Accessibility Conformance Report that states how the product meets each accessibility criterion. Schools ask for it in nearly every purchase.
43 · Accessibility
The accessibility standard most US schools require, and the one the ADA Title II rule sets for public universities.
44 · Accessibility
The newer version of the standard, which adds criteria such as visible focus and larger touch targets. More schools are starting to ask for it.
45 · Accessibility
Testing with JAWS, the most widely used screen reader on Windows.
46 · Accessibility
Testing with NVDA, the free Windows screen reader many students use.
47 · Accessibility
Testing with VoiceOver, the screen reader built into Macs, iPhones, and iPads.
48 · Accessibility
Checking that everything works without a mouse: every control reachable with the Tab key, in a sensible order, with visible focus.
49 · Accessibility
Checking that text and controls stand out enough from their background for people with low vision to read them.
50 · Accessibility
Running accessibility checkers over the interface to catch common problems early, before manual testing.
51 · Accessibility
A written plan, with dates, for fixing the gaps an accessibility audit finds. Many schools accept known gaps when this plan exists.
52 · Accessibility
A letter from an independent accessibility firm confirming the audit and its results, which some schools require on top of the VPAT.
53–64
53 · Legal, privacy, regulatory
The US law protecting student education records. The vendor acts under the school's direct control and uses student data only to provide the service.
54 · Legal, privacy, regulatory
Contracts that set out how the vendor may use, protect, and share the data it handles for a school.
55 · Legal, privacy, regulatory
A published list of the other companies that handle data for the service, such as hosting, with notice when it changes.
56 · Legal, privacy, regulatory
European and UK privacy law, which applies when a tool serves students in those countries.
57 · Legal, privacy, regulatory
California's consumer privacy law and its later amendment, which give California residents rights over their personal data.
58 · Legal, privacy, regulatory
The growing set of state student privacy laws, such as California's SOPIPA and New York's Education Law 2-d, each with its own contract terms.
59 · Legal, privacy, regulatory
Statements that schools increasingly require about whether and how AI is used, and whether student data trains any model.
60 · Legal, privacy, regulatory
Disclosing which AI models a tool uses, from which providers, and what data is sent to them.
61 · Legal, privacy, regulatory
Telling schools promptly, within the time their contracts and state laws set, if student data may have been exposed.
62 · Legal, privacy, regulatory
Keeping data only as long as it is needed, and deleting it with confirmation when a school asks or a contract ends.
63 · Legal, privacy, regulatory
A registered agent and a process for handling copyright takedown notices about content in the service.
64 · Legal, privacy, regulatory
Making sure the text, images, and media in tools are licensed for use in courses.
65–78
65 · LTI integration
1EdTech's certification that a tool works correctly with LTI 1.3 and its core services. Some schools require it.
66 · LTI integration
Letting instructors choose a tool and its content from inside the LMS and place it in a course.
67 · LTI integration
The LTI service that gives a tool the course roster: who is enrolled, and in what role.
68 · LTI integration
The LTI service that creates gradebook columns and sends scores back to the LMS.
69 · LTI integration
Connecting a tool to an LMS by pasting one URL, with the configuration exchanged automatically.
70 · LTI integration
Connecting to LMSes that don't support dynamic registration, by exchanging client IDs, keys, and URLs by hand with each school's administrator.
71 · LTI integration
Some schools still run older LTI 1.1 integrations, which use a different, older protocol.
72 · LTI integration
When an instructor copies a course into a new term, the tool's placements and settings come along, without the old students' data.
73 · LTI integration
Starting each term clean, with new rosters and gradebooks, while instructors keep the setup they built.
74 · LTI integration
Courses that combine several sections, or one course listed under several departments, so every student appears in one roster and gradebook.
75 · LTI integration
Creating a gradebook column for each placed activity, with the right name and points, in each LMS.
76 · LTI integration
Updating a student's score in the LMS when it changes after it was first sent.
77 · LTI integration
Reporting late work and excused students the way each LMS expects, so a missing score isn't mistaken for a zero.
78 · LTI integration
Some gradebooks expect points out of a maximum and others a percentage, so scores are converted to show correctly in each.
79–86
79 · LMS platforms
Canvas has its own placements, launch behavior, and gradebook rules that a tool has to handle.
80 · LMS platforms
Blackboard Learn, now from Anthology, differs from other LMSes in how tools are registered, placed, and graded.
81 · LMS platforms
Moodle runs on each school's own servers, in many versions and configurations, and each can behave a little differently.
82 · LMS platforms
Brightspace has its own rules for registering tools, deploying them to courses, and creating grade items.
83 · LMS platforms
Sakai, used by a number of research universities, has its own LTI support and quirks.
84 · LMS platforms
Instructure's program for companies whose tools work with Canvas.
85 · LMS platforms
Anthology's program for companies whose tools work with Blackboard.
86 · LMS platforms
D2L's program for companies whose tools work with Brightspace.
87–97
87 · Payments and commerce
The card industry's security standard for taking card payments. Payments go through a PCI-compliant processor, so card numbers never pass through your tool.
88 · Payments and commerce
Collecting sales tax where it is owed and filing it with each state.
89 · Payments and commerce
Most schools don't pay sales tax, so their exemption certificates are collected and kept on file.
90 · Payments and commerce
Students pay for a tool themselves, the way they would for a textbook.
91 · Payments and commerce
The school pays for a tool on behalf of its students.
92 · Payments and commerce
Accepting the purchase orders schools issue before they buy.
93 · Payments and commerce
Invoicing schools and waiting the 30, 60, or more days their payment process takes.
94 · Payments and commerce
Refunding students who drop a course during the add/drop period.
95 · Payments and commerce
Answering card disputes and chargebacks with the evidence the card networks require.
96 · Payments and commerce
Accounting for revenue over the period a purchase covers, rather than all at once.
97 · Payments and commerce
Paying builders their share of what their tools earn.
98–99
98 · Support and relationships
Answering students' first questions, about access, launching, or paying, so they don't land on the builder.
99 · Support and relationships
Contracts signed with each school, so a tool can be used there without its builder negotiating one.
Get started