HECVAT 4 Response

This is our published response to the Higher Education Community Vendor Assessment Toolkit, version 4.1.5 (released February 10, 2025 by EDUCAUSE), organized by the seven HECVAT 4 domains. HECVAT 4 consolidated the old Full, Lite and On-Premise workbooks into one questionnaire of 321 questions with conditional routing.

Need the official EDUCAUSE workbook completed and signed? Request it at [email protected] and we will fill it out and return it. Allow about a week for the first one, and less after that. A downloadable pre-completed workbook is planned for this page before launch.

This page exists so that your analyst can make a go/no-go call without waiting for any of that, and so the answers are on the public record rather than in an email thread.

Scope and date. This response covers the hosted Career Readiness Report service at careerreadinessreport.com. The platform launches August 15, 2026 and capabilities roll out on a published roadmap from there, so answers describe architecture that is decided and being built, not a system that has been running under independent audit. This response is re-issued against the production system once the full feature set is complete.

---

1. Organization

Vendor. Champlin Enterprises, LLC, an Illinois limited liability company, United States. The Career Readiness Report is one of several software products the company builds and operates.

Ownership and funding. Privately held. This product carries no revenue; it is funded by the company's other products. There is no investor, no acquisition process and no paid tier, so there is no commercial pressure to change the data terms later.

Security function. We do not maintain a separately staffed information security department. Security responsibilities sit with the engineering lead who architects and operates the platform. For an institution that requires a named security officer with an independent reporting line, this will not satisfy your control.

Certifications and audits. None. No SOC 2 Type I or Type II, no ISO 27001, no FedRAMP, no StateRAMP or TX-RAMP authorization, no HITRUST. An independent penetration test is scheduled before launch and the summary letter will be published on this site.

Insurance. We do not currently carry cyber liability insurance and cannot provide a certificate of insurance naming your institution as an additional insured. If your contract requires one, we cannot meet that requirement today. Stated plainly because it is a common hard gate and you should not discover it at signature.

Subcontractors. No development, support or administration is subcontracted or offshored. Sub-processors are limited to the infrastructure providers listed in section 3.

Breach history. The Career Readiness Report service has had no security incident. It is a new system that has not yet launched, so that statement carries exactly as much weight as it should, which is very little. We are not making a corporate-wide historical representation here; if your questionnaire requires one, ask and we will answer it specifically and in writing.

Business continuity. Encrypted backups with a documented restore procedure. If the company were to discontinue the Service, the Terms commit us to ninety days' notice to institutional administrators with export available in open formats for the entire notice period. That commitment is contractual, not a marketing statement.

---

2. Product

Description. A multi-tenant web application that measures the eight NACE Career Readiness Competencies through student self-assessment plus 360-degree feedback from employers, internship supervisors, mentors and faculty, and produces cohort, program and accreditation reporting for the institution.

Deployment model. Software as a Service, hosted by us. No on-premise option. No customer-managed keys. Institutions are separated logically, not physically. If your policy requires a single-tenant deployment or customer-held encryption keys, tell us before onboarding, because the answer today is no.

Data classification handled. Personally identifiable information from student education records as defined by FERPA: name, institutional email, student identifier, program, class standing, cohort, term, assessment responses, and any custom fields the institution defines. Optional demographic fields where the institution enables them.

Data we do not handle. No Social Security numbers, no financial account or payment card data (the Service accepts no payment, so PCI DSS is out of scope), no protected health information, no biometric data, no export-controlled or classified data. If a field you plan to import would introduce any of these, do not import it.

Authentication. Institution-managed accounts with role-based access. Optional campus single sign-on via SAML 2.0 and OpenID Connect, tested against Shibboleth, InCommon, Microsoft Entra ID and Google Workspace. SSO can be configured as required, so local passwords are disabled entirely.

Rater access. External raters do not create accounts. They respond through a single-use, expiring, cryptographically random link bound to one student and one experience. A rater link never establishes a session against any account and never grants access to any other record. This is deliberate: requiring employers to register is the single largest cause of response-rate collapse in 360 programs, and account sprawl among external parties is a security liability in its own right.

Session management. Idle and absolute session timeouts, secure and HTTP-only cookies, CSRF protection on all state-changing requests, and session invalidation on password change and on privilege change.

Accessibility. WCAG 2.2 Level AA target. See the VPAT 2.5 conformance report. Note that HECVAT 4's IT Accessibility domain assesses against WCAG 2.1 AA; our target is the later and stricter 2.2.

---

3. Infrastructure

Hosting. Liquid Web, United States. Dedicated PHP-FPM pool, isolated system user per site.

Data residency. All service data is stored in the United States. No processing or storage outside the US. No data is transferred to a jurisdiction without an adequacy decision or appropriate safeguards.

Sub-processors.

We give institutional administrators notice before adding a sub-processor that would process personal data, so you have the opportunity to object.

Encryption in transit. TLS 1.2 minimum, TLS 1.3 preferred. HTTP redirects to HTTPS. HSTS enabled. Strict origin certificate validation between the edge and the origin.

Encryption at rest. Full-disk encryption on all storage. Sensitive fields carry an additional application-layer encryption envelope. Backups are encrypted, and restore access is held to the same least-privilege set as production.

Tenant isolation. Every record carries a tenant identifier, and scoping is enforced in the data-access layer rather than left to developer discipline: a query that omits the tenant scope raises rather than silently returning another institution's rows. Cross-tenant isolation is covered by automated tests that run on every change. This is the single control most worth verifying in a review, and we will walk your analyst through the implementation on request.

Administrative access. Our production access is least-privilege, individually attributed, requires multi-factor authentication, and is logged. Shared or generic administrative accounts are not used. No vendor access to your institution's data occurs for support purposes without a logged, time-bounded authorization.

Audit logging. Authentication events, data exports, administrative actions and record modifications are written to an append-only log recording actor, timestamp and affected record. Institutional administrators can read their own institution's log. This exists so a FERPA access review is answerable with evidence rather than assertion.

Vulnerability management. Dependencies are monitored for published advisories and patched on a risk-ranked basis, with security patches to internet-facing components prioritized. We do not currently run a continuous automated scanning program against production or engage a third-party managed detection service.

Logging retention. Server logs (IP, user agent, timestamp, path) are retained for a short period for security and abuse prevention. Application audit logs are retained for the life of the account.

---

4. AI and machine learning governance

HECVAT 4 added a conditional AI/ML domain of 32 questions. It applies to us, so we answer it directly rather than claiming the section is out of scope.

Where AI is used. One feature: generating a written development narrative for a student from their competency results. Nothing else in the Service uses a model. Scoring, aggregation, benchmarking, reporting and access control are all deterministic code. No model makes or influences any decision about a person.

Model and provider. A large language model provided by Anthropic, accessed over an encrypted API connection. This is an LLM, not a model we trained.

Training on your data. We do not train models on student data, and our agreement with the provider prohibits the provider from training on content submitted through the API. Content is not retained by the provider for training purposes. We do not fine-tune any model on institutional or student data.

What is sent. The student's competency scores plus limited context such as major and institution name. Direct identifiers are not required for the feature to work and are minimized in the request.

Human oversight and contestability. Output is clearly labeled as AI-generated inside the Service. A student or an administrator can request regeneration. An administrator can disable the feature for the entire institution, and the rest of the platform is fully functional with it off.

Prohibited uses. The Terms forbid using competency scores to make consequential decisions about an individual, including admission, employment, discipline, financial aid and academic standing. The instrument is not validated for that purpose. This is a contractual restriction on the institution as well as a design position on our side.

Bias and fairness. We have not conducted a formal algorithmic bias audit of narrative generation. We consider this a real and unresolved limitation and are stating it rather than omitting it. Mitigations today are structural: the model summarizes scores it is given rather than producing a score, no model output enters any ranking or decision, aggregate benchmarks are computed by deterministic code and never by a model, and the feature can be switched off wholesale.

Automated decision-making under GDPR. The Service performs no automated decision-making producing legal or similarly significant effects within the meaning of GDPR Article 22, because no model output drives an outcome for a data subject.

AI supply chain. One provider, named above, disclosed in the sub-processor list, and subject to the same notice-before-change commitment as any other sub-processor.

---

5. Privacy

Full detail is in the Privacy Policy. The questions a HECVAT reviewer asks:

Controller and processor. For student records the institution is the controller and we are the processor. We process only on your documented instructions. We do not decide what is collected, who is enrolled, or how results are used.

FERPA. We operate as a school official with a legitimate educational interest under 34 CFR § 99.31(a)(1)(i)(B) and expressly accept the obligations that designation carries: use of education records solely to perform the service, operation under the institution's direct control, no redisclosure except as directed in writing or as required by law, and no use of records for our own purposes including marketing or product development on identifiable data. This acceptance is contractual, in the DPA and FERPA addendum, not merely a policy statement.

Sale and sharing. We do not sell personal information. We do not share personal information for cross-context behavioral advertising. There is no advertising anywhere in the student experience. Under CCPA as amended by CPRA we act as a service provider; under comparable state laws, a processor.

GDPR. For students in the EEA, UK or Switzerland we act as processor. We will execute a Data Processing Agreement incorporating the European Commission's Standard Contractual Clauses. The full processor commitments (Article 28 duties, breach notification, assistance with Articles 32 to 36, deletion or return at termination, audit information) are in the DPA.

Data minimization. The institution defines which fields exist. We recommend collecting the minimum that answers the assessment question, and demographic fields are off unless the institution enables them.

Benchmarking. National and peer benchmarks are computed from anonymized aggregates with direct and indirect identifiers removed and a minimum group-size threshold applied, so no statistic derives from a group small enough to identify an individual. No institution is named in a cross-institutional comparison without written agreement. An institution can opt out of contributing to benchmarks entirely, and opting out restricts no other feature.

Retention and deletion. The institution controls retention. Export of all data in open formats, deletion of an individual student's records, and deletion of the entire institutional account are all available at any time. On account deletion, personal data is removed from live systems promptly and from encrypted backups within the normal rotation. Anonymized aggregates that can no longer be linked to any individual may be retained.

Data subject requests. Directed to the institution as controlling party; we support the institution in responding.

Children. Designed for post-secondary students, not directed to children under 13. Institutions enrolling dual-enrollment or early-college students under 18 should tell us, as additional obligations may apply.

---

6. IT accessibility

Detail is in the VPAT 2.5 Accessibility Conformance Report and the Accessibility Statement.

Conformance target. WCAG 2.2 Level AA, Revised Section 508, EN 301 549.

Report format. VPAT 2.5 INT, which covers the US and EU standards in one document.

Testing. Automated checks in the build plus manual keyboard-only and screen-reader passes. We have not commissioned a third-party accessibility audit, and we have not conducted formal usability testing with assistive-technology users. Both are limitations we state rather than omit.

Remediation. Reported barriers are triaged like security issues, with acknowledgement targeted within two business days and a remediation plan communicated even where the fix takes longer. [email protected]

Accessibility of the marketing site. This public site scores 100 on Lighthouse accessibility and is tested at every deploy. That is not a substitute for auditing the application, but it indicates the standard we hold.

---

7. Case-specific and consortium questions

Payment card data. Out of scope. The Service accepts no payment of any kind, so PCI DSS does not apply.

Protected health information. Out of scope. Do not import PHI.

Research data. The Service is not designed as a system of record for human-subjects research. If your IRB intends to use assessment data for research, that determination and its consent requirements are the institution's.

State authorization programs. No TX-RAMP or StateRAMP authorization. Texas and other states operating a mandatory cloud authorization program should treat that as a gap.

Contract requirements we can meet. Signed DPA, FERPA addendum, GDPR SCCs, a security review call with your analyst, notice before sub-processor changes, 72-hour breach notification, and export on demand.

Contract requirements we cannot meet today. Certificate of insurance, SOC 2 report, single-tenant hosting, customer-managed encryption keys, on-premise deployment, uptime service level agreement with remedies.

---

Contact

Security questionnaires, the official signed HECVAT workbook, architecture questions and review calls: [email protected]

Champlin Enterprises, LLC, Illinois, United States