How to Write an RFP for an Online Examination System

Most examination-platform tenders fail for the same reason: the specification describes features instead of conditions. Vendors then answer different questions, bids stop being comparable, and the evaluation committee is left choosing on price.

An online examination system RFP works when it states the conditions the platform must survive — how many candidates sit simultaneously, what happens if integrity is challenged, which systems it must talk to, and where the data may live. This checklist covers the five requirement areas that decide the outcome.

1. State peak concurrency, not total candidates

The single most common specification error is quoting a total candidate population. Total population tells a vendor almost nothing; peak concurrency — how many candidates sit at the same moment — is what infrastructure must be sized against.

Twenty thousand candidates spread across a fortnight is an ordinary workload. Twenty thousand in one two-hour window is a different engineering problem. Specify:

• Peak concurrent candidates in a single sitting
• Total annual exam volume
• Number of sittings and how compressed the calendar is
• Whether demand is seasonal or continuous

Ask bidders to state a concurrency figure they have actually operated in production, not a theoretical ceiling. For reference, iTest is engineered for 120,000+ concurrent candidates and over 2 million exams a year.

2. Define integrity by consequence

Integrity requirements should follow from what the exam decides. A formative classroom quiz and a professional licensing examination do not need the same defences, and specifying the same requirements for both wastes budget in one direction or risk in the other.

For high-stakes examinations, specify:

• Proctoring approach and integrity scoring
• Identity verification requirements
• Audit trails sufficient to defend a contested result
• Role-based access control over examination data
• Question formats required, including clinical or structured formats

The test of a serious bid is whether the vendor can describe what happens when a result is challenged — not merely how detection works.

3. Name every system it must integrate with

Integration is the requirement most often left vague and the one most likely to move the price after award. List the systems by name and version, and separate the standard from the bespoke.

• Standard LMS integration — iTest integrates with Moodle, Blackboard, Canvas and Google Classroom
• Student information system and HR/ERP connections
• Legacy or ministry systems with no modern interface
• Single sign-on through your existing identity provider
• Data migration from an incumbent platform

Where systems were never designed to interoperate, the work is brokering between them rather than calling an API. Intrazero handles this with iMiddleware, its own integration platform, which connects more than 500 governmental university faculties in Egypt's national LMS programme.

4. Settle deployment and data residency early

For ministries, public universities and hospital groups, the deciding question is often not functional at all — it is where the data lives and whether the answer satisfies a regulator.

State plainly whether you require cloud, on-premise or hybrid deployment, and which framework applies: the PDPL in Saudi Arabia (overseen by SDAIA, with National Cybersecurity Authority controls), GDPR in the EU, or your own national rules. iTest supports cloud, on-premise and hybrid; education platforms are built against GDPR and FERPA.

Establish this before shortlisting. It changes the shape of the whole engagement, and discovering a constraint after award is expensive.

5. Specify languages, training and what happens after go-live

Bilingual delivery is not a translation line item. Native Arabic with true right-to-left layout is a design and engineering requirement, and retrofitting it costs more than specifying it up front.

• Languages required, and whether RTL is among them
• Training scope — administrators, invigilators, examiners, candidates
• Support and maintenance levels after launch
• Phased rollout or single launch
• Data export and handover terms if the contract ends

That final point is worth writing into the specification rather than leaving to negotiation. Institutional data should remain the institution's, and the terms are easier to agree before award than after.

The questions that separate serious bids

If you ask nothing else, ask these four:

1. What peak concurrency have you operated in production, and where?
2. What happens when an exam result is challenged?
3. Which of our named systems have you integrated with before?
4. Can this run inside our infrastructure, and under which framework?

Answers to those four will tell you more than a feature matrix. Intrazero's iTest delivers Egypt's national medical licensing examination (EMLE), sat by 9,397 doctors for the Egyptian Health Council and Ministry of Health — a setting where each of those four questions had a required answer.