Trust

Security

A high-level summary of XYLEX security controls, vendor management, incident response, and shared responsibility expectations.

Last updated: March 2, 2026

This page is intentionally framed as a sober public overview. It does not claim certifications, attestations, or controls that are not separately documented in writing.

Security Program

XYLEX operates a security program intended to protect confidentiality, integrity, and availability across our services and internal operations.

Our controls are designed using a risk-based approach that takes into account the nature of the service, the sensitivity of data involved, the deployment model, and evolving threat conditions.

Program elements may include policy governance, access management, system hardening, secure change management, vendor oversight, monitoring, incident response, and continuity planning.

Access Control and Identity

Access to systems and data is intended to be granted on a least-privilege, need-to-know basis.

  • Access is limited according to role, operational necessity, and approval workflows appropriate to the environment.
  • Administrative access may be protected through strong authentication, logging, periodic review, and revocation procedures.
  • Customers remain responsible for access management within their own organizations, including user lifecycle controls and permission hygiene for their authorized users.

Application and Infrastructure Security

Security controls are applied across both the software lifecycle and the infrastructure used to deliver services.

  • Development workflows may include peer review, dependency management, change controls, and testing practices intended to reduce the risk of introducing vulnerabilities.
  • Production services are designed to use network controls, secrets handling, logging, patch management, and other safeguards appropriate to the environment.
  • We design services to use encryption in transit and, where supported by the relevant service stack, encryption for stored data and backups.

Monitoring and Incident Response

Operational telemetry and response procedures are used to detect, assess, and contain security events.

  • We may collect logs, alerts, and other system signals relevant to authentication, infrastructure health, abuse prevention, and suspicious activity review.
  • Incidents are triaged according to severity, potential customer impact, and legal obligations.
  • Where required, affected customers are notified through agreed channels after sufficient validation and containment work has begun.

Business continuity and restoration measures are summarized in our Data Recovery Policy.

Vendor and Subprocessor Management

Third-party vendors are used selectively and are expected to meet contractual security and confidentiality requirements appropriate to their role.

Infrastructure providers, communications platforms, observability tools, and other service providers may support service delivery. Where they process customer or personal data on our behalf, we expect written contractual terms that address confidentiality, data handling, and security obligations in a manner appropriate to the services they provide.

Shared Responsibility

Effective security depends on both XYLEX controls and customer-side operating discipline.

  • Customers are responsible for managing their users, protecting their credentials, configuring integrations appropriately, and validating the suitability of the service for their use case.
  • Customers should notify XYLEX promptly if they suspect unauthorized access, exposure, misuse, or other security issues affecting their account or data.
  • If customers require additional control mappings, audit support, or contractual security commitments, those requirements should be raised during procurement or renewal.

Reporting Vulnerabilities and Security Questions

Security concerns can be reported directly to XYLEX for triage and follow-up.

Please report suspected vulnerabilities, account compromise, or other security concerns through our contact page and clearly mark the request as a security issue. Include affected URLs, steps to reproduce, impact assessment, and any deadlines that matter.

Customers with contractual incident channels or escalation paths should continue using those agreed channels.