Authorization first
The accountable owner must authorize targets and resolve third-party or provider permissions before active testing.
Trust center overview
Security, governance, and responsible engagement
Review how to govern target authorization, scope, credentials, sensitive evidence, operational safety, reporting, and limitations before a Revaizor engagement.
Minimize sensitive inputs
Share only the credentials, test data, architecture context, and evidence needed for the approved objective.
Ask for specifics
Security, privacy, retention, access, location, subprocessors, and incident terms should be confirmed for the proposed engagement.
Engagement governance
A security test should have an accountable owner, written authorization, exact targets, explicit exclusions, permitted techniques, a test window, escalation contacts, and stop conditions. Provider and third-party permissions are part of authorization, not an assumption.
Credentials and target data
Use scoped test accounts and non-production data where the objective permits. Avoid sharing secrets in initial sales forms. Before an engagement, agree an approved transfer method, recipients, access duration, and revocation process appropriate to the material involved.
Evidence handling
Penetration-test evidence may contain system details, identifiers, screenshots, requests, responses, or limited proof of impact. Agree collection limits, redaction, access, report distribution, retention, deletion, and any customer-side storage requirements before testing begins.
- Collect only evidence needed to support the authorized observation.
- Avoid unnecessary production records and personal or payment data.
- Restrict detailed exploit evidence to approved operational recipients.
Operational safety
Rules of engagement should exclude destructive or availability-impacting actions unless specifically approved with safeguards. Monitoring and incident-response contacts need a clear path for suspected incidents, unintended access, or conditions that require testing to pause.
Reporting and disclosure
Reports should separate confirmed observations from assumptions, describe evidence provenance, and state constraints. Disclosure of findings to vendors or third parties requires customer direction and a coordinated process; a test engagement does not grant permission to publish vulnerabilities.
Verify the controls you require
This page does not claim certifications, specific hosting locations, retention periods, encryption designs, audit reports, or contractual commitments. Request current documentation and engagement-specific terms for the controls that matter to your risk review.
Frequently asked questions
Should sensitive target details be sent through the public contact form?
No. Use the public form for high-level qualification only. Agree an appropriate channel and handling terms before sharing credentials, non-public architecture, target lists, or vulnerability evidence.
Can testing continue when scope ownership is unclear?
No. The accountable owner and any required provider or third-party permissions must be established before active testing of that target.
Where are binding security commitments documented?
Binding commitments belong in the executed agreement and engagement documentation. Ask for current evidence and terms rather than relying on general website language.
Define your next security mission
Tell us the target type and desired outcome. Sensitive scope details are collected after qualification.
Start a security review