THREATNEST

Authorized Testing Policy

Effective date: July 19, 2026

This policy explains the minimum conditions under which ThreatNest performs security testing.

It does not itself authorize testing and does not replace a signed Authorization to Test, Statement of Work, or Rules of Engagement.

1. Written authorization required

ThreatNest does not perform active penetration testing without written authorization from a person who has authority over the systems being tested.

A form submission, introductory call, payment, email inquiry, public vulnerability, or publicly reachable system is not sufficient authorization.

2. Required authorization details

Before testing begins, the parties must identify:

  • the client’s legal or organizational identity;
  • the authorized representative;
  • the primary domain or application;
  • each approved subdomain, API, IP address, repository, account, or environment;
  • excluded systems and third party services;
  • the testing period;
  • approved testing methods;
  • prohibited activities;
  • approved testing personnel;
  • emergency contacts;
  • the procedure for stopping testing;
  • and any special operational or data handling restrictions.

3. Approved personnel

Engagements are led by Omar Geylani.

Supporting ThreatNest personnel may participate only where their role is approved under the engagement process and they are subject to the same confidentiality, scope, and data handling requirements.

4. Third party systems

Authorization from the client applies only to systems the client owns or is legally authorized to include.

Embedded or connected third party services are excluded unless the relevant owner or provider has granted permission.

ThreatNest may identify potential concerns involving third party integrations without actively testing the third party.

5. Safe testing standard

ThreatNest uses nondestructive methods and minimizes interaction with real information.

Testing stops at proof of concept where further exploitation would unnecessarily increase risk or expose additional information.

ThreatNest does not intentionally retain or exfiltrate patient information or unrelated confidential records.

6. Immediate findings

Where ThreatNest validates a critical issue presenting a credible immediate risk, it may notify the designated emergency contact before the final report.

The client is responsible for determining and performing the operational, legal, or regulatory response.

7. Testing pause or revocation

The client may request an immediate pause through the agreed emergency contact.

ThreatNest may also pause testing when:

  • unexpected instability occurs;
  • scope or ownership becomes uncertain;
  • a third party objects;
  • sensitive information is unexpectedly exposed;
  • authorization is withdrawn;
  • or continued testing would create unreasonable risk.

Testing resumes only after the issue is resolved and authorization remains valid.

8. No public disclosure

Findings discovered during a client engagement are confidential.

ThreatNest will not publicly disclose a client vulnerability without the client’s written permission or a binding legal requirement.

9. Contact

Questions concerning authorization may be sent to threatnest@threatnest.com.