Skip to main content

Privacy & Data Governance Levels (V9 Enterprise)

Why this exists​

In most people-counting systems, “privacy” is described as a static product claim.
In V9 Enterprise, privacy is a governance decision.

We deliberately separate:

  • What the platform is capable of
  • What the customer chooses to enable
  • What is technically enforced and auditable

This section introduces the Privacy & GDPR Compliance Levels—a structured, selectable framework that allows enterprise customers to negotiate, document, enforce, and audit their chosen privacy posture over time.

This is designed for:

  • CIOs / Heads of IT
  • Security & Compliance teams
  • DPOs and enterprise architects
  • Executive stakeholders signing off DPIAs and procurement

Design principles (executive summary)​

  1. Privacy by architecture, not promises
    Enforcement is built into system domains, not left to operational discipline.

  2. Selectable but non-bypassable
    Customers can choose a level—but once selected, it is technically enforced across all modules.

  3. Audit-first, not incident-driven
    Every privacy-relevant change is logged, immutable, and reviewable.

  4. GDPR-aware, not GDPR-dependent
    Higher levels are explicitly designed to be outside GDPR scope by construction.

The Five Privacy Levels (reversed model)​

note

In V9, Level 5 is the safest, and Level 1 is the most permissive.
This inversion is intentional and signals risk clearly at executive level.

Level 5 – Fully Anonymous (GDPR-Exempt by Design)​

Intended for:
Airports, public infrastructure, government buildings, privacy-critical retail, legal-risk-averse enterprises.

What this means:

  • No personal data is collected, processed, or stored
  • No identifiers, no signals, no re-identification vectors
  • Data cannot be combined with any external dataset to identify individuals

Allowed

  • Aggregate people counts
  • Directional flows
  • Time-based totals (hour/day/week)
  • Occupancy thresholds

Not allowed

  • Wi-Fi
  • Bluetooth
  • Device fingerprinting
  • Image retention
  • Path reconstruction
  • Any identifier persistence

Compliance posture

  • Designed to be outside GDPR scope
  • No DPIA required in most jurisdictions
  • Minimal compliance burden

Level 4 – Anonymous with Ephemeral Intelligence (GDPR-Exempt)​

Intended for:
Enterprises needing operational insight without privacy exposure.

What this means:

  • Short-lived, non-persistent signals may exist in memory
  • No storage of identifiers
  • No cross-time or cross-location linkage

Allowed

  • Real-time queue length
  • Live occupancy alerts
  • Temporary path smoothing (non-persistent)
  • On-device only processing

Not allowed

  • Persistent IDs
  • Historical path replay
  • Wi-Fi / BLE storage
  • Cross-store or cross-day linkage

Compliance posture

  • Still GDPR-exempt by architecture
  • Signals are mathematically non-recoverable once expired

Level 3 – Pseudonymous Analytics (GDPR-Scoped)​

Intended for:
Retail analytics teams balancing insight and compliance.

What this means:

  • Pseudonymous identifiers exist
  • Identifiers are rotated, salted, and non-human-readable
  • No direct identification, but GDPR applies

Allowed

  • Path analytics
  • Dwell time
  • Zone transitions
  • Limited retention windows

Restricted

  • No raw image access
  • No long-term identifier reuse
  • No external data joins

Compliance posture

  • GDPR applies
  • DPIA typically required
  • Strong internal controls needed

Level 2 – Enhanced Signals (GDPR-Scoped, Higher Risk)​

Intended for:
Advanced analytics, R&D pilots, controlled environments.

What this means:

  • Additional sensing modalities may be enabled
  • Stronger governance required

Allowed

  • Wi-Fi (hashed, salted)
  • Bluetooth (configurable)
  • Extended retention (policy-bound)

Requirements

  • Explicit customer approval
  • Internal access control
  • Regular audits

Level 1 – Maximum Capability (Strict Governance Required)​

Intended for:
Very specific, legally reviewed deployments.

What this means:

  • Full platform capability is technically available
  • Strongest compliance obligations

Allowed

  • All sensing modules (subject to law)
  • Longitudinal analysis

Non-negotiable

  • Formal DPIA
  • Legal sign-off
  • Contractual safeguards
  • Continuous audit readiness

Enforcement model (this is the differentiator)​

Privacy levels are not labels. They are enforced through architecture.

Central Privacy Registry (separate domain)​

  • One registry per company
  • All entities inherit the same privacy level:
    • Devices
    • Sites
    • Floors
    • Analytics modules
    • APIs
    • Data exports

No module can override this locally.

Configuration & visibility​

What customers see

  • Current privacy level (read-only once locked)
  • Enabled / disabled capabilities
  • Effective date
  • Authority who approved it

What they can change

  • Only what is permitted within that level
  • Some settings are:
    • User-adjustable
    • Account-creation-only
    • Locked entirely

Audit trail (compliance-grade)​

Every privacy-relevant action is logged:

  • Privacy level selection
  • Changes attempted (allowed or rejected)
  • Module enablement (Wi-Fi, BLE, etc.)
  • Data access attempts
  • Export attempts
  • API access
  • Retention changes

These logs are:

  • Immutable
  • Timestamped
  • Attributable
  • Exportable for audit

This supports:

  • Internal audits
  • External auditors
  • Regulatory inquiries
  • Customer self-assurance

What this means for executives​

  • Privacy is a board-level choice, not a technical accident
  • Risk is visible, bounded, and documented
  • Enforcement is systemic, not procedural
  • Compliance evidence exists before it is requested

This is particularly relevant in people-counting, where perception risk often exceeds actual risk.