A security due-diligence checklist for higher-ed AI vendors

Every institution I have worked with is being pitched AI products in admissions, enrollment management, student success, and advancement at a pace that would have been unimaginable three years ago. The number of vendors is up. The sophistication of the marketing is up. The pressure on institutional leadership to “adopt AI” is up. What has not kept pace is the quality of security due diligence.

This is a buyer’s checklist. I wrote it partly because I want prospective CeliaConnect customers to evaluate us against it — we welcome the scrutiny — and partly because I have watched institutions sign DPAs with AI vendors on the basis of a single SOC 2 logo on the website. That is not enough. The questions below are the questions your IT, legal, and compliance teams should be asking every AI vendor, without exception.

Print this. Share it. Push back when a vendor resists answering.

Section 1: Data inventory

Before you touch encryption or compliance certifications, establish what data the vendor is actually going to process.

• What specific data fields does your product ingest from our system? Ask for the explicit field list, not a category description. “Student demographic information” is not an answer. “First name, last name, email, home address, DOB, parent email” is an answer.
• Is any of that data directly identifying, indirectly identifying, or sensitive under FERPA, GDPR, or state privacy law? A credible vendor will not only know the answer but will have a published data classification for every field they ingest.
• What data do you derive or generate from the data we send? Scores, embeddings, vector representations, content outputs — these are new data that did not exist before. Where does it live and who owns it?
• Is any of our data used to train your models or any third-party model? This is the single most important question in the entire checklist. If the answer is yes, or if the answer is qualified, dig deeper. If the vendor cannot give you a clear “no” on training, understand what opting out requires and whether it actually propagates to their sub-processors.
• What is the minimum field set required for your product to function? Ask the vendor to describe the smallest possible data footprint. Many vendors over-collect because their architecture requires it; some over-collect because they have not thought about it. Both are worth knowing.

Section 2: Compliance and legal

• Are you SOC 2 Type II compliant? If yes, request the current report under NDA. If no, what is your timeline? “We are working toward SOC 2” is a fine answer for an early-stage vendor. “We are SOC 2” without an actual report is not.
• How does your product align with FERPA? Specifically: do you consider yourself a school official under the school official exception, a service provider under directory information use, or both? The answer determines what your DPA needs to cover.
• Do you have a DPA template? Can we review it before we proceed? Vendors who will not share their DPA template before a signed NDA are red-flagged.
• If we are a European institution or enroll European students, how do you handle GDPR? What is your Article 28 data processor posture? If the vendor does not know what Article 28 is, stop the conversation.
• What is your data residency policy? Can we require EU residency or U.S. residency? This matters for cross-border institutions and for state schools with residency requirements.
• Do you have a published sub-processor list? How do you notify us of changes? Sub-processors matter. The vendor’s security posture is the ceiling; the weakest sub-processor is the floor.
• How do you handle data subject requests (access, deletion, rectification)? Both for GDPR and for CCPA/state privacy law equivalents.

Section 3: Encryption and key management

• How is our data encrypted at rest? AES-256 is table stakes. The more interesting question is who holds the keys.
• How is our data encrypted in transit? TLS 1.3 should be the answer. Anything less warrants follow-up.
• What is your key management architecture? Specifically, is there a hardware security module (HSM)? Is there envelope encryption? Who can access plaintext data under what circumstances?
• How are our credentials to your system (and your credentials to our system) stored? This is often the weakest link. Slate service-user credentials sitting in a plaintext config file destroy every other control upstream.
• What is your credential rotation policy? How fast can we force a rotation? You want to know the answer before you need it.

Section 4: Tenant isolation

• Is our data physically or logically isolated from other customers? Physical isolation (separate databases per customer) is the strongest answer. Logical isolation (shared database with per-customer row filtering) is weaker but manageable if implemented correctly.
• How do you prevent cross-tenant data leakage? Ask for the specific control. “We use tenant IDs in every query” is a policy. “The database binding is scoped per request so cross-tenant queries are impossible” is an architecture.
• Have you ever had a cross-tenant incident? Ask. You want to know both the honest answer and how the vendor responded.
• How do you handle our data if we terminate? What is the deletion SLA? Do you retain anything in backups, and for how long?

Section 5: AI-specific controls

These questions apply specifically to AI vendors and are often the ones institutional IT teams forget to ask.

• Which models do you use, and who operates them? OpenAI, Anthropic, Google, AWS Bedrock, self-hosted open weights, fine-tuned? Each has different data handling implications.
• What data do you send in prompts? What data do you receive in completions? Ask for a sample redacted prompt and a sample redacted completion. This single request will tell you more about the vendor’s data handling than any security whitepaper.
• Are prompts logged by the model provider? For how long? The default answer from most AI labs is “up to 30 days for operational purposes.” Some enterprise contracts extend or reduce this. Know what your contract with the vendor says about their contract with the model provider.
• Is your data used to train or fine-tune any model, including the vendor’s or the AI lab’s? Repeat of the question from Section 1. Ask it again in this context.
• How do you handle prompt injection and output injection? Specifically, if a bad actor can get their content into the AI pipeline, what protections prevent unauthorized data exfiltration via prompt manipulation?
• How do you handle PII in AI pipelines? This is where vendors often reveal whether they have thought seriously about the problem. The best answers are architectural (the PII never enters the pipeline) rather than procedural (we filter the pipeline for PII).
• Do you have red-team or adversarial-testing documentation you can share? Any vendor whose AI product has not been stress-tested against prompt injection, jailbreak attempts, and adversarial inputs is incomplete.

Section 6: Audit, observability, and incident response

• What operations on our data are audit-logged? What is in each log entry? “Everything” is not an answer. You want the specific event taxonomy: reads, writes, admin actions, impersonation, key access, model-call events.
• Are audit logs tamper-evident? Hash chains, append-only storage, periodic anchors to external storage. If the vendor can silently modify their audit logs, the audit logs are not trustworthy.
• Can we export audit logs for our own records? On what cadence? In what format?
• What is your incident response plan? What is the customer notification SLA? 24 hours? 72 hours? Contractually binding? Most state breach-notification laws require 30 to 60 days, which is not fast enough.
• Do you have a vulnerability disclosure program or bug bounty? Publish the contact. The presence of a disclosure program is a positive signal; the absence is worth noting.
• Do you conduct regular penetration tests? When was the last one and can we see the summary? Annual is the floor. Quarterly is better for early-stage AI products.

Section 7: Operational trust

• How long has your company existed? Who funds you? What is your runway? These are not security questions on paper, but an AI vendor running out of cash next quarter is a security incident in slow motion. You need the vendor to be around when your contract ends.
• Who on your team has access to production data? What roles? What controls? Ask for the privileged access list. You may not get names, but you should get roles and counts.
• What is your business continuity plan? If your primary engineer gets hit by a bus tomorrow, who maintains the product? This is especially important for smaller vendors where a single person may hold critical operational knowledge.

Section 8: Red flags

Patterns that should make you stop and reconsider, in rough order of severity:

• The vendor cannot produce a specific field-by-field data inventory.
• The vendor’s DPA template is not available for review before contract negotiation.
• The vendor cannot definitively answer whether your data is used for model training.
• The vendor treats every security question as “we will provide that when you sign an NDA.”
• The vendor’s security page is three paragraphs of marketing language and a single SOC 2 logo.
• The vendor does not have a published sub-processor list.
• The vendor’s incident response SLA is longer than your state’s breach notification requirement.
• The vendor implements “PII protection” as a promise in a terms-of-service document rather than as an architectural control.
• The vendor’s pricing model depends on processing as much data as possible (which structurally incentivizes over-collection).

A note on CeliaConnect

CeliaConnect was built with this checklist in mind — or rather, the shape of this checklist was partly informed by the mistakes I watched competitors make. Our architectural answer to most of the Section 5 questions is “the AI does not see PII at all, by architecture, so the question does not apply in the way it applies to other vendors.” Our answer to Section 4 is per-tenant D1 databases, not shared-schema-with-row-filtering. Our answer to Section 6 is tamper-evident audit chains anchored weekly to external storage.

We encourage every institution evaluating CeliaConnect to run this checklist against us and against every other vendor in the conversation. We will answer every question on the list with specifics, not marketing language. That standard of openness is what higher-ed AI should look like.

Request our security whitepaper →

Join the waitlist →