Define what secure delivery means for your assessment
Secure assessment delivery protects the assessment decision throughout the candidate workflow. The controls you need depend on what the result determines, who takes the assessment, which systems supply identity and roster information, and how a candidate can recover from a failure.
Start by documenting the decision that the assessment supports. A formative course quiz, a placement assessment, and a licensure examination do not have the same risks or response requirements. Include the consequences of an incorrect score, an unavailable service, an unauthorized attempt, an accommodation failure, and a disputed result.
Question and Test Interoperability (QTI) 3 describes assessment content, tests, results, accessibility data, and some delivery behavior. It does not assign responsibility for candidate identity, access control, monitoring, incident response, or records retention. The assessment host and the institution must define those responsibilities.
Separate the delivery responsibilities
An assessment can be structurally valid QTI and still fail operationally. Keep the boundary between portable content and delivery controls clear before you evaluate a product or design an integration.
The same organization can own more than one responsibility, but the operating agreement should name one accountable owner for each one. Do not use a product feature list to assign those duties.
Control identity and access
An assessment launch needs to establish the candidate, course or program context, assessment assignment, and authority to begin or resume an attempt. Test each role that can view, start, submit, score, override, rescore, or export an assessment.
Use least privilege. An instructor who can review results may not need access to item answer keys. A support representative who can diagnose a launch failure may not need to see candidate responses. A delivery service should reject an attempt request that does not match the authenticated candidate, released assessment, and current policy.
For Learning Tools Interoperability (LTI) integrations, record the launch configuration, service scopes, key rotation owner, and offboarding procedure. Test access after an enrollment change, course copy, role change, dropped candidate, and expired link. The LTI Advantage implementation guide provides the integration context; it does not replace your institution’s authorization tests.
Release an approved, traceable assessment
Treat release as a boundary. Before candidates begin, capture which test, items, assets, scoring rules, accommodations, and operational policy apply. Keep that record immutable for active attempts.
If an author corrects an item after release, create a new version. Do not silently replace the content seen by candidates who already started. Define when the correction applies, how staff identify affected attempts, and whether a rescoring process is necessary. Keep the original candidate response and outcome alongside the later decision.
QTI packages can move assessment content between systems. Validate the package, its asset paths, stylesheets, custom interactions, and declared relationships before release. The QTI validation guide explains why XML, schema, semantics, accessibility, rendering, scoring, and interoperability require separate results.
Keep the authoritative state on the host
The candidate browser needs enough content and state to render an item and collect a response. Keep access policy, answer keys, scoring rules, deadline decisions, and the final attempt record on the host.
Define which event establishes an attempt, saves a response, accepts a submission, returns a score, or closes an attempt. Give each event a durable identifier. When a candidate retries after a timeout or reconnect, the service must distinguish a safe repeat from a different state change.
Test the following conditions with representative items and policies:
- Open the assessment in two tabs, then submit from the stale tab.
- Disconnect during a save, refresh the browser, and reconnect.
- Submit twice because the candidate did not receive a response.
- Submit at the deadline while many other candidates submit.
- Restart the browser after a saved response and restore the attempt.
- Correct an item or answer key after an attempt has started.
- Review a disputed score without changing the original response record.
Record the expected result before the test. A demonstration that shows a successful submission does not prove how the system behaves during a failure.
Preserve candidate access during recovery
Recovery has technical and academic consequences. A system may restore the last saved answer, accept a late submission under a policy, reopen an attempt, or require staff review. Define those outcomes in advance and show candidates what happened.
Test browser storage and server-side state separately. Browser storage can improve recovery from a connection loss, but the institution still needs a server-side record that can resolve duplicate requests, browser changes, and support cases. Test a new browser, a cleared browser profile, and a device change if your policy permits candidates to use them.
Give candidates a receipt after a material action such as final submission. Give staff an event trail that answers when the candidate started, saved, submitted, received a result, or encountered an error. Do not expose other candidates’ data, internal secrets, or answer information in either record.
Deliver accommodations in the released workflow
Accessibility and accommodations are delivery requirements. Test them in the same launch, navigation, save, review, and submission flow that candidates use. A component demonstration cannot establish that the complete assessment process works.
Test representative candidate preferences, additional time, breaks, keyboard operation, screen-reader name and state, error feedback, zoom, contrast, and media alternatives. QTI 3 includes accessibility and Personal Needs and Preferences structures, but the delivery host must apply them correctly. WCAG 2.2 also evaluates complete processes, not isolated screens.
Keep private accommodation information out of portable QTI content and limit access to the staff and services that require it. Document where each preference is stored, who can change it, and how a change affects an active attempt.
Plan for incidents and result challenges
Define the incident process before a high-consequence assessment. Name who detects a problem, who decides whether to pause or continue, who communicates with candidates, and who approves a correction or rescoring decision.
For every material incident, preserve the assessment version, candidate state, service status, staff actions, and final decision. Keep the original score when a later correction produces a different outcome. A candidate, reviewer, or auditor should be able to understand the event without reconstructing it from informal messages.
Test the process with a tabletop exercise and a representative recovery scenario. Include a content error, an integration outage, a candidate-specific accommodation issue, and a delayed submission. The goal is to verify responsibilities and evidence, not to simulate every possible attack.
Request evidence with the right scope
Ask suppliers and internal teams for evidence that matches the claim. A certification record, a validation result, a load test, an accessibility report, and an incident exercise answer different questions.
Request the following materials for the exact product version and deployment model under review:
- An architecture diagram showing identity, launch, delivery, scoring, storage, monitoring, and support boundaries.
- A support matrix that distinguishes implemented, tested, partial, unsupported, and externally verified capabilities.
- Representative QTI packages, expected scoring outcomes, and import or delivery results.
- A release record that ties item revisions, assets, policy, and approval to the candidate experience.
- Recovery test results for disconnects, duplicates, browser restarts, deadlines, and service restoration.
- Accessibility test results for representative item families and candidate workflows.
- Security and authorization test evidence, including administrator and support roles.
- Incident, correction, rescoring, data-export, and retention procedures.
Verify current certification independently. 1EdTech’s QTI conformance and certification information identifies the official program; it does not establish that a different product, release, profile, or deployment is certified.
Set acceptance criteria before procurement or launch
Write acceptance criteria that name the content, candidates, policies, integrations, environments, and failure cases you will test. Use your institution’s real items and roles. Define who can approve an exception, how long it may remain open, and what happens if a material check fails.
Use the secure assessment delivery acceptance test plan to prepare the evaluation. For product-specific implementation and recovery details, review QFlowLearn’s assessment delivery documentation. Test any product against your institution’s own acceptance criteria.
