Security
How we build, run and protect the Xbrandify platform, and what your team can expect from us. Practices, described plainly.
This page is maintained by Your Brand Travel International AB, the company behind Xbrandify, to answer common security and privacy questions about the platform. It describes our practices. It is not a certification, an audit report or an independent attestation. Security is a shared responsibility: we secure the platform, our customers secure their own accounts, users and content, and both sides rely on the commitments set out in our written agreements.
Hosting and infrastructure
The platform runs on managed cloud infrastructure rather than self-managed hardware, so patching, physical security and network hardening at the infrastructure layer are handled by the hosting providers we use.
Hosting providers and primary data residency: [TO CONFIRM: hosting providers and regions].
Encryption in transit and at rest
Traffic between browsers, our services and our data stores is encrypted in transit using TLS. Data stored in our managed databases and object storage is encrypted at rest by the underlying platform.
Minimum TLS version enforced and cipher policy: [TO CONFIRM: TLS policy].
Access control and least privilege
Internal access to production systems and customer data is restricted to the people who need it to run and support the service, and is granted on a least-privilege basis by role rather than by default.
Access is reviewed and removed when someone changes role or leaves. Review cadence: [TO CONFIRM: access review cadence].
Authentication
Customer users sign in through our managed authentication layer. Credentials are stored as salted hashes by that layer, never in plain text, and sessions are issued as signed, expiring tokens.
Available options such as single sign-on and multi-factor authentication, and where they are enforced: [TO CONFIRM: SSO and MFA availability and enforcement].
Tenant isolation and row-level security
Each customer's data is logically separated. Database access is governed by row-level security policies, so a request can only read or write rows that belong to the authenticated tenant and user, and authorisation is enforced in the database rather than only in application code.
Privileged, policy-bypassing database access is limited to specific server-side operations and is not available to browser code.
Secrets management
API keys, tokens and other credentials are stored as managed secrets and injected into server-side code at runtime. They are never committed to the codebase and never shipped in client-side bundles. Calls to third-party services that require a secret are made server-side only.
Secret rotation practice: [TO CONFIRM: secret rotation process].
Logging and monitoring
We collect application and infrastructure logs, along with error reports, so we can detect failures and unusual activity and investigate what happened. Logs are kept separate from customer-facing surfaces and access to them is restricted.
Log retention and alerting thresholds: [TO CONFIRM: log retention and alerting].
Backups
Customer data held in our managed databases is backed up by the underlying platform so that we can recover from loss or corruption. Restores are performed by authorised personnel only.
Backup frequency, retention and recovery objectives: [TO CONFIRM: backup frequency, retention, RPO and RTO].
Vulnerability management
We keep dependencies current, review code changes before they reach production, and run automated scanning over our codebase and dependencies to surface known vulnerabilities. Issues are triaged by severity and fixed through our normal release process, with urgent fixes shipped out of band.
Remediation targets by severity, and any external testing: [TO CONFIRM: remediation SLAs and penetration testing cadence].
Subprocessor due diligence
We keep the number of providers with access to customer data deliberately small. Before a provider processes personal data on our behalf we assess it, put a written data processing agreement in place, and confirm an appropriate transfer mechanism where data leaves the European Economic Area.
The current list is maintained in our Privacy Policy: [TO CONFIRM: full subprocessor list].
Incident response and breach notification
We have an internal process for detecting, triaging, containing and resolving security incidents, and for recording what happened and what we changed afterwards.
Where we act as processor for guest data, we notify the affected customer as controller without undue delay after becoming aware of a personal data breach, with the information they need to meet their own obligations. Under Article 33 of the GDPR, the controller must notify the competent supervisory authority within 72 hours of becoming aware of a notifiable breach, and our notification is designed to support that deadline. In Sweden the supervisory authority is Integritetsskyddsmyndigheten (IMY).
Customer notification channel and escalation path: [TO CONFIRM: notification process].
Responsible disclosure
If you believe you have found a security vulnerability in our platform, we want to hear about it. Please report it to us privately, with enough detail for us to reproduce the issue, and give us reasonable time to investigate and fix it before any public disclosure.
Please avoid testing that degrades the service, and do not access, modify or retain data belonging to others. We will acknowledge your report and keep you updated while we work on it.
Reports: [TO CONFIRM: security contact email]
Need more detail for a security review?
Enterprise customers and prospects can request additional documentation, including our Data Processing Agreement, our subprocessor list, hosting and data residency details, and answers to your own security questionnaire. Tell us what your review needs and we will work through it with you.