Security Policy

HOSTELELLA applies reasonable technical and organizational measures appropriate to the risk to protect the confidentiality, integrity, availability and resilience of the Service. This policy summarizes the main measures without disclosing details that could weaken security.

1. Governance and access

• Internal access limited by need, role and least privilege.
• Use of individual accounts and permission control for critical systems.
• Strong authentication/MFA for administrative accounts where the provider or system allows.
• Reasonable access reviews and removal of permissions when no longer needed.
• Logical separation between development, testing and production environments where appropriate.
• Change and deployment management with technical review proportionate to risk.

2. Data protection

• Encryption in transit via HTTPS/TLS.
• Encryption at rest where provided by the cloud infrastructure or managed service.
• Secrets management via secure stores and server variables, avoiding client-side exposure.
• Data minimization in telemetry, logs and support processes.
• Clock-in presence verification (where enabled by the business): device coordinates are processed ephemerally on the server and are never stored or logged; only the result (inside/outside) and the approximate distance are kept.
• Logical separation per customer/business via authorization controls and data policies (RLS) where applicable.
• Limited access to production data for support, diagnostics or security when necessary.

3. Application and API

• Authentication via identity provider and tokens.
• Access validation at the gateway/API layer and authorization controls by user, business and role.
• Database policies and logical segmentation to reduce exposure between customers.
• Rate limiting, anti-abuse controls and input validation on sensitive endpoints.
• Protections against automated abuse on sensitive public flows, including captcha where appropriate.
• Full card details are captured and held in Stripe components; HOSTELELLA does not store PAN or CVC.
• Cryptographic validation of payment webhooks, idempotency and event reconciliation to reduce impersonation and duplicate processing.
• External-purchase reporting tokens encrypted at rest, secrets in a secure store and non-reversible HMAC fingerprints to prevent token reuse or trial abuse.
• Reasonable review and remediation of vulnerabilities in dependencies, infrastructure and own code.

4. Communications and preferences

• A single server-side component decides whether an optional communication may go out. Its default behaviour is to deny: if the template classification, the purpose, a valid consent or the suppression check is missing, nothing is sent.
• The decision is taken twice: when the message is prepared and again immediately before it is handed to the email provider, so that an opt-out that happens in between always wins.
• Every email template is registered and classified as necessary or optional. An unknown or mis-classified template is blocked.
• The suppression list stores an HMAC-SHA256 fingerprint of the address, with the key held in the secret store and never in code or on the client. The address itself is not stored in clear text in that list.
• Unsubscribe links use a high-entropy random identifier, bound to a single recipient and expiring. They never contain the email address or phone number, do not allow redirection to external destinations, and are rate limited.
• The public unsubscribe response is idempotent and does not reveal whether an account exists.
• The user identifier, their business and their role are always derived from the session token on the server: the client cannot send or alter them.
• Communications telemetry never records email addresses, phone numbers, subjects, content or tokens.

5. AI processing and minimization

6. Operations, monitoring and continuity

• Technical monitoring and activity logs to detect errors, abuse or incidents.
• Backups and recovery mechanisms according to the applicable managed service.
• Reasonable internal recovery and continuity objectives, dependent on the cloud provider and contracted plan.
• Incident response process and assessment of personal data breaches.
• Maintenance and updates for security, stability and compliance.
• Logging of critical security events and retention in accordance with the Retention Policy.

7. Reasonable limitations

This policy summarizes security controls without disclosing details that could weaken the Service. Measures may vary by environment, plan, managed provider and risk. No system is absolutely secure; HOSTELELLA will maintain appropriate and proportionate measures, but the Customer must apply its own internal controls.

8. Sub-processors

HOSTELELLA selects providers that offer adequate security measures for the purpose of the processing. The main sub-processors are published in the Sub-processors Annex.

9. Jurisdiction and international governmental access

The jurisdiction of the infrastructure for each service is identified in the Sub-processors Annex. For non-personal data held in the Union, HOSTELELLA applies legal review of third-country authority requests, response minimization, access controls and encryption where appropriate; it will reject or challenge requests conflicting with Union law where there are reasonable grounds and notify the Customer where legally permitted. Providers will be subject to equivalent commitments to the applicable extent.

10. Customer responsibilities