Customer-controlled access
Your organization approves the systems, roles, methods, and operating boundaries used for service delivery.
Security / Access architecture
Access is earned.
Not assumed.
Remote operations require trust—but trust should be implemented as scoped permissions, attributable identities, approved connectivity, and explicit authorization.
01Reference architecture
Customer-controlled
at every layer.
The exact technical path depends on the customer environment. The principles do not: approve the connection, identify the person, require strong authentication, restrict the role, and preserve accountability.
01
Customer environmentSystems remain customer-owned
02
Approved access layerCustomer-selected connectivity
03
Identity + MFAIndividual, attributable access
04
Authorized operationsRunbook-scoped permissions
05
Audit trailAvailable session and action records
02Access principles
Individual identities
Access should be attributable to a person—not shared through unaccountable, generic operator credentials.
Multi-factor authentication
MFA is expected wherever the customer platform and approved access architecture support it.
Least privilege
Permissions are scoped to the responsibilities in the contract and runbook, not unrestricted by default.
Approved connectivity
Remote access uses customer-approved methods such as secure tunnels, identity-aware access, or managed platforms.
Session accountability
Operational access and significant actions should be traceable through available platform and workflow logs.
Credential handling
Credential storage, rotation, sharing restrictions, and recovery procedures are defined around the approved customer platform.
Change authorization
Actions that can affect production systems follow the approval boundaries established in the contract and runbook.
Access revocation
Offboarding and role changes include removing identities, sessions, tokens, and permissions that are no longer required.
Data minimization
Only the operational data and system access needed for the contracted responsibility should be available to the service.
03Video data handling
Access does not imply
automatic retention.
Video viewing, event access, export, retention, and deletion depend on the customer system, platform configuration, and contracted scope. The access model should minimize exposure and make permitted handling explicit.
The same principle applies to network data: collect and expose what is necessary to operate the responsibility assigned—nothing more by default.
04Claims discipline
Principles before
badges.
The operating model is designed around least-privilege and auditable access principles. This website does not present unverified compliance certifications, security awards, or universal platform guarantees.
Where a customer has specific control, audit, insurance, legal, or compliance requirements, those requirements belong in the assessment and contract review.
Security and access review
Define access before granting it.
Bring your identity, remote-access, logging, change-control, and revocation requirements into the operating design.
Discuss your access model