To reduce test bank leaks, protect access to questions before the exam, test controls while questions are visible, and define what happens after a suspected incident. This guide gives certification and assessment teams five practical checks for evaluating online exam security with dummy questions before a live rollout.
Protecting exam content means reducing opportunities to copy or distribute material and preparing a proportionate response when an incident is suspected. No single software control can eliminate every route to leakage, especially a camera outside the device running the exam.
Begin with the material and its exposure
Identify what needs protection: a reusable question bank, a limited-use paper or a practical task. Map who can access each version before, during and after the examination. Controls for candidates cannot compensate for unrestricted access in the content-preparation process.
Validate software controls in the actual environment
Confirm which restrictions are supported by the selected platform, application and operating-system configuration. Test permitted references, accessibility tools and normal exam actions. A control that prevents legitimate work needs adjustment before rollout, even if it blocks an unwanted action successfully.
What TrustExam Content Protect does
TrustExam Content Protect hides exam content when it detects supported screen-sharing, remote-access or display-duplication interference, and restores visibility after that interference stops. This is a response to a detected condition. It does not establish that a question was copied, identify every possible capture method or prove that the entire question bank is secure.
Confirm the application mode, operating systems and device configurations included in your deployment. The checks below are proposed pilot acceptance criteria, not published test results or a guarantee that every configuration is supported. Use a separate test session with dummy questions and authorised testers.
Five checks before protecting a live question bank
1. Establish a normal exam session
First complete a normal test with the permitted references, accessibility tools and equipment that participants will actually use. Include moving between questions and submitting answers. Record the operating system, application version and exam settings so the result can be reproduced.
Acceptance criterion: legitimate tasks can be completed in the agreed configuration, and the team has a documented route for approved adjustments. Resolve unexpected blocking before testing prohibited activities.
2. Test screen sharing and remote access separately
With your technical team, run each approved test scenario against a dummy question. Observe the participant screen and the receiving screen, rather than relying only on a warning message. Record when the condition begins, what remains visible and when the protection response occurs. Screen sharing and remote access should have separate results.
Acceptance criterion: the agreed prohibited action triggers the expected response in the tested setup, and the receiving view does not expose the protected question after the response. If it does, record a failed check and investigate the configuration. A successful test is evidence for that setup only.
3. Validate the actual display configuration
Check the display paths relevant to your programme, including any permitted second screen and prohibited duplication scenario. Record the actual adapters, display modes and connected equipment. The guide to HDMI splitters and display paths explains why the test must cover the intended configuration rather than treating all hardware as equivalent.
Acceptance criterion: each configuration has its own observed outcome and an explicit supported, unsupported or unresolved status. Do not extend one successful display test into a claim that every splitter or capture device is detected.
4. Check recovery after the condition stops
Stop the controlled interference and observe how the session returns to normal. Check question visibility, navigation, the answer already entered and the timer. Record what actually happens; do not assume that hiding content pauses the clock or guarantees answer recovery.
Acceptance criterion: recovery matches the agreed exam policy, and support staff know what to do if a participant cannot continue. Record any resumption, timing or resit decision that must remain with the organiser.
5. Record the external-camera boundary
A camera outside the exam computer may photograph a question without screen sharing or remote access. Software content protection alone cannot establish that no such image was taken. Agree the room rules, permitted devices, observation arrangements and adjustments appropriate to the exam, then test the review process with a staged incident using dummy content.
Acceptance criterion: the organiser can explain both the protection boundary and who reviews an incident. A technical signal is not automatically a misconduct verdict. Use the proctoring signals and appeals guide to define the evidence, reviewer and candidate-response steps.
Account for the physical environment
Agree rules for additional devices, room setup and camera coverage where these are part of the programme. Explain the requirements in advance and define alternatives for participants who need an adjustment. Camera views provide context for review; an incomplete view should not be presented as complete evidence.
Use assessment design as another layer
Consider how question exposure, permitted resources and the reuse of material affect risk. These are decisions for the assessment owner. Check that changes preserve the intended learning or qualification outcome, rather than making the examination harder without improving its validity.
Prepare a response to suspected leakage
Record the session, relevant time, material involved and evidence available to the authorised reviewer. Follow the programme’s access rules when handling recordings or exam content. Distinguish a suspected capture attempt from confirmed distribution; they are different findings and require different evidence.
Evaluate the combined approach
A pilot should test ordinary participant tasks, approved exceptions and controlled examples of the risks in scope. Record both prevented actions and remaining gaps. Use the result to agree an honest protection boundary and the responsibilities of the organiser, technical team and reviewers.
Keep one evidence record for each pilot check
Use these fields in your own pilot worksheet: scenario; dummy question reference; device and operating system; application version and mode; relevant settings; expected behaviour; observed behaviour; time and evidence reference; reviewer; pass, fail or unresolved decision; remaining gap and next action. This is a suggested evaluation record, not a claim that the platform exports all these fields automatically.
Keep test recordings and screenshots under the organiser’s access and retention rules. Record whether a question remained visible, whether an attempted capture was blocked and whether distribution was confirmed as separate findings. Do not use a warning count as a leakage rate.
Turn the pilot into a deployment decision
For a certification programme, the useful outcome is an agreed list of supported setups, tested controls, remaining risks and responsible owners. Require unresolved critical scenarios to be addressed before using a live question bank. Recheck affected scenarios when the application, operating system or exam policy changes.
Bring your delivery mode, permitted tools and priority leakage scenarios to a TrustExam demo. We can use them to discuss the pilot scope and the evidence your assessment team needs for its decision.