Audit logs capture authentication events, authorization and privilege changes, and user and administrator actions.

Logs are encrypted and held in immutable storage with MFA-restricted access, and can be exported on request.

Onebox supports single sign-on for end users, authenticating against the customer's identity provider via SAML 2.0.

Administrators authenticate through OAuth against Onebox's internal authentication service.

2FA is enforced across product and administrator access. TOTP authenticator apps are supported natively, and FIDO2 / WebAuthn is available where contractually required.

For customers not using SSO, password complexity is configurable: minimum length, mixed case, digits and symbols.

Passwords are never stored in plaintext. Resets are issued as time-limited tokenised links, and privileged account resets require an approval workflow.

Sessions time out after a period of inactivity and require re-authentication. The timeout is configurable per tenant within defined security limits.

All API endpoints apply server-side input validation and sanitisation. Error messages shown to users are generic, while full detail is written to the audit log.

Onebox does not access or collect device location or GPS data. No current or planned features require this permission.

Onebox mobile apps are distributed only through the Apple App Store and Google Play Store, published under the Onebox Ibérica account.

Production databases are backed up daily with automated, encrypted snapshots, replicated across two AWS availability zones for redundancy.

Backup restoration is tested twice a year to confirm data can be recovered as expected.

Customer data stays available for export for 90 days after contract termination. After that window, it is permanently deleted from production and backup systems.

The same 90-day notice applies in the event of business discontinuation.

Customers retain full ownership of their data, inputs, outputs and metadata, as set out in the Master Service Agreement and DPA.

These ownership rights hold even through an acquisition or bankruptcy event.

Customers can export their data, in full or in part, directly from the product interface in CSV format, without contacting Onebox.

Data is encrypted at rest with AES-256 (AWS KMS) and in transit with TLS 1.2 or higher, across all data stores and backups.

Access to production data follows least privilege. Every access is authorised and logged.

Onebox is a multi-tenant platform. Each customer's data is logically separated at the application and database layer through tenant-scoped access, with network segmentation between environments.

Staff and third-party access to internal tools and infrastructure follows role-based permissions, with separation of duties between security administration, system administration and standard user functions. Privileged operations require an explicit role assignment.

Access is reviewed annually across the organisation, and quarterly for systems handling confidential data.

Access is revoked immediately on role change or termination.

Cryptographic keys are generated, rotated and revoked through AWS KMS, with customer-managed keys available on request. AWS never has access to plaintext key material.

Application secrets are stored separately in Infisical, with access restricted by least privilege.

Onebox staff and third parties do not access institutional personal data as part of routine operations.

Access and configuration changes are logged centrally through AWS CloudTrail and the application's own audit logs.

Access and actions performed across the platform are continuously monitored by Lacework.

Processing is governed by GDPR and the Spanish LOPDGDD, with a Record of Processing Activities maintained throughout.

Full detail in the Privacy Policy.

A Data Processing Agreement is signed with each institutional client, with Standard Contractual Clauses available on request for any international transfer scenario.

Requests for access, rectification, erasure, restriction, portability or objection are handled through documented procedures, within statutory timeframes.

Privacy is built in by design: data minimisation, purpose limitation and privacy-friendly defaults apply across the data lifecycle. A Data Protection Impact Assessment has been carried out for the solution.

Onebox's own website uses cookies for session management, preferences and navigation analytics, with a banner letting visitors accept, reject or configure them.

Full detail in the Cookie Policy.

The supervisory authority is notified within 72 hours of becoming aware of a breach, and affected individuals are notified directly where the risk to them is high.

Personal data is processed and stored within the EEA (AWS eu-west-1, Ireland), with no transfer to the US or China under normal operation.

Onebox does not process demographic, genetic or biometric data, and does not carry out automated decision-making with significant effects on individuals.

Onebox has appointed an external Data Protection Officer. Privacy-related questions can be directed to lopd-gdd@atico34.com.

Onebox applies contractual security clauses covering confidentiality, integrity, availability, data protection and traceability with every data-handling provider, in line with GDPR Article 28.

Subprocessors are vetted before onboarding. Customers are notified of any change as soon as Onebox is notified by the upstream provider.

Customers may run their own vulnerability testing and audits against their instance, under an agreed scope and rules of engagement.

Vendor contracts include liability clauses covering data-breach scenarios.

New vendors go through a security assessment before engagement, including evidence such as ISO 27001, SOC 2 or PCI DSS certification. High-risk vendors are reviewed annually.

Onebox's contractual terms for platform use are published in the Terms of Service.

Onebox is hosted on AWS, in eu-west-1 (Ireland), running on EKS with ALB and ECR.

AWS's own infrastructure holds an independently audited SOC 2 Type 2 report, available through AWS Artifact under the shared responsibility model.

The platform runs on a multi-AZ Kubernetes cluster with autoscaling and load balancing across availability zones.

Databases use read replicas and clustered storage for redundancy, targeting 99.9% availability per the underlying AWS SLA.

Infrastructure and application layers are monitored 24/7 via Lacework, CrowdStrike, AWS CloudWatch and Site24x7, with PagerDuty alerting and on-call rotation.

Live platform status: oneboxtds.statuspage.io.

All data at rest is encrypted with AES-256 through AWS KMS, using customer-managed keys.

Infrastructure changes are managed as code with Terraform and OpenTofu, applying hardening baselines. Every change goes through pull-request review before deployment.

Production runs as a separate environment from staging and development. Changes are tested in staging first, and direct access to production is limited to authorised personnel.

Business continuity and disaster recovery plans are documented, owned by the Security & Privacy team, and tested annually.

Backups are replicated across at least two availability zones.

Production infrastructure runs in a segmented AWS VPC, with Security Groups and Network ACLs enforcing default-deny rules between subnets.

Cloudflare adds a further layer of protection at the network edge.

Onebox follows a documented secure development lifecycle: requirements, secure design, code review, automated security testing, staging validation, controlled deployment and post-release monitoring, aligned with OWASP guidance.

Source code is scanned automatically for security issues before release, alongside dynamic testing against pre-production environments.

Dependencies are monitored continuously and flagged for review when outdated or vulnerable.

Onebox runs a public vulnerability disclosure programme through Bugcrowd, offering safe harbor for good-faith security research.

Secrets and credentials are managed in Infisical. Nothing is hard-coded or kept in plaintext.

Developers complete mandatory secure coding training aligned with OWASP guidance, with participation tracked.

Changes go through impact analysis, formal authorisation, staging tests and post-deployment validation, with rollback available. Emergency changes follow retrospective authorisation.

Code is version-controlled, with dependency monitoring in place to flag outdated or vulnerable components for review.