Trust

A review path that stands up to real buyer diligence.

Anydefect should be reviewable without a long sales sequence. This page shows what is public, what is tracked, and how customers move from first evaluation to support, procurement, and incident communication.

Access and authorization

Customers are expected to connect only environments, tenants, repositories, APIs, and targets they own or are explicitly authorized to assess.

Workspace access is role-based so reviewers, operators, and stakeholders can work from the same evidence without sharing one broad admin account.

Anydefect keeps the customer workflow centered on findings, scans, reports, and audit history rather than exposing internal operator systems.

Operational review path

Documentation, pricing, privacy, terms, and the DPA are public so buyers can review the operating model before procurement starts.

Support requests are expected to carry workspace, connector, scan, and time-window context so the issue can be tracked on one thread.

Platform-wide incidents are communicated on the public status page, while workspace-specific troubleshooting stays in the support path.

Evidence and escalation

Customers should be able to move from connector setup to findings, remediation, reporting, and audit history without rebuilding the evidence chain by hand.

Reports and exports are product outputs, not separate analyst deliverables assembled outside the workflow.

Trust review starts with the public pages below and then moves into tracked contact when a buyer needs legal, security, or procurement follow-up.

How a serious review should work

1. Review the public baseline

Start with docs, legal pages, privacy, DPA, trust, and pricing so the operating model is clear before custom questions start.

2. Validate with one real source

Use scoped, least-privilege access where possible, run a real baseline, and confirm findings, ownership, and exports before wider rollout.

3. Escalate on the right path

Use status for public incidents, support for workspace issues, and contact for procurement or legal follow-up that needs a named owner.

What is public vs. what is tracked

Public pages should answer the baseline questions: what the platform does, how customers use it, which legal documents exist, and where incidents are posted.

Anything tied to a workspace, procurement thread, signed legal document, or security review follow-up should move into a tracked request through support or contact so it has a clear owner and reference.