Data Flow Guide
This guide documents how data flows within Invisiq and what external network connections the product makes. It is intended to support network egress validation and data residency verification.
Principles
Section titled “Principles”Invisiq is designed with a data-residency-first approach:
- All customer data is stored in your own infrastructure.
- Enprivacy has no access to your data.
- Outbound internet connectivity is minimised to a single endpoint for user management.
Internal Data Flows
Section titled “Internal Data Flows”| Source | Destination | Data | Protocol |
|---|---|---|---|
| Application | Database | Application data | TLS (internal) |
| Application | Object storage | File uploads | TLS (internal) |
External Connections
Section titled “External Connections”The product makes the following outbound connections to external services:
| Destination | Port | Protocol | Purpose | Data transmitted |
|---|---|---|---|---|
auth.enprivacy.com | 443 | HTTPS | User authentication and entitlement | User identity (email, user ID, roles) |
No customer data is transmitted to Enprivacy or any other external party.
What Is Sent to auth.enprivacy.com
Section titled “What Is Sent to auth.enprivacy.com”No Telemetry or Update Checks
Section titled “No Telemetry or Update Checks”The product does not phone home to check for updates or send telemetry. All features (except user authentication) work fully air-gapped.
Data at Rest
Section titled “Data at Rest”See Data Security & Privacy for details on where data is stored and encryption recommendations.
Egress Validation
Section titled “Egress Validation”You can validate the product’s network egress by:
- Deploying with a network egress proxy or firewall logging enabled.
- Allowing only
auth.enprivacy.com:443in your egress allow-list. - Blocking all other outbound traffic and verifying that no application features break (except authentication).