Security and Data Architecture

1. Architecture overview

Visentry processes camera and event data from customer-authorized sources such as Ring through authenticated application services and camera-processing components. Web users authenticate through Keycloak; Django enforces role, workspace, and object-ownership controls.

Production components are separated at the network level. The application, database, identity provider, and camera-processing services communicate only through the interfaces required for their functions.

2. Data storage locations and systems

The systems below show the primary data locations in the Visentry production architecture. Visentry may support Customer-managed/on-premises and managed deployments. The actual provider, country/region, backup location, and cross-border support-access points for the database and media are identified in the order form or data-residency schedule before production activation.

This general page does not promise AWS Frankfurt, Türkiye, or any other region for a particular deployment. No location is guaranteed unless it is written in the Customer documentation. A region change is subject to the transfer assessment and contractual notice process.

Ring OAuth access and refresh tokens are encrypted at application level with Fernet. Temporary Ring video content used for processing is cleared after the job completes.

3. Data flow between systems

Data flows only within the connection initiated by the customer and for configured security features. Results are not transferred to a shared customer pool or an AI model-training dataset.

4. Security in transit and at rest

Public web, OAuth, and external service traffic is transported over HTTPS/TLS. Ring OAuth tokens are stored using authenticated Fernet encryption. Encryption keys and Ring client credentials are supplied as deployment secrets and are not committed to source control.

PostgreSQL and media data use isolated persistent volumes. Storage encryption at the disk or volume layer depends on the production hosting configuration; Visentry does not claim separate application-level encryption for every database and media record where that hosting control is not enabled.

5. Access control and audit

• Keycloak-based authentication and role-based application permissions.
• Customer separation through workspace, ownership, and object-level checks.
• Authenticated and permission-controlled media endpoints.
• Timestamped audit entries for administrative and authenticated application changes.
• Integration-job, processing-status, and error records.

6. Backups, security testing, and assurance boundaries

Persistent volumes support infrastructure-level backup. Backup frequency, encryption, retention, restore testing, RPO, and RTO are configured for each production environment and documented contractually. A backup is not represented as available unless it has been enabled and verified.

Visentry uses code review, authorization and tenant-isolation tests, and dependency updates. Visentry does not currently claim completion of an independent penetration test or possession of a SOC 2 or ISO 27001 certification.

7. Retention, account deletion, and incident response

A user can initiate irreversible account deletion from account settings. The process deletes the Keycloak identity and user-associated Ring tokens, cameras, locations, person records, photos, alerts, and event media. The last owner of a workspace with other members must assign another owner first.

Suspected security incidents are assessed for scope and impact, contained, remediated, and validated for recovery; affected credentials are rotated where appropriate. Affected customers are notified without undue delay in accordance with applicable law and contract.