Service levels

Commitments we actually make.

We publish the service-level commitments we hold ourselves to — response targets, product guarantees, and our maintenance policy. We do not publish a fabricated availability figure; a quantified, contractual uptime SLA is part of your enterprise agreement.

View system status

01 · Support response targets

How fast we respond, by severity.

Response targets are the time to a substantive human response and the start of active work — not a promise of resolution time, which depends on the issue. Contractual, credit-backed targets can be set in the enterprise agreement.

S1 — Critical

The hosted service is unavailable, or a confirmed security issue materially affects your tenant.

1 business hour

S2 — High

A core capability (discovery, scanning, evidence export, or remediation) is significantly degraded with no reasonable workaround.

4 business hours

S3 — Normal

A non-critical function is impaired, or a component is degraded but a workaround exists.

1 business day

S4 — Low

A question, cosmetic issue, or feature request with no service impact.

2 business days

02 · Product guarantees

Guarantees that hold on every plan.

These are structural properties of how TrustFix operates in your environment — not settings, and not gated behind a tier.

Read-only by default

TrustFix inventories identities through least-privilege, read-only access. We do not require — and do not want — standing write credentials into your environment. This is an axiom of the product, not a tier.

Human approval for every fix

No change lands in your infrastructure without a person merging it. Remediation is delivered as a pull request you review and merge; TrustFix proposes and proves, you decide.

Agentless collection

There is no agent to deploy into your hosts. TrustFix reads identity metadata through cloud and code-host APIs, so there is no new running process inside your estate to maintain or trust.

Every action on a signed ledger

Scans, findings, and proposed fixes are recorded on an append-only, Ed25519-signed trust ledger you can verify offline — so what TrustFix did in your environment is itself auditable, not a black box.

03 · Maintenance & notification

How we handle change and disruption.

Planned maintenance

Maintenance that may affect availability is scheduled for low-traffic windows and communicated to affected customers in advance where practicable. Routine, zero-impact deployments do not require notice.

Incident notification

We notify affected customers of material service incidents, and post them on the public system-status page with timestamps. Confirmed security incidents affecting your data are handled under the notification terms of your agreement and DPA.

Availability posture

This service does not publish a synthetic uptime percentage. A quantified, credit-backed availability SLA — with measurement method and remedies — is defined in the enterprise agreement, so the number you rely on is contractual, not marketing.

Responsible disclosure

Report a security issue to security@trustfix.dev. We acknowledge receipt promptly and follow a coordinated, 90-day disclosure timeline consistent with industry norms, with safe harbor for good-faith research.

These commitments describe our current operating practice and are provided for transparency. The definitive, contractual service-level terms — including any quantified availability target and service credits — are set out in your enterprise agreement, which governs in the event of any conflict.