Responsible Testing & Authorisation Policy

1. Two-Tiered Testing Architecture (Passive vs. Active)

HackGuardX strictly separates unverified public checks from authenticated vulnerability scanning:

• •Tier 1 — Unverified Passive Exposure Check: Anyone may enter a business domain into our Free Exposure Check. This check performs strictly passive DNS lookups (A, MX, TXT, SPF, DMARC) and a single standard HTTPS HEAD/GET request to inspect public security headers and certificate validity—equivalent to a normal web browser visit.
• •Tier 2 — Verified Active Security Scanning: Scheduled web application testing, subdomain enumeration, API fuzzing, and cloud/repository reviews are strictly locked until the workspace owner completes cryptographic ownership verification.

2. Methods of Ownership Verification

Before active testing is enabled on any domain or environment, HackGuardX verifies control via one of four methods:

• •DNS TXT Verification: Adding a unique token (`hackguardx-verification=hr_live_...`) to the domain's DNS zone.
• •HTML Meta Tag / Well-Known File: Placing a verification token at `/.well-known/hackguardx-verify.txt`.
• •Cloud IAM Role Handshake: Deploying our read-only CloudFormation/Terraform audit role inside your AWS, Azure, or GCP account.
• •GitHub App / Microsoft Entra OAuth: Authenticating as an organisation administrator.

3. Non-Destructive Production Safety Guardrails

Even after ownership is verified, HackGuardX's scanning engine defaults to Production-Safe Mode: requests are rate-capped, destructive SQL/file-deletion payloads are never sent, and form crawlers ignore unauthenticated contact/checkout submission loops.