A feed playing on a laptop is a useful start. Acceptance asks a longer question: can an agreed event travel through the service and reach the person who must own it?
The idea in view · Planning diagram
A working feed is the first check
- Useful view
- Required event
- Event received
- Human review
- Accepted handoff
- Usable record
Test the complete path
A playable feed does not prove the alert reaches a reviewer. Start with an authorized movement in a covered area and follow the resulting record through to a safe test contact. Record timestamps and the camera alias at each stage.
Include adverse conditions
Repeat important routes after dark and during normal deliveries. Include a simulated missing feed and unavailable test contact using provider-approved methods. Agree a stop signal before testing and ensure nobody mistakes the exercise for a real incident.
Make sign-off conditional
Attach failed tests, owners and retest results. Define which failures block activation and which views are excluded temporarily. Retest after a material camera, firmware, lighting or rule change rather than assuming the original acceptance still applies.
Keep a failed test useful
Give each scenario its own identifier and keep the expected action beside the observed result. “Camera failed” is too broad to guide a repair. “Person visible in playback but no event received for the north-gate walk” identifies a stage to investigate. Keep the original record even after a successful retest so the approval has a history.
Agree the test conditions with the people responsible for site safety and monitoring. Use authorized participants, an explicit exercise window and test contacts. Suppress any real dispatch only through the provider’s approved exercise procedure. If a scenario cannot be exercised without affecting live duties, record the limit and find an agreed alternative rather than improvising.
Write acceptance criteria in terms of the task
Acceptance is the point where evidence supports a defined duty. Start with what the view must allow the reviewer to do, the conditions in which it must work and the record that demonstrates the result. A camera displaying live video proves a connection at that moment. It does not establish useful nighttime detail, correct event delivery, a working fallback or an incident report that the business can use.
Create separate checks for visibility, event behavior, review, contact and reporting. Keep their owners distinct where different parties control them. The installer may supply the view, IT may supply connectivity and the monitoring provider may accept the review duty. The business must decide whether the combined result meets its requirement. Avoid asking one party to sign for another party's untested responsibility.
Test normal activity and exceptions
Use safe, authorized scenarios that reflect real routes and lighting. Confirm that expected activity can be understood in context and that a defined exception follows the intended path. Include a moving person or vehicle where relevant rather than judging an empty scene. Record the camera alias, rule version and conditions so the test can be understood after the equipment or site changes.
A useful acceptance plan also tests degraded conditions. What happens if the view is blocked, the event does not arrive or the first contact does not answer? The desired result may be a correctly reported gap and an authorized fallback rather than normal service continuing. The test should establish that the failure is handled as agreed; it should not hide the failure or pretend an unavailable view still provides coverage.
Reference context: Axis: Object Analytics manual
Use conditional acceptance carefully
Some defects may allow a limited duty to begin while others prevent reliance altogether. Record the accepted part, the excluded condition, the temporary arrangement and the owner authorized to accept it. A broad signature beside a list of unresolved defects can leave the operating team uncertain about what it may rely on. Make the condition visible in the live scope and instructions.
Set a closure test for each material issue. Replacing a camera, changing a rule or improving lighting is an action; it is not the acceptance result. Repeat the relevant scenario and retain the observed outcome. Where the system changes after acceptance, identify which tests need to be rerun. A previous successful result belongs to its tested configuration and conditions, not every later state of the site.
A fictional test that distinguishes three failures
A staged walk reaches a restricted route. The recorder contains usable footage, but the monitoring platform has no corresponding event. That narrows the investigation toward configuration or event delivery rather than proving that the reviewer overlooked an alert. On another view, an event arrives but the moving person is indistinct after dark. That is a different visibility problem. On a third, review succeeds but the contact cannot acknowledge the action.
Keep separate test records and owners for these outcomes. The first needs the event path investigated, the second needs image conditions assessed and the third needs the response plan tested. A single failed-test label loses that distinction. Once each issue is addressed, repeat the relevant path before changing the acceptance status. The worksheet should show the evidence for closure and the exact duty that has been accepted.
Make the call
Choose the result before the test
| Situation | Decision to make | What to ask for |
|---|---|---|
| Video appears but no event is delivered | Whether the end-to-end task passed | Separate video and event results |
| The day test passes and the night test fails | Which hours can be accepted | A limited scope or corrected night retest |
| The call was attempted but not answered | Whether ownership transferred | An acknowledgement record or a failed handoff |
Before you move on
- Agree expected results and test safety controls.
- Run each scenario and retain its incident or fault reference.
- Approve only the scope supported by the results.
A worksheet you can actually use
Start with the blank sheet. Add one row per item, assign an owner and mark anything unresolved as pending. The completed example shows the level of detail to aim for.
Keep completed security plans private. Use aliases; keep passwords, access codes, personal contacts and footage links in your approved systems.
How to fill the worksheet
- Test ID
- Use a unique reference that can connect the scenario, evidence, correction and later retest without mixing different results.
- Scenario
- Describe safe authorized activity that exercises the actual duty, including relevant normal and degraded conditions.
- Expected result
- State the observable completion criteria before testing so a partial result cannot silently become a full pass.
- Evidence reference
- Link to evidence in the approved system. Do not embed private footage links or credentials in a general acceptance sheet.
- Pass or fail
- Record the actual outcome and any condition. A useful video feed is not a pass for untested event or response duties.
- Retest date
- Record the planned relevant verification and owner after correction, keeping the duty pending until its acceptance decision.
A worked example
Fictional acceptance: the north gate passes in daylight but fails after dark. The gate is excluded from accepted night coverage until lighting is corrected and the route retested.
| Test ID | Scenario | Expected result | Evidence reference | Pass or fail | Retest date |
|---|---|---|---|---|---|
| T01 | Night gate walk | Alert reviewed and test contact reached | To complete | Pending | To agree |
Questions readers bring to this task
What else should you know?
Who should sign off the results?
The site’s authorized decision owner and the parties responsible for the tested service should review them. Keep unresolved exclusions visible. The commissioning guidance in the SCC buyer toolkit supports agreeing requirements and acceptance; your final sign-off must still reflect the actual service and local obligations.
Link to this answer ↗Who signs off acceptance?
The parties responsible for the requirement, technical system and monitoring duty should accept their respective parts. The business owner makes the final reliance decision with the relevant evidence. A technician's completion note should not be treated as acceptance of an untested response arrangement.
Link to this answer ↗Is daytime testing enough?
Only for a duty genuinely limited to the tested daytime conditions. After-hours monitoring needs relevant dark, lighting and operational checks. Where conditions cannot yet be tested, record the limitation and keep the affected duty conditional rather than assuming that a daytime result transfers.
Link to this answer ↗What should happen after a failed test?
Record the observed boundary, preserve the relevant evidence, assign the corrective action and define the retest. Keep the affected requirement pending or explicitly limited until an authorized decision is made. A failure is useful information when it leads to a clear correction and verified result.
Link to this answer ↗Notes & sources
These proposed tests are not an accredited certification or a guarantee against loss.
Reviewed October 27, 2026. The examples and worksheets are planning aids, not customer results or a statement of contracted service.
- Surveillance Camera Commissioner: Buyers Toolkit (2018)
Historical operational requirements, commissioning and handover context; not current legal advice or certification.
- ProtectUK: CCTV operational checklist (2022)
Operational prompts on purpose, coverage, lighting and review. Its historical legal references are not used as current law.
- GOV.UK: police requirements for CCTV systems
Purpose, quality, storage, export and playback considerations; not a promise of police response.
- Axis: Object Analytics manual
Manufacturer guidance on scenes, filters and detection limitations. Not evidence of NightMarshal detection performance.