The access question is bigger than who has a password. A cloud invitation, a recorder account and an integration can each keep working after another path is removed.
The idea in view · Planning diagram
Separate the permission record from the secret
- Role alias
- Approved purpose
- Permitted actions
- Approving owner
- Removal condition
- Verification reference
Map permissions to tasks
Separate live viewing, playback, export, configuration and user administration. Ask whether the equipment supports the intended role boundary. Where it does not, record that limitation for IT rather than describing all access as read only.
Make approvals traceable
Reference the authorized request and the person responsible for the grant. Use role or account aliases in broadly shared planning records. Set a review point for temporary supplier work so access does not continue simply because nobody remembered to remove it.
Verify removal
Have an authorized administrator remove expired access and confirm the result. Review linked cloud, recorder and integration accounts as separate paths. A changed local password does not necessarily revoke an independent cloud invitation.
Review the account lifecycle, not just today’s list
Record why each account exists, the approved task and the party responsible for reviewing it. Use the product’s supported roles and test important boundaries. A label such as “operator” can mean different things across camera, recorder and cloud systems. Keep any unsupported permission restriction visible to IT rather than describing the access as more limited than it is.
At supplier handover or staff departure, use the register to trace the separate paths. Ask the authorized administrator to confirm removal and retain the result. Do not put passwords into the same sheet to make the exercise convenient. The register explains authority and ownership; secret storage is a different function.
Register permissions by purpose and role
An access register connects a person or service role to an approved purpose, system and set of permissions. Viewing, exporting and administering are different capabilities. Record which are needed for the actual duty rather than treating access as one yes-or-no field. Include the approving owner and review or removal condition so another person can understand why the role exists.
Keep the register separate from credential storage. It should show authority and accountability without containing passwords, recovery codes or unrestricted camera links. Use role aliases and approved references in a general worksheet, with personal details held in the appropriate controlled system. The register should help an authorized administrator remove or review access, not make sensitive access easier for everyone who receives the document.
Reference context: ICO: surveillance data protection principles
Include service accounts and indirect routes
Review the paths used by integrations, installer tools, remote applications and management systems as well as named interactive users. Removing a person from one interface may leave a shared account or another route active. The responsible administrator should identify the supported method for reviewing effective access across the actual deployment.
For each service role, identify its owner, required permissions and dependency on the monitoring duty. A broad integration account should not be left unexplained merely because it is not used by a person. Conversely, changing it without a test may interrupt events or recordings. The access decision and the service consequence need to be considered together, with an approved change and verification process.
Reference context: Axis: device hardening guide
Make removal a verified action
A departure, contract exit or completed maintenance task should trigger the relevant access review. Record the requested removal, person authorized to implement it and verification result. A spreadsheet row marked inactive is not proof that the system permission was revoked. Check the relevant routes using the administrator's approved process.
Also verify that the intended remaining service still works. If a shared role was supporting several duties, removal may require a better role arrangement rather than keeping unnecessary access indefinitely. Retain the decision and result at an appropriate level of detail. Where the system cannot support the intended separation, record that limit and assess the supported options with the vendor and responsible owner.
A fictional review of an old installer account
A site review finds an installer account still active after a completed project. The register has no current owner or purpose for it. The administrator asks the business and technical owners whether any accepted maintenance duty still requires the account. The team does not assume either that it is malicious or that it is harmless.
If no continuing purpose is approved, the administrator removes the relevant access and checks for associated routes. The monitoring path is retested if it depended on the same role. The record shows the decision, removal and result without storing the password. The example illustrates a review process; it does not establish that every legacy account can be disabled safely without understanding the system dependencies.
Make the call
Which permission needs review?
| Situation | Decision to make | What to ask for |
|---|---|---|
| A reviewer can view and export | Whether both functions are approved | The installed role’s actual permissions |
| A temporary engineer account remains active | Whether the work still requires it | A review owner and removal check |
| A local account was revoked | Whether a cloud path still exists | A check of every relevant system |
Before you move on
- List access paths and task permissions.
- Record the approval owner and expiry or review point.
- Check removal across all relevant systems.
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
- Account alias
- Use a stable role or account alias, keeping credentials and unnecessary personal identifiers out of the general register.
- System
- Identify the actual device, recorder, platform or access path so removal in one interface is not assumed to cover every route.
- Approved task
- Describe the purpose and permitted actions, separating viewing, export and administration rather than recording access as one undifferentiated right.
- Approval reference
- Reference the authorized decision and role that approved it, especially for temporary support or a provider integration.
- Expiry or review
- State the actual expiry or review condition and assign an owner to departures, completed work and contract changes.
- Removal verified
- Record the supported revocation check and confirm any required remaining service still works after the permission change.
A worked example
Fictional review: an installer’s temporary cloud invitation remains active after a local account was disabled. IT closes the second path and records both checks.
| Account alias | System | Approved task | Approval reference | Expiry or review | Removal verified |
|---|---|---|---|---|---|
| Supplier-A | Video cloud | Maintenance only | REQ-01 | End of work | Pending |
Questions readers bring to this task
What else should you know?
Is the register proof that access is controlled?
It is evidence of the approval and review process, not proof the system enforces the intended role. Verify permissions through the installed client and have authorized staff test revocation. Keep the governance record and technical result together.
Link to this answer ↗Should the access register include passwords?
No. Keep secrets in the organization's approved secret-management process. The register should describe approved roles, permissions, owners and review decisions, using controlled references where necessary. Combining authority records and credentials makes the document more sensitive and harder to share appropriately.
Link to this answer ↗Do read-only users need to be listed?
They should be considered in the access review because viewing can still expose personal or operational information. Record the purpose and permitted scope proportionately. Do not assume read-only means public or that export and viewing permissions are identical on the installed system.
Link to this answer ↗Notes & sources
The worksheet contains no credentials. A register supports governance but does not prove the underlying permission controls work.
Reviewed October 27, 2026. The examples and worksheets are planning aids, not customer results or a statement of contracted service.
- Axis: device hardening guide
Manufacturer guidance on accounts, access, network boundaries and time settings; use your equipment vendor’s instructions.
- Axis: Camera Station hardening guide
Vendor-specific network exposure and segmentation guidance.
- ICO: surveillance data protection principles
UK surveillance guidance on purpose, retention, secure access and transparency. Guidance is under review; check it when making a decision.