Wiacom supports two distinct data-flow models. The appropriate model depends on the customer’s data governance requirements, existing infrastructure, retention policy, lawful basis, and data-minimisation requirements.
Both models are designed to support GDPR-compliant deployments when implemented with the appropriate contractual, technical, organisational, retention, consent, and security controls.
They differ in where personal data is held, which system acts as the primary system of record, and what responsibilities the customer assumes.
Wiacom is hosted primarily on Microsoft Azure and Google Cloud, with Amazon Web Services used where required for selected components or customer-specific deployments. These providers maintain independently audited security, privacy, and compliance programs, including ISO/IEC 27001, ISO/IEC 27017, ISO/IEC 27018, SOC 1, SOC 2, SOC 3, CSA STAR, PCI DSS, GDPR support programs, and other regional or sector-specific frameworks where applicable.
| Access Method | Notes |
|---|
| HTTPS REST API | Strong authentication required; source IP restrictions available |
| Scheduled exports | Periodic data exports to a customer-designated destination |
| Push to CDP / CRM | Real-time or automated push into approved external platforms on a configured schedule or trigger |
Data Available
The following data may be exposed, subject to the configured consent, legal basis, and deployment rules:
| Data Type | Notes |
|---|
| Email address, phone number, and other personal or profile-related details | Only where collected lawfully for access, service operation, or marketing, depending on the configured flow |
| Confirmed and non-confirmed registrations | Where a valid email was provided at sign-up |
| Sign-up date and return visit history | Visit frequency and loyalty indicators |
| Dwell time | Session duration per visit |
| Portal funnel stage | Stage reached in the registration journey |
| Email delivery and engagement | Open, click, confirmation, and delivery tracking |
| Traffic and behaviour analytics | Selected session and usage metrics |
| Custom metrics | Available where specifically configured for a deployment |
The platform does not expose raw guest names or email addresses in standard analytics views. Reports and dashboards are scoped according to the configured consent and data-processing rules for the deployment. Full PII export is available only through authenticated API or scheduled export, where permitted by the applicable consent and legal basis.
Who Holds the Data
In this model, Wiacom acts as a data processor on behalf of the customer. A Data Processing Agreement (DPA) governs this relationship.
The customer remains the data controller and retains rights over guest data, including export and deletion requests, subject to the agreed processing terms and applicable law.
Model 1 is designed for fast deployment and is typically the most suitable option for small and medium-sized customers that do not want to operate their own data platform, CRM, consent storage, or transactional messaging infrastructure.
It provides a ready-to-use operating model with standard Wiacom terms, consent flows, data-retention controls, and portal documentation. Default terms and conditions templates are available and have been reviewed by reputable professional legal advisers, although customers remain responsible for validating their final deployment, notices, and lawful basis according to their own jurisdiction and internal policies.
This model is available for deployments in multiple markets and is intended to provide broad operational coverage with minimal customer-side implementation effort.
This is a custom implementation available for customers with stricter data minimisation, data residency, or internal governance requirements.
In this model, Wiacom acts primarily as an integration and enforcement layer. Personal data is pushed directly to the customer’s own CDP, CRM, PMS, or another approved external system at the point of collection.
Wiacom retains only a unique pseudonymous user identifier and the technical data required for WiFi authentication, session control, reporting, SLA monitoring, security, and troubleshooting.
Pseudonymous identifiers may still be considered personal data where they can be linked back to an individual by the customer or another authorised system.
| Data Retained by Wiacom | Purpose |
|---|
| Unique pseudonymous user identifier | Cross-session recognition and credential linkage |
| Technical authentication credentials | WiFi access enforcement, including RADIUS, iPSK, or similar mechanisms |
| Session and connection metadata | Reporting, troubleshooting, SLA monitoring, and security analysis |
Customer Responsibilities
| Requirement | Detail |
|---|
| System of record | The customer’s platform becomes the primary store for personal data |
| External API availability | Customer APIs must be accessible from Wiacom infrastructure for real-time data push |
| Transactional messaging | The customer must provide their own email and SMS delivery services, including API credentials, delivery rules, templates, and compliance responsibilities |
| Data governance | The customer is responsible for managing personal data inside its own systems after transfer |
| Custom implementation | This model requires scoping and specific implementation work by the Wiacom team; it is not a self-service configuration |
Model 2 must be agreed and scoped with the Wiacom team before deployment. It cannot be applied retrospectively to an existing Model 1 deployment without data migration and deletion planning.
When to Consider This Model
This model is well suited for:
- Enterprise or public-sector customers subject to strict data localisation requirements
- Customers who already operate a consolidated CDP or CRM and want to minimise the number of systems holding personal data
- Deployments where a PMS, such as a hotel property management system, is the authoritative system of record for guest identity
- Organisations seeking to reduce the personal-data footprint across third-party processors
- Customers with internal policies requiring privacy-minimised architecture by design
Model Comparison
| Model 1 — Data Platform / Data Vault | Model 2 — Middleware |
|---|
| Personal data stored in Wiacom | Yes, with configurable retention; selected data can also be pushed externally | Minimal; pseudonymous identifiers and technical data required to operate the service |
| System of record | Wiacom, or customer system if push-based configuration is used | Customer CRM / CDP / PMS |
| Transactional messaging | Wiacom-provided | Customer-provided |
| API / CDP push available | Optional | Required |
| Analytics and reporting | Full platform analytics available | Limited to pseudonymous and technical session data |
| Implementation type | Standard deployment | Custom scoping required |
| DPA with Wiacom | Required | Required, with reduced processing scope |
| Suitable for strict data minimisation | Partially | Yes |
