Security

Architecture principles

• Read what is needed, keep as little as possible. Detection works on live streams; what persists is the alert record and the clip the customer's retention policy allows.
• Tenant isolation. Each customer's video, alerts and users are logically separated. Cross-customer access is not a supported configuration.
• Detection, not identification. There is no facial recognition gallery to breach, because the platform does not build one.

Data protection

• Encryption in transit using current TLS, and encryption at rest for stored clips, alert records and configuration.
• Camera credentials and integration secrets held in a managed secret store, never in application code or client-side configuration.
• Least-privilege, role-based access for customer staff, with console actions recorded in an audit trail the customer can review.

Access control on our side

Administrative access to production is limited to named engineers who need it, protected by multi-factor authentication, and reviewed as roles change. Support access to a customer environment is granted for a defined purpose and revoked when that work is finished.

Deployment and change

Changes are reviewed before release and can be rolled back. Detection model changes are evaluated before they reach a customer environment, and a customer can request a documented evaluation in its own environment before a change is enabled.

Resilience and incident response

Alerting paths are monitored, and customer administrators are notified of degradations that would affect alert delivery. If an incident affects customer data, we notify the affected customer's named contacts with what is known, what is being done and what we recommend, and follow up in writing.

Customer responsibilities

Security of a deployment is shared. Customers control camera placement, signage and notice, who holds console accounts, how alerts are routed, and how long footage is retained. We support those decisions, and we will not configure a deployment that conflicts with a customer's stated policy.

Disclosures

Previzion publishes the commitments a buyer’s legal, IT and procurement reviewers ask for: what the system reads, what it retains, where it runs, and what it will not do. Those commitments live in the Privacy Policy, the Terms of Use and the architecture principles above.

Formal disclosure documents — the model evaluation summary, the data processing addendum and the subprocessor list — are available to customers and prospects under review. Request them at legal@previzion.ai.

Reporting a vulnerability

If you believe you have found a vulnerability, email security@previzion.ai with enough detail to reproduce it. Please give us a reasonable window to investigate before disclosing publicly. We do not pursue legal action against researchers who report in good faith, avoid privacy violations and do not degrade service.