Penetration testing

Request the current report or approved summary from your enterprise diligence contact. Check its version, scope, dates, methods, and results.

Assessment scope

The release requires an authorized independent assessment before production use or live customer data. Its scope must cover the enabled core release, including:

review requirement and case creation;
employee identity, assignment, stale membership, and review authority;
tenant and application boundaries;
Inbox, authenticated deep links, reviewer email, and decision actions;
callback registration and endpoint validation;
raw-body signature verification, key rotation, replay, ordering, and expiry;
SDK continuation binding, atomic claim, and execution acknowledgment;
repair, replay, retention, deletion, and tenant offboarding; and
support diagnostics and evidence export.

The test plan must cover these attack and failure cases:

Object access without authorization (IDOR), cross-tenant binding, assignment manipulation, and self-approval.
Server-side request forgery (SSRF), DNS rebinding, redirects, private addresses, and alternate ports.
Oversized or slow responses and header injection.
Signature forgery, timestamp replay, key confusion, and schema downgrade.
Secret exposure, protected-field allowlists, and conflicting idempotent replay.

Evidence to review

The release evidence must record:

the assessor and authorization;
exact version, environments, dates, and scope;
methodology and exclusions;
each finding, severity, owner, and disposition;
retest evidence for every critical and high finding;
approved residual-risk decisions for lower findings; and
Product, Engineering, and Security approval for the tested version.

This list defines required coverage; it does not claim that testing is complete. Use the approved report to confirm results and unresolved findings.

Customer or customer-assessor testing

Obtain written authorization before testing a VeriProof-managed environment. It must name the environment, tenant, source addresses, techniques, volume, and test window.

Normal application access does not authorize scanning, cross-tenant probes, stress tests, Staff Portal testing, social engineering, or tests against another provider.

An authorization record should define:

in-scope hostnames, APIs, tenants, and accounts;
allowed methods and test-data classification;
excluded systems and third-party services;
request-rate and concurrency limits based on current environment capacity;
stop conditions and an immediate contact;
evidence handling and vulnerability-reporting channels; and
cleanup and credential-revocation steps.

Do not copy fixed rate limits from this page into a test plan. The security and operations owners must approve limits for the selected environment.

Reporting a finding

Use the Responsible Disclosure process or the secure channel named in the written rules of engagement. Include the authorization reference when the work was part of an approved assessment.

Do not place credentials, signing secrets, protected customer evidence, or exploit data in ordinary email, chat, screenshots, or public issue trackers.