---
icon: material/certificate-outline
title: "Compliance"
---

Encryption at rest and in transit, SOC 2, GDPR, HIPAA, SOX/PCI-DSS, metric retention, and incident response.

??? tenx-compliance "How is data encrypted"

    - **In transit:** TLS 1.2 or better for all API communications
    - **At rest:** whatever your own metrics backend enforces, inside your own boundary

    Since logs stay in your infrastructure, they're protected by your existing encryption controls.

??? tenx-compliance "How is the AI agent's access controlled"

    The agent (Claude or your own LLM) authenticates with a scoped, rotatable, per-environment key, never a shared master credential. It reads aggregated metrics and proposes config changes to a destination you control (a pull request in your repo, a ConfigMap, or stdout); the engine enforces only what you approve. A read-only mode blocks all writes, and every proposed and applied change is recorded with a stable pattern id, reason, and timestamp in history you own. See [Agent operation](index.md#agent-operation).

??? tenx-compliance "Is Log10x SOC 2 certified"

    **No.** Log10x holds no SOC 2 report today.

    A SOC 2 attests the systems a vendor operates, and log10x operates nothing in your data path: you install the engine, it runs in your infrastructure, log content never reaches log10x, and your own SOC 2 boundary already covers the systems holding your logs. A log10x report would attest how the software is built, signed and distributed, which is the part a [SBOM](../../security/sbom.md) and the [security pages](../../security/index.md) evidence directly today.

    The facts a [SIG Lite](https://sharedassessments.org/sig/){target="_blank"} or CAIQ asks about the product are published across those pages; a licensed form on your own copy comes back completed from [security@log10x.com](mailto:security@log10x.com).

    **Metrics:** Metrics go to a time-series backend you own, inside your own compliance boundary. The log10x-hosted backend exists for the demo and for evaluation, not as a production destination.

??? tenx-compliance "How does Log10x support GDPR compliance"

    Log content never reaches log10x, so log10x never processes it and it never crosses a border on our account; where it does travel is decided by your own pipeline, so a SIEM hosted outside your region is the thing to check. Deploy in your EU infrastructure and the parts 10x controls stay in the EU: the agent, the engine, and your metrics store all run in your region.

    Where a contract needs paper covering the account and billing records log10x does hold, [security@log10x.com](mailto:security@log10x.com) handles it at contract time.

??? tenx-compliance "Can Log10x support HIPAA requirements"

    All log processing happens in your environment, so PHI stays inside your HIPAA-compliant infrastructure and log10x receives none of it. Enterprise contract terms are handled by [security@log10x.com](mailto:security@log10x.com).

??? tenx-compliance "What about SOX and PCI-DSS"

    Audit trails are maintained entirely in your infrastructure.

    Log10x doesn't process or store log content, placing us outside your CDE (Cardholder Data Environment). Your existing controls apply. The architecture simplifies compliance scope.

??? tenx-compliance "What is your incident response and breach notification process"

    Your log content sits in your own infrastructure, and log10x has no access to it or to the systems holding it, so an incident inside log10x cannot expose it. What log10x does hold, and what could therefore be exposed, is account and billing records plus any aggregated metrics an evaluation sent to the hosted backend. Neither holds log content.

    Two log10x systems do sit upstream of your deployment even though they hold none of your data: the release pipeline that builds and signs the artifacts you install, and the KMS key that signs license tokens. Both are in scope for incident response, and a compromise of either is notified the same way, because the remedy is yours to apply through an upgrade.

    1. **Notification:** the account contact, directly by email.
    2. **Contact:** [security@log10x.com](mailto:security@log10x.com).

    Incident response inside your own infrastructure stays with your team, since that is where the engine and your logs are.