HECVAT, VPAT and DPA: What Procurement Will Ask You For

When you propose new career software, procurement will almost always ask for three things: a HECVAT (security), a VPAT or ACR (accessibility), and a data protection or data processing agreement (privacy and contracts). If you know what each is, who cares about it, and what to collect before you socialize a tool on campus, you will move from “interesting idea” to signed contract much faster.

The three documents in plain terms

HECVAT: Security and risk

The Higher Education Community Vendor Assessment Toolkit (HECVAT) is a standardized security questionnaire that helps IT and information security assess risk.

In practice:

It is a spreadsheet or online questionnaire with detailed questions about hosting, encryption, incident response, disaster recovery, and vendor policies.
There are versions: HECVAT Full (for higher risk systems), HECVAT Lite (for lower risk), and HECVAT On-Prem (less common for SaaS tools).
Many SaaS vendors publish a completed HECVAT on their website, often behind a simple request form.

On most campuses, the people who care about the HECVAT are:

Information security and central IT
Sometimes a campus privacy officer or CISO

Example: Champlin Enterprises publishes a completed HECVAT Lite for the Career Readiness Report at https://careerreadinessreport.org/hecvat so IT can review the security posture before committing staff time to deeper evaluation.

VPAT / ACR: Accessibility

A VPAT (Voluntary Product Accessibility Template) is a standardized format for reporting how a product meets accessibility standards, especially WCAG 2.1 and Section 508. When completed, it is often called an Accessibility Conformance Report (ACR).

In practice:

It lists each relevant accessibility criterion and indicates whether the product supports it fully, partially, or not at all, with notes.
It is usually a PDF or Word document that follows the official VPAT template from the ITI (Information Technology Industry Council).
Mature vendors update their VPAT whenever they ship major UI changes.

On most campuses, the people who care about the VPAT or ACR are:

The digital accessibility office or ADA/504 coordinator
Procurement, especially if they maintain an accessible technology policy
Sometimes legal counsel, if accessibility risk is a concern

Example: Career Readiness Report publishes its VPAT / ACR at https://careerreadinessreport.org/vpat so accessibility staff can quickly evaluate conformance claims instead of starting from scratch.

DPA / DTA / privacy terms: Data protection and legal risk

The third piece is less standardized in name but just as important. Depending on your state and institution, you might hear:

Data Processing Agreement (DPA)
Data Transfer Agreement (DTA)
Data Security Addendum
Business Associate Agreement (for HIPAA, less common in career tools)

Functionally, these documents sit alongside the main contract or terms of service and define:

What data are collected, and for what purposes
Whether the vendor is a data controller or processor
Where data are stored and for how long
Which security controls and safeguards are contractually required
Breach notification requirements and timelines
Subprocessor use and oversight

On most campuses, the people who care about the DPA and related terms are:

Procurement and central contracting
General counsel or the campus attorney
Privacy officers or data stewards

Some vendors have a standard DPA or security addendum posted publicly. Others will only negotiate it in the contract stage.

Who on campus will ask for what

Although every institution routes approvals differently, the same pattern appears repeatedly.

Information security and IT

Likely asks for:

HECVAT (Full or Lite, depending on perceived risk)
Copies of SOC 2 reports or similar, if available
Details about SSO, MFA, and API integrations

Their concerns:

Can this system connect safely to campus identity management and data feeds
What happens if the vendor is breached or goes offline
How does this tool interact with other systems in the environment

Having a HECVAT in hand before you talk with IT reduces the back and forth, even if they still require a local security review.

Accessibility office or ADA coordinator

Likely asks for:

VPAT / ACR
Any internal accessibility audits or third-party assessments
Details on keyboard navigation, screen reader support, captioning, etc.

Their concerns:

Whether adopting the tool will create barriers for students or staff
Whether they can mitigate any gaps with training, configuration, or exceptions

A VPAT that clearly admits partial support in some areas can lead to a focused conversation on realistic accommodations. A vague or out-of-date VPAT often triggers a deeper and slower review.

Procurement and legal

Likely asks for:

A DPA or security addendum
The vendor’s standard terms and conditions or contract
Documentation of FERPA compliance, and if relevant, GDPR / state privacy laws
Proof of insurance limits where required by policy

Their concerns:

Data classification, especially if you are handling student records
Who is liable for what, including breach response and uptime
Whether the contract language aligns with institution-wide templates

If the vendor already has higher education customers, they will often have a DPA that maps to typical FERPA and student privacy language, which helps legal counsel move faster.

What to gather before you pitch a tool

A careers office does not need to become a compliance department. It does help, however, to approach internal conversations with a minimum package ready.

Consider preparing the following before you bring a new tool to a committee or IT:

Public security and privacy documentation Ask the vendor for:

Completed HECVAT (Full or Lite) if they have it
Security overview or white paper
Privacy policy and data retention description

Accessibility documentation Request:

Current VPAT / ACR that references WCAG 2.1
Any known accessibility roadmaps or recent fixes
Contact for their accessibility lead, if one exists

Draft data terms Clarify:

Whether they have a standard DPA or security addendum
Where data are hosted and backed up
Whether they use subprocessors and where those are located

Concrete use case and data flows Prepare a one-page summary for campus reviewers that explains:

Who will use the tool (students, employers, faculty, staff)
What data will be imported from institutional systems, if any
What students or employers will enter directly
How long the data are needed and whether they must be exported

Peer references Identify:

Other institutions using the product, especially in your state or system
Any published security, accessibility, or privacy statements from those peers

This package does not guarantee approval. It does, however, show that you understand the institutional process and it often prevents a promising tool from getting stuck for months on basic documentation.

Practical tradeoffs and how to manage them

Not every vendor, especially smaller or newer companies, will have a fully polished HECVAT, VPAT, and DPA ready. There are options, but each has tradeoffs.

No HECVAT yet Security may ask the vendor to complete one as a condition of review. This slows the process but is sometimes acceptable if the risk is low and timelines are flexible.
Incomplete VPAT Accessibility staff may request testing access, sandbox accounts, or a pilot to validate claims. This can support your case if the tool performs better than the documentation suggests, but it consumes staff time.
Custom DPA negotiation Legal and procurement might insist on institution templates, especially for systems handling identifiable student data. Vendors sometimes accept this, but extended redlines can delay implementation seasons.

Where you can, align your expectations with your procurement calendar. For example, avoid introducing a tool that requires custom contract language two weeks before fiscal year close or during your institution’s peak RFP season.

How to start the conversation on your campus

You do not need to arrive with all three documents perfect. You do need to show that you know they exist and that you are prepared to help coordinate.

Practical next steps:

Ask your procurement lead or IT liaison, "For cloud tools with student data, which HECVAT version do we usually require, and do we have a standard DPA template".
Check your institution’s public technology procurement or accessibility site for any posted expectations about VPATs and security reviews.
Build a simple internal checklist for your office so that any staff member proposing a tool gathers at least: a HECVAT or security summary, a VPAT or ACR, and a statement on data handling.

Once those expectations are clear, every future proposal from your careers office will arrive with the core security, accessibility, and privacy information that procurement expects, which keeps the focus on educational value rather than paperwork gaps.