Skip to content
SECQON

Legal / Acceptable Use Policy

Draft pending legal review. This text is being finalised with counsel and the highlighted values are not yet filled in. It is published so you can read exactly what the product asks you to accept.

SecQon Acceptable Use Policy

Effective date: 27 August 2026 · Version: 2026-08-v1

This Acceptable Use Policy ("AUP") forms part of the SecQon Terms of Service and applies to everyone who uses SecQon. Capitalised terms have the meaning given in the Terms.

SecQon sends real attack traffic at real systems. This policy exists so that traffic only ever reaches systems that someone with authority has genuinely authorised.

Breach of this policy is grounds for immediate suspension without notice, with no refund, and may be reported to law enforcement.


1. The one rule that matters

Only point SecQon at systems you own, or that you hold current written authorisation to have tested. Everything else in this policy follows from that.

Verifying an Asset proves you control it technically. It does not prove you are entitled to authorise testing of it. Both must be true.

2. Assets you must not add

You must not add, verify, or attempt to scan:

  1. Anything you do not own and are not authorised to test, including systems you merely have an account on, access to, or a contract with.
  2. A third-party SaaS or hosted application you are a tenant of — for example your CRM, help desk, payment gateway, email provider, or code host. You are a user of that system, not its owner, and their terms govern testing of it.
  3. Shared hosting where the IP address, server or platform also serves other customers, unless you have the provider's written permission.
  4. Infrastructure belonging to a hosting, cloud, CDN, WAF, DNS, registrar, transit or telecommunications provider, as distinct from your own content served through it.
  5. Government, defence, judicial, electoral, or public-sector systems, without written authorisation from the operating authority and, where required, the relevant CERT.
  6. Critical national infrastructure: power, water, fuel, transport, aviation, maritime, telecommunications core networks, emergency services, and anything designated as protected critical infrastructure in its jurisdiction.
  7. Healthcare systems where a fault could affect patient care, including clinical, diagnostic, pharmacy and medical-device systems.
  8. Financial market infrastructure: exchanges, clearing houses, payment networks, settlement systems, and core banking systems.
  9. Industrial control systems, SCADA, OT, building management, and embedded or safety-critical devices.
  10. Systems of a third party operated on their behalf unless you are a managed service provider with a written arrangement with us covering it, as required by Section 6.5 of the Terms.
  11. Assets in a jurisdiction where the testing would be unlawful, or where you cannot satisfy local notification requirements.

If you are unsure whether an Asset is permitted, ask us at ABUSE_EMAIL before adding it.

3. Cloud and hosting provider policies are your responsibility

Major providers publish their own rules about security testing of workloads on their infrastructure. Some permit testing of your own resources without notice; some require prior notice; some prohibit certain classes of test outright; and almost all prohibit testing that affects shared or provider-managed components.

You are responsible for reading and complying with the policy of every provider that serves your Assets — including cloud, hosting, CDN, WAF, DNS, API gateway and managed database providers — and for obtaining any permission they require before you verify an Asset. A provider's rejection of testing does not entitle you to a refund.

4. Techniques SecQon will not perform

These are disabled in the product and must not be requested, re-enabled or worked around. Attempting to induce them is a breach of this policy.

  • Denial of service, distributed denial of service, stress or load testing, or any test whose intent or likely effect is to exhaust capacity.
  • Destructive actions: deleting, encrypting, corrupting or overwriting data; dropping tables; defacing content; disabling services or accounts.
  • Persistence: installing backdoors, web shells, implants, scheduled tasks, or any artefact intended to survive the test.
  • Lateral movement or pivoting from a tested Asset into any other system, including systems on the same internal network.
  • Bulk data exfiltration. Validation extracts the minimum needed to demonstrate an issue — never a dataset.
  • Social engineering, phishing, vishing, smishing, or any test directed at a human being, including your own staff.
  • Physical security testing or attacks on premises, personnel or hardware.
  • Wireless attacks and attacks against networks not reachable from the public internet.
  • Supply-chain attacks, including publishing packages, typosquatting, or targeting your vendors' systems.
  • Password spraying or credential stuffing against production accounts, or the use of credentials obtained from breach corpora.
  • Attacks on third parties that share infrastructure with an Asset.

5. How you must use the platform

You must not:

  1. Attempt to bypass, disable or degrade the scope guard, egress controls, verification requirement, rate limits, scan windows or plan limits.
  2. Use the Service to relay, proxy, launder or disguise traffic aimed at anything other than your Authorised Assets.
  3. Submit credentials you are not authorised to use, credentials with more privilege than testing requires, or credentials belonging to another person.
  4. Falsify verification — for example, by exploiting a vulnerability in a third party's system in order to place a verification token on it, or by using a hijacked, expired or dangling DNS record or subdomain.
  5. Create accounts by automated means, create multiple accounts to evade limits or a suspension, or share credentials between people.
  6. Reverse engineer, scrape, or copy the Service, its rules or its templates, or use it to build a competing product.
  7. Interfere with the Service itself, including probing, scanning or testing SecQon's own infrastructure other than through the disclosure process in Section 8.
  8. Use the Service to stalk, harass, defraud, or infringe the rights of any person.
  9. Use Findings to attack any system, or disclose another party's vulnerabilities without their consent.
  10. Misrepresent a SecQon Report as a manual penetration test, a certification, or an audit opinion, or alter a Report while presenting it as ours.

6. Rate limits, windows and volume

Scan intensity, request rates and concurrency are set by your plan and profile and are enforced by the platform. Do not attempt to raise them by scripting the API, creating additional accounts, or re-adding Assets. If you need higher intensity for a genuine reason, contact us — we would rather agree it than find it.

7. Content you submit

Do not upload or enter unlawful content, malware, another party's confidential information, or personal data beyond what the Service needs to operate.

8. Reporting

  • Abuse, or a system being tested without authorisation: ABUSE_EMAIL. We treat these as urgent and can stop a scan immediately.
  • A vulnerability in SecQon itself: SECURITY_EMAIL. Please give us a reasonable period to remediate before public disclosure. We will not pursue legal action for good-faith research that respects this policy, stays within our published scope, and does not access, alter or exfiltrate other customers' data.

9. Enforcement

Where we believe this policy has been breached, we may, at our discretion and without prior notice:

  • stop in-flight scans and activate the account kill switch;
  • suspend or terminate the account, with no refund;
  • remove or unverify an Asset;
  • preserve and examine the relevant audit records and scan logs;
  • notify the owner of an affected system, the relevant provider, a CERT, or law enforcement, and cooperate with any resulting investigation; and
  • require evidence of your authorisation before restoring service.

We will tell you what happened and why as soon as it is reasonable to do so, unless we are legally prevented from doing so.

10. Changes

We may update this policy as the threat landscape and the product change. A material change requires your acceptance before you add a new Asset or launch a new Scan.

Questions: LEGAL_EMAIL · Abuse and emergency stop: ABUSE_EMAIL