How we scan, and what we never do.

1. Authorized targets only

RiskMeter only ever performs scanning activity against assets the requester has explicitly identified, in writing, as either owned by them or as assets they are authorized by the asset owner to approve for testing. Each Scan is preceded by a written scope confirmation that lists every domain, subdomain, path prefix, and (where applicable) IP range that is in scope.

Where an asset is hosted by a third party (for example, AWS, Cloudflare, Vercel, Heroku, Netlify, or a managed CMS), it is the requester's responsibility to confirm that the host's own authorization requirements have been met. RiskMeter may decline to test any asset where third-party authorization is unclear or absent.

If we cannot independently verify ownership or authorization to a reasonable degree of confidence, we will pause and request additional confirmation before proceeding. We reserve the right to decline any engagement for any reason or no reason.

2. Scope and assets

Default scope, unless explicitly modified in the written scope confirmation, includes:

• Public web domains and subdomains explicitly listed by the requester
• Web applications served from those domains
• Public-facing APIs the requester authorizes for testing
• Server-level configuration of those assets (TLS versions, certificate validity, security headers, exposed services, server banner strings)
• Public-facing static content and asset directories

The following are out of scope unless explicitly added in writing:

• Authenticated areas behind your customers' accounts
• Third-party services (payment providers, identity providers, CDNs, email providers, analytics vendors), even if they appear on your site
• Infrastructure or services not owned by the requester or not covered by the written authorization
• Source-code review or static code analysis
• Mobile applications
• Physical security testing or social engineering

3. What we will not do

• We will not perform destructive testing (data destruction, account deletion, intentional outages, content modification).
• We will not perform denial-of-service or sustained high-volume traffic attacks.
• We will not perform social engineering, phishing, or any test that targets your staff, contractors, or customers.
• We will not attempt to access, exfiltrate, or modify customer or employee personal data.
• We will not use credentials we are not explicitly given, and we do not request or store customer passwords through this Site.
• We will not test outside the agreed scope window without prior written agreement.
• We will not chain a discovered vulnerability to gain further access beyond what is necessary to demonstrate the issue.

4. Scan intensity and timing

Scans are throttled to minimize load on your origin and on shared infrastructure. We will work with you to identify a low-traffic window when possible. We commit to:

• Provide a defined scan window with a stated start and end time
• Use rate-limited, non-flooding traffic patterns suitable for production environments (typically far below normal organic traffic volume)
• Pause and notify you within a reasonable time if we observe scan activity correlating with measurable service degradation
• Stop and re-coordinate if you report any scan-related impact during the scan window

5. Source identification

Scan traffic will originate from a documented set of IP addresses and a clearly identifiable user-agent string. We will share both with you in writing prior to scan start so your monitoring tools and incident-response team can correlate the activity with our engagement.

If we change scan source IPs during an engagement (for example, because a cloud provider rotates an address), we will notify you before scan traffic resumes from the new address. We do not intentionally route scan traffic through anonymizing proxies, Tor, or shared residential proxies.

6. Data handling during the scan

During a scan we may incidentally observe technical data emitted by your application — HTTP responses, headers, error pages, redirect chains, certificate metadata, and public content that the application returns. We treat all of this material as Confidential Information of the requester.

We do not retain unnecessary response bodies. Where we capture response data as evidence for a finding, we redact any inadvertently captured sensitive content (e.g., personal data appearing in stack traces or error pages) before storage.

See our Privacy & Data Handling page for the full data lifecycle, retention periods, and subprocessor list.

7. Findings and disclosure

Findings are disclosed only to the authorized requester, via the contact email confirmed during application. We do not publish or share specific findings with third parties, sell findings to anyone, or use findings to market against the requester.

We may publish or share aggregated, fully de-identified statistics about scan results across our customer base (for example, “X% of scanned sites had at least one missing security header”). Such statistics will not name, identify, or be reasonably linkable to any specific requester.

If a finding indicates an active compromise of the asset (for example, an indicator of an attacker already present), we will notify the requester promptly through the agreed contact channel and pause further scanning until the requester confirms how to proceed.

8. Stopping a scan

You may revoke authorization or request that we cease scanning at any time, in writing to legal@riskmetercybersecurity.com or by replying to your designated RiskMeter contact email. Upon receipt we will:

• Stop active scanning within a reasonable time (typically within the same business hour for staffed coverage)
• Confirm cessation in writing
• Honor any reasonable request to delete data collected during the engagement, subject to limited records retained for legal, accounting, and security purposes (see Retention in our Privacy Policy)

9. Limits of testing & responsible expectations

A scan reflects the state of your environment at a single point in time, using a defined set of techniques and signatures. It is not a guarantee that your application is free of vulnerabilities, and the absence of a finding in a Scan Report does not constitute a representation that no vulnerability exists. Findings are presented to the best of our ability based on the techniques used during the engagement.

We disclose the techniques we use and what they cover in the Scan Report. We do not claim to detect zero-day vulnerabilities or exploit chains that have not yet been publicly disclosed.

10. Security incidents during a scan

In the unlikely event that an action we take during a scan contributes to an outage, performance degradation, or other operational impact, we will: (a) immediately stop the action; (b) notify your designated contact; (c) preserve relevant logs to help determine cause; and (d) cooperate in good faith with any review of the engagement.

11. Changes to these rules

We may update these Rules of Engagement from time to time. The version that applies to your scan is the version referenced (by date) in your written scope confirmation. Material changes affecting customers with active engagements will be communicated directly.

12. Contact

Operational questions about an in-progress scan: reply to your designated RiskMeter contact email. Legal or scope-change questions: legal@riskmetercybersecurity.com. General questions: see our Privacy Policy.