How we handle the access you give us.

Testing authorization

Testing never begins without written authorization from someone entitled to give it. The person who buys confirms at checkout that they own the application or are authorized to approve testing of it, and scope is then confirmed in writing before any testing starts.

If authorization cannot be established, no testing is performed and the payment is refunded in full.

Scope controls

Every engagement has an explicit scope in the portal: the targets that are in, and the ones that are explicitly excluded. Anything outside it is off-limits, including third-party services your application depends on.

Network targets are validated when they are added: private, loopback, link-local and cloud-metadata addresses are refused, and the resolved addresses are recorded so later work connects to what was approved.

Data handling

The two most dangerous things we hold are your test-account credentials and uploaded app binaries. Both have a real expiry that a scheduled job enforces.

• Test credentials are encrypted with AES-256-GCM. The key lives in Google Cloud Secret Manager, never in the database.
• Within your organization, only owner and CTO roles can read stored credentials.
• Credentials expire 30 days after they are stored and are destroyed by the retention job. The row is overwritten, so the audit trail still shows the account existed and when it was destroyed.
• Uploaded binaries are deleted from storage when their retention date passes.
• Reports are streamed through an authenticated endpoint that checks your session and writes an audit entry. We never issue shareable download links.

Minimum evidence

We use the minimum evidence necessary to prove a vulnerability. We never bulk-download customer data. Sensitive storage findings are proven with listings and redacted samples, and anything identifying is redacted in the report.

Where the application supports it, we test with multiple test users and tenants we control, so proving cross-tenant access does not require touching a real customer's data.

Customer confidentiality

Your organization's data is isolated by Postgres row-level security, not by application code alone, so a mistake in one route cannot expose another customer's findings. We test that isolation with real data on demand.

Read-only auditor accounts, for a compliance officer or a prospect's security team, see only delivered work and can change nothing.

Finding disclosure

Findings belong to you. We do not disclose them to anyone else. Case studies on this site are anonymized: customer names, hosts, payloads, credentials and data are removed, and nothing is published that could identify the customer or the target.

Critical findings are reported to you as soon as they are confirmed, not held until the end of the cycle.

Retesting methodology

A fix is verified by replaying the original attack path against the fixed build, plus the obvious variations of it. The result is recorded on the finding: verified, or still exploitable with fresh evidence.

Our own security practices

We hold ourselves to the standard we test you against.

• Portal sign-in by single-use magic link; accounts are created only after a verified payment or by staff, never by open sign-up.
• A nonce-based Content Security Policy, HSTS, and strict security headers on every response.
• Rate limiting and bot protection on sign-in and checkout.
• An audit log of access to findings, reports and credentials that customers cannot read or alter.

Certifications

Zentinel does not currently hold SOC 2 or ISO 27001 certification, and we do not claim to. If your vendor review needs specific evidence, ask and we will tell you exactly what we can provide.

Contact

Security questions, vendor reviews, or a vulnerability in Zentinel itself: hello@zentinel.dev. Legal detail is in the terms and privacy policy.