Security architecture

Security on GLBNXT Platform is not a feature layer added on top of the infrastructure. It is built into the architecture at every level, from the physical data centre through to the application endpoints your team deploys. Every component in the platform stack operates within a security model designed to protect your data, your users, and your organisation's obligations to the people whose information you process.

This section explains how the GLBNXT Platform security architecture is structured, what controls are in place at each layer, and how the shared responsibility model defines the boundary between what GLBNXT manages and what your organisation is responsible for.

Defense in Depth

GLBNXT Platform applies a defense-in-depth approach to security. Rather than relying on a single perimeter control, multiple independent layers of security controls are applied across the platform stack. A failure or bypass at one layer does not compromise the security of the system as a whole, because additional controls are in place at every layer beneath and beyond it.

The security layers applied across the platform include physical infrastructure security, network isolation and access controls, identity and authentication controls, application-level access policies, secrets and credential management, audit and monitoring, and data protection at rest and in transit. Each layer is managed independently and assessed against the security requirements appropriate to its position in the stack.

Physical and Infrastructure Security

GLBNXT Platform runs entirely on EU-based infrastructure operated by data centre providers certified to recognised physical security standards. Physical access to the facilities hosting your environment is restricted to authorised personnel through multi-factor physical access controls. GLBNXT does not operate its own data centre facilities. It operates on infrastructure provided by certified European data center partners whose physical security posture is assessed as part of the GLBNXT vendor management process.

All compute, storage, and networking components that form your platform environment run within this physically secured infrastructure boundary. No workloads, data, or network traffic leave the EU at any point in the processing of your requests.

Network Security and Isolation

Every platform environment is deployed within an isolated network boundary. Network segmentation ensures that your workloads are separated from other platform tenants at the infrastructure level. Internal service communication within your environment is encrypted in transit. External access to your environment is routed through managed ingress points with configurable access rules.

Firewall policies, network access controls, and traffic routing for your environment are configured and maintained by GLBNXT. Outbound connectivity to approved external services is available and configurable for use cases that require integration with systems outside the platform. All inbound and outbound traffic is subject to the access controls and logging policies applied at the network layer.

Distributed denial of service protection is applied at the network boundary. Traffic anomalies that indicate potential abuse or attack are detected and mitigated at the infrastructure level before they reach your application workloads.

Identity and Authentication

Access to GLBNXT Platform is controlled through a managed identity layer that supports integration with enterprise identity providers. Single sign-on via SAML and OAuth is available for organisations using Azure AD, Okta, Google Workspace, or other compatible identity providers. Users authenticate through their existing organisational identity, and platform access is governed by the roles and policies configured for their account.

Multi-factor authentication is available and can enforced for all access to the platform and is strongly recommended for all user accounts. For environments using SSO, MFA is handled by the identity provider and applies the same policies as the rest of the organisation's access controls.

Service-to-service authentication within the platform uses platform-managed tokens that are issued, rotated, and validated by the platform identity layer. Application workloads do not handle service authentication credentials directly.

Role-Based Access Control

Access to platform components, data services, model endpoints, and administrative functions is governed by role-based access control policies configured for your environment. Each user account is assigned a role that define the resources they can access and the actions they can perform.

Role assignments are managed by your platform administrator through the platform console. The principle of least privilege applies to all role assignments: users and service accounts are granted access only to the resources they specifically require for their work. Roles are reviewed as part of the onboarding process and should be reviewed again whenever team membership or responsibilities change.

For a detailed guide to configuring and managing roles in your environment, see the Access Control and Identity section.

Data Protection

Data in transit between platform components, between the platform and your users, and between the platform and authorised external services is encrypted using TLS 1.2 or higher. Unencrypted communication is not permitted within the platform environment. Certificate management and renewal is handled by GLBNXT.

Data at rest and in transit within the platform never leaves the EU. Data residency guarantees are documented in your GLBNXT service agreement and data processing agreement.

Vulnerability and Patch Management

GLBNXT maintains responsibility for patching and updating all platform-managed components, including the operating systems, container runtimes, orchestration layer, database services, and platform application components that run within your environment. Security patches for critical and high-severity vulnerabilities in platform components are applied on an expedited basis following discovery and validation.

Patch management for application-layer components developed by your team, including custom code, application containers, and third-party libraries used within your workloads, is a responsibility of your development team. GLBNXT can provide guidance on vulnerability scanning and dependency management practices appropriate for your environment.

Penetration Testing and Security Assessment

GLBNXT conducts regular security assessments of the platform infrastructure, including penetration testing by independent third-party security specialists. Assessment findings are reviewed and remediated according to their severity. Summary findings from platform-level assessments are available to enterprise customers as part of the GLBNXT Trust Centre documentation.

If your organisation requires a penetration test of your specific platform environment, contact your GLBNXT contact to discuss the scope, process, and conditions applicable to customer-initiated security testing.

Security Incident Response

GLBNXT maintains a security incident response process that defines how platform-level security events are detected, contained, investigated, and resolved. The process includes defined responsibilities, escalation paths, and communication timelines for incidents affecting platform infrastructure and customer environments.

In the event of a security incident affecting your environment, GLBNXT will notify your organisation through the contact channels defined during onboarding within the timeframes required by applicable data protection regulation, including GDPR Article 33 notification obligations where a personal data breach has occurred or cannot be ruled out.

Your organisation maintains responsibility for incident response activities within the application layer, including investigating incidents that originate within your own application code, managing communications with your users and regulators, and fulfilling any notification obligations that arise from incidents within your sphere of responsibility.

Shared Responsibility Model

Security on GLBNXT Platform operates under a shared responsibility model. Understanding the boundary between GLBNXT's responsibilities and your organisation's responsibilities is essential for maintaining a complete and coherent security posture.

GLBNXT is responsible for:

• Physical infrastructure security

• Network isolation, firewall management, and DDoS protection

• Platform component patching and vulnerability management

• Encryption at rest and in transit for platform-managed data

• Secrets vault infrastructure and access policy enforcement

• Identity provider integration and MFA for platform access

• Security monitoring, alerting, and incident response for platform-level events

• Compliance certifications and audit evidence for the platform layer

Your organisation is responsible for:

• Role assignments and access control configuration for your team

• Security of application code and custom workloads deployed on the platform

• Patch management for dependencies and libraries within your application containers

• Data classification and handling policies for data processed by your applications

• User awareness and secure use of platform access credentials

• Compliance obligations specific to your industry, jurisdiction, and data processing activities

• Security review and governance of the AI applications and workflows you build and deploy

Neither party's responsibilities can substitute for the other's. A platform that is securely operated by GLBNXT but accessed through poorly managed credentials, or that runs well-secured infrastructure beneath poorly designed application code, does not achieve the security outcomes either party intends. The shared responsibility model works when both sides fulfill their obligations consistently.

For guidance on the compliance frameworks that build on this security architecture, see the Compliance Frameworks section. For guidance on configuring access controls within your environment, see the Access Control and Identity section.