New from Proctortrack: Meritclaw, the same integrity engine, rebuilt for hiring. → Meet Meritclaw

How to Write an Online Proctoring RFP: A Complete Checklist for Universities

Choosing an online proctoring solution is not just about finding software that monitors exams.

A university must consider academic integrity, student privacy, accessibility, technical compatibility, faculty workload, and long-term costs.

But when every vendor promises secure exams, easy integration, and reliable support, how can institutions identify the right solution?

The answer begins with a well-written online proctoring RFP (Request for Proposal).

An RFP helps universities explain their needs, ask consistent questions, and compare providers using clear evaluation criteria.

A poorly written RFP can lead to confusing proposals, unexpected costs, or software that does not meet institutional requirements.

This guide explains how to write an online proctoring RFP, what to include in the requirements checklist, and how to evaluate vendors before making a purchasing decision.

What Is an Online Proctoring RFP?

An online proctoring RFP is a formal document universities use to request proposals from companies offering remote examination monitoring and security services.

It describes the institution’s examination needs and asks vendors to explain how their solutions can meet them.

A typical RFP covers:

  • Institution and examination requirements
  • Proctoring methods and security controls
  • Student identity verification
  • Learning Management System (LMS) integration
  • Accessibility and accommodations
  • Data privacy and security
  • Implementation and technical support
  • Pricing and contract terms
  • Vendor evaluation criteria

An RFP is different from a request for information (RFI), which helps institutions explore available solutions, or a request for quotation (RFQ), which typically focuses on obtaining prices for more clearly defined requirements.

If a university does not yet understand its options, an RFI or market review may be more useful before issuing a formal RFP.

The goal is not to produce the longest document. It is to make sure every provider answers the questions that matter.

Step 1: Define Your University’s Examination Requirements

Before writing technical requirements, determine what the university needs to achieve.

Different examinations carry different levels of risk.

A short weekly quiz may need basic restrictions, while a final examination, nursing assessment, or professional qualification may require stronger monitoring and supervision.

Start by collecting information from departments that conduct online assessments.

Consider:

  • How many students take online examinations each year?
  • How many examinations are conducted per semester?
  • What is the highest number of simultaneous exam sessions?
  • How long do examinations usually last?
  • Which programs require stronger security?
  • Do students take exams across different countries and time zones?
  • Are examinations conducted inside the LMS or through external assessment platforms?

Sample RFP requirement:

“The university seeks an online proctoring solution capable of supporting [number] annual examination sessions, including a peak of [number] concurrent candidates, across undergraduate, graduate, and professional programs.”

Replace the placeholders with reliable institutional estimates.

Without realistic examination volumes, vendors may provide prices or capacity claims that do not match actual needs.

Step 2: Involve the Right University Departments

An RFP written by only one department may overlook important requirements.

For example, IT teams may prioritize security and integration. Examination administrators may focus on incident reporting. Faculty may value simple exam setup, while students need clear instructions and accessible workflows.

Create a small evaluation team with representatives from:

  • IT and information security
  • Procurement and finance
  • Examination and assessment operations
  • Academic integrity and faculty leadership
  • Digital learning and LMS administration
  • Accessibility and disability support
  • Legal and student privacy

Each department should help define its requirements before the RFP is released.

Assign responsibility for writing requirements, reviewing vendor responses, testing software, and making the final recommendation.

This helps avoid a situation where the selected product works technically but creates problems for the people who must use it.

Step 3: Create a Complete Online Proctoring RFP Requirements Checklist

This is the most important part of the document.

Instead of asking whether a vendor offers “secure online proctoring,” divide the requirement into specific capabilities and expected outcomes.

The following eight areas provide a practical starting point.

1. Examination Security and Candidate Authentication

Objective: Establish reasonable confidence that the correct candidate takes the exam and unauthorized activities are appropriately restricted.

Include questions such as:

  • How does the platform verify candidate identity before an examination?
  • Can candidate access be linked to existing university accounts?
  • What browser or application restrictions are available?
  • How are attempts to access unauthorized tools handled?
  • Can examination security settings differ by course or assessment?
  • What happens when an identity check cannot be completed?

Universities should evaluate the limits of each security control.

For example, browser restrictions may reduce unauthorized activity on the testing computer but cannot automatically control every external device.

What to request: A live demonstration of candidate check-in, secure exam launch, restricted activities, and exception handling.

2. Automated, Live, and Hybrid Proctoring Options

Objective: Match examination supervision to the assessment’s risk level.

Universities may need different monitoring methods across departments.

Automated proctoring can identify events for later review. Live proctoring allows a trained person to supervise the session. Hybrid approaches combine automated monitoring with human oversight.

Ask vendors:

  • Which proctoring methods are available?
  • Can administrators select different models for different examinations?
  • How are suspicious events flagged?
  • When can a human proctor intervene?
  • Who makes the final decision about potential misconduct?
  • How are false or misleading alerts investigated?

An automated flag should not automatically become a finding of academic dishonesty.

What to request: A demonstration showing how an incident moves from detection to review and resolution.

3. LMS Integration and Technical Compatibility

Objective: Ensure the solution works with the university’s existing technology.

Most institutions already use learning platforms such as Canvas, Blackboard, Moodle, or D2L Brightspace.

A proctoring system should fit into the existing examination workflow instead of forcing faculty and students to manage unnecessary additional steps.

Important questions include:

  • Does the solution integrate with our specific LMS version?
  • Does it support Learning Tools Interoperability (LTI) 1.3?
  • Which LTI Advantage services, if any, are supported?
  • Does the provider hold relevant current integration certifications?
  • How are students, courses, and examination settings connected?
  • What software installation, permissions, and device requirements apply?
  • What happens after an LMS update?

LTI Advantage, developed by 1EdTech, provides a useful framework and sample procurement wording for education technology integrations.

What to request: A working demonstration using the institution’s LMS test environment, not only a presentation of supported logos.

4. Student Data Privacy and Information Security

Objective: Protect examination data and reduce institutional risk.

Remote proctoring may involve examination recordings, screenshots, identity information, and system activity records.

Universities must understand what information is collected, how it is protected, and who can access it.

Ask vendors:

  • What student and examination data is collected?
  • Where is the information processed and stored?
  • Which employees or service providers can access it?
  • How long is the data retained?
  • Can the institution establish retention and deletion requirements?
  • How are security incidents reported and managed?
  • What happens to institutional data when the contract ends?

A useful resource is the Higher Education Community Vendor Assessment Toolkit (HECVAT) from EDUCAUSE.

HECVAT 4 includes questions covering cybersecurity, privacy, accessibility, and artificial intelligence.

Requesting a completed HECVAT can make vendor security reviews more consistent. However, completing the questionnaire is not proof that every requirement has been met.

What to request: A completed applicable security questionnaire, relevant supporting evidence, data-handling terms, and an incident-response overview.

5. Accessibility and Student Experience

Objective: Make examinations accessible without creating unnecessary security gaps.

Students may use assistive technologies, require additional exam time, or have approved accommodation arrangements.

An RFP should explain the university’s accessibility expectations and require evidence that they can be met.

Questions should include:

  • Can candidates complete the examination workflow using approved assistive technologies?
  • Are keyboard-only navigation and screen reader access supported?
  • Can authorized accommodations be configured?
  • Are alternative arrangements available when a standard monitoring requirement creates a barrier?
  • Does the provider supply current accessibility documentation?
  • What happens when a student faces an accessibility problem during an exam?

Universities can use the Web Content Accessibility Guidelines (WCAG) 2.2 as an accessibility evaluation reference while identifying the specific legal standard that applies to them.

Ask for a current Accessibility Conformance Report (ACR), often prepared using a VPAT template, and test the actual software with relevant users.

What to request: Accessibility documentation and a practical demonstration of the complete student journey, including check-in and incident recovery.

6. Incident Reporting and Human Review

Objective: Give institutions useful evidence while protecting students from incorrect decisions.

A system that generates hundreds of unclear alerts can create additional work for examination administrators.

Universities should evaluate whether reports are understandable, timely, and useful.

Ask:

  • What evidence is available for each flagged event?
  • Are incidents linked to timestamps and relevant recordings?
  • Can authorized faculty review incidents within the approved workflow?
  • Can reviewers add notes and document outcomes?
  • How quickly are reports available?
  • Can the institution export the records needed for an investigation or appeal?

Reporting quality matters as much as monitoring features.

What to request: Sample reports and an end-to-end demonstration using an illustrative examination incident.

7. Technical Support and Operational Reliability

Objective: Help examinations continue smoothly when technical problems occur.

Support becomes especially important during final examination periods.

A student experiencing technical difficulties may have limited time to resolve the issue.

Ask vendors:

  • What student and faculty support channels are available?
  • Is assistance available during all scheduled examination hours?
  • What are the agreed response and resolution targets?
  • How are interrupted examinations recovered?
  • What availability commitments does the provider offer?
  • How are planned maintenance and service interruptions communicated?
  • What onboarding and faculty training are included?

Also request evidence showing that the platform can handle the university’s expected peak examination volume.

What to request: A support plan, service-level agreement, incident escalation procedures, and documented recovery workflows.

8. Pricing and Total Cost of Ownership

Objective: Understand the complete cost rather than comparing advertised prices alone.

Online proctoring pricing may depend on exam sessions, examination duration, proctoring type, support requirements, and licensing arrangements.

Two offers with the same basic price can create very different total costs.

Ask vendors to separate:

  • Platform licensing
  • Per-exam or per-student charges
  • Live proctoring charges
  • Setup and integration fees
  • Training and support costs
  • Additional reviews or reporting
  • Minimum purchase commitments
  • Contract renewal increases
  • Exit and data migration costs

What to request: A standardized pricing sheet using the same examination volume and usage assumptions for every provider.

This allows the university to compare the total cost of operating each solution rather than relying on the lowest headline price.

Step 4: Separate Mandatory and Preferred Requirements

Not every desirable feature should become a compulsory requirement.

An RFP that treats every feature as essential can unintentionally eliminate suitable vendors or increase costs without improving assessment outcomes.

Use three classifications:

Requirement type Meaning Example
Mandatory Must be satisfied for an eligible proposal Meets applicable institutional privacy and accessibility requirements
Preferred Important, but alternatives can be considered Supports the university’s preferred incident review workflow
Optional Adds value but is not essential Provides additional customizable analytics dashboards

Use neutral wording that describes the needed outcome rather than a particular vendor’s product design.

For example, instead of requiring a named lockdown tool, ask vendors to explain how their secure testing controls restrict unauthorized resources and demonstrate those restrictions.

Sample RFP wording:

“Vendors must identify whether each requirement is fully supported, partially supported, unsupported, or dependent on additional configuration. All claims must include supporting documentation or a demonstration plan.”

This approach makes responses easier to compare and reduces the risk of selecting a provider based on marketing claims.

Step 5: Build a Fair Vendor Evaluation Scorecard

After defining the requirements, explain how proposals will be evaluated.

A weighted scorecard helps the university compare vendors consistently.

For example:

Evaluation category Suggested weight
Exam security and proctoring controls 20%
Privacy and information security 15%
Accessibility and student experience 15%
LMS integration and compatibility 15%
Reporting and human review 10%
Support and operational reliability 10%
Total cost of ownership 10%
Implementation and training 5%
Total 100%

These percentages are an illustrative starting point. Universities should adjust them to match their examination risks and institutional priorities.

Each category can be scored from 0 to 5, where:

  • 0: Requirement not met or evidence missing
  • 1–2: Limited support or significant concerns
  • 3: Meets the defined requirement
  • 4–5: Meets the requirement with stronger demonstrated performance or additional value

For each category, multiply the rating divided by five by the category’s weight.

For example, a rating of 4 out of 5 in a category worth 20 points produces 16 points.

Mandatory requirements should be checked separately before applying the weighted score.

A high overall score should not compensate for an unacceptable failure involving essential student privacy, accessibility, or security obligations.

Step 6: Require Vendor Demonstrations and a Practical Pilot

Written proposals cannot prove that every feature works as expected.

Shortlisted providers should be asked to demonstrate their technology using consistent scenarios.

Consider five tests:

Test scenario What to evaluate
A student starts an LMS-based examination Login, setup, and integration experience
A candidate attempts a restricted activity Security controls and documented limitations
An automated event requires investigation Reporting quality and human review
A student uses an approved accommodation Accessibility and configurable exam settings
Internet access is interrupted Recovery, support, and preservation of exam progress

The university should observe the same tasks across all shortlisted solutions.

Record the actual setup steps, technical issues, support needs, review time, and student feedback.

A pilot can expose problems that are difficult to identify in a proposal.

If a provider cannot demonstrate an important requirement, the university should document the gap before making a decision.

Step 7: Specify Implementation, Contract Terms, and RFP Deadlines

The final RFP should explain what happens after the institution chooses a provider.

Include requirements for:

  • Implementation schedule and responsibilities
  • LMS configuration and testing
  • Training for faculty and administrators
  • Student communication and technical preparation
  • Service-level agreements
  • Data protection and confidentiality
  • Contract duration and renewal terms
  • Data export and deletion at contract termination
  • Future pricing changes
  • Transition assistance if the university switches providers

Also provide a clear procurement schedule.

At minimum, identify the proposal submission deadline, vendor question period, evaluation stages, demonstration expectations, and planned award date.

Follow your institution’s procurement rules, particularly when the purchase requires competitive bidding or public-sector approvals.

Clear expectations help both vendors and university teams plan realistically.

Common Mistakes Universities Should Avoid in an Online Proctoring RFP

Even a detailed RFP can produce poor results when its requirements are unclear.

Mistake 1: Copying another university’s RFP without reviewing it. Examination volume, LMS infrastructure, budgets, and student needs may be different.

Mistake 2: Choosing the provider with the most features. A long feature list does not establish reliability or value. Focus on controls that address real institutional risks.

Mistake 3: Treating low pricing as the deciding factor. Hidden implementation, support, or usage costs can change the long-term financial picture.

Mistake 4: Ignoring faculty and student experience. Software that is difficult to use can increase support demands and undermine adoption.

Mistake 5: Relying only on vendor claims. Important requirements should be supported by documentation, demonstrations, or a practical pilot.

An effective procurement process balances security, usability, cost, and institutional accountability.

How Proctortrack Fits Into an Online Proctoring RFP Evaluation

Proctortrack provides online examination integrity solutions for universities, colleges, and other assessment organizations.

Its offering includes multiple security and supervision models, including secure browser controls through ProctorLock, automated proctoring, human quality-assurance review, and live proctoring options.

Proctortrack also offers integrations with major learning management systems, including Canvas, Moodle, Blackboard, and D2L Brightspace, helping institutions evaluate examination security within their existing learning environments.

These capabilities are relevant to RFP requirements covering secure testing, flexible supervision, LMS integration, and incident reporting.

Institutions should request demonstrations of the specific product configuration they are considering, along with documentation covering implementation, accessibility, privacy, support, and pricing.

No single provider should be selected solely because its feature list appears complete.

The strongest procurement decision is based on demonstrated performance against the university’s own requirements.

Final Thoughts: A Better RFP Leads to a Better Proctoring Decision

Choosing an online proctoring solution can affect thousands of examination sessions, faculty workflows, and student experiences.

A clear RFP gives universities a practical way to assess these responsibilities before making a financial commitment.

Start with examination needs, define measurable requirements, involve the right stakeholders, and compare providers using consistent evidence.

Most importantly, test what matters before signing the contract.

The best online proctoring RFP does not ask which vendor offers the most features. It asks which solution can reliably meet the university’s academic, technical, financial, and student needs.

Explore Proctortrack’s online proctoring options to understand how different examination security and supervision models can support institutional requirements.

BOOK A DEMO

Register using institution email as personal email will not be given priority. (Please do not fill this form if you are a student)
 

Download your E-Book!

Understanding and Combating Online Exam Cheating

Kindly use your Organization/Institute email below.