SecQon Rules of Engagement and Testing Authorisation

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

This document (the "RoE") is the operative authorisation under which Infiqon Private Limited ("Infiqon") conducts security testing against your systems through SecQon. It forms part of the SecQon Terms of Service and takes precedence over them in respect of the conduct and scope of testing.

Read this as you would read a penetration testing authorisation letter, because that is what it is. It is the document that makes our testing of your systems lawful, and the document we will rely on if someone challenges it.

---

1. Authorisation granted

1.1 You authorise and instruct Infiqon, and its personnel and automated systems acting on its behalf, to conduct external, non-destructive security testing against each of your Authorised Assets, for the duration set out in Section 10, using the methods described in Section 4.

1.2 This authorisation is given by you as the party entitled to grant it, and extends to the specific activities described in this RoE and to nothing else.

1.3 This is a standing authorisation. Once an Asset is verified and your subscription is active, scheduled and continuous testing may run without a further prompt, until you remove the Asset, pause monitoring, or your verification lapses.

2. Your warranty of authority

2.1 You represent and warrant, on each occasion you add an Asset, complete verification, launch a Scan, or allow a scheduled Scan to run, that:

1. you own the Asset, or hold current, express, written authorisation from its owner and operator to authorise third-party security testing of it;
2. you have authority to bind the entity on whose behalf you act;
3. you have obtained any permission required by the hosting, cloud, CDN, WAF, DNS or managed service provider that serves the Asset;
4. the testing described here is lawful in every jurisdiction in which the Asset is hosted, operated or reachable; and
5. the Asset is not in a prohibited category under the Acceptable Use Policy.

2.2 Technical verification is not legal authority. Proving control of a DNS record or a web root demonstrates that you can place a token; it does not demonstrate that you are entitled to authorise an attack. Section 2.1 is what we rely on for that, in every case.

2.3 You will keep evidence of your authority for as long as the Asset is in your account and for three years afterwards, and will produce it within five business days of a reasonable request from us, including in response to an abuse complaint.

3. Scope

3.1 In scope

Only Verified Assets in your account, at the time each Scan runs. Nothing else, ever.

3.2 Out of scope — always

• Any Asset that is not verified, or whose verification has lapsed.
• Subdomains of a verified apex domain. Verifying example.com does not authorise testing of admin.example.com. Each host is verified separately.
• Any host, IP or service discovered during reconnaissance but not verified. Discovered surface is shown to you as "verify to test" and receives no test traffic.
• Anything excluded by the Acceptable Use Policy.
• Internal, private or non-internet-facing systems.

3.3 How scope is enforced

Scope is enforced at the network egress boundary of the scan worker, not merely in the logic that chooses what to test. Every outbound connection is checked against your verified-asset allowlist and the resolved address is pinned; anything out of scope is blocked and recorded, even if it was introduced mid-scan by reconnaissance, a redirect, a DNS change or a bug in our own code. Denials are written to the audit log.

3.4 Changing scope

Add an Asset and verify it to bring it into scope. Remove an Asset to take it out of scope immediately.

4. Methods we use

Depending on the scan profile you choose, testing may include:

1. Passive reconnaissance — DNS records, certificate transparency logs, public metadata, technology fingerprinting.
2. Surface enumeration — subdomain discovery, port and service discovery, endpoint and content discovery on your verified hosts.
3. Transport and configuration testing — TLS configuration and certificates, security headers, cookie flags, DNS hygiene, exposed development and administrative interfaces.
4. Vulnerability testing — checks for known vulnerable software versions and for common web vulnerability classes, including the OWASP Top 10.
5. Bounded exploitation for validation — a limited, minimal attempt to confirm whether a candidate issue is genuinely exploitable, using the smallest payload that demonstrates the point. This is what allows us to label a Finding as confirmed rather than theoretical.
6. Authenticated testing — only where you have explicitly supplied credentials for that purpose, subject to Section 6.
7. Continuous monitoring and change detection — periodic re-testing and alerting on new exposure.

5. Methods we will not use

The following are prohibited and disabled, and are not authorised by this RoE under any circumstances:

• denial of service, distributed denial of service, stress or load testing;
• destructive actions of any kind — deletion, encryption, corruption or overwriting of data, defacement, or disabling of services or accounts;
• establishing persistence: backdoors, shells, implants or scheduled tasks;
• lateral movement or pivoting beyond the Authorised Asset;
• bulk extraction of data;
• social engineering, phishing or any activity directed at a person;
• physical or wireless attacks;
• attacks against a third party, including other tenants of shared infrastructure.

Payloads are bounded, per-asset rate limits are enforced, and scan windows are respected.

6. Credentials for authenticated testing

If you supply credentials:

• issue dedicated test accounts with the least privilege needed;
• never supply production administrator or superuser credentials;
• expect them to be used to log in and exercise authenticated functionality, which may create, modify or delete data within that account's own permissions;
• revoke them when you stop testing.

Credentials are stored encrypted, are never sent to a language-model provider, and are never included in Findings, evidence or Reports. You remain responsible for the consequences of the access you grant.

7. Source of traffic, timing and control

7.1 Source. Test traffic originates from a dedicated, published egress address range, so your team and your providers can identify it. It is identifiable in your logs as SecQon.

7.2 Notify your defenders. We recommend you tell your hosting provider, security operations team, managed detection provider and WAF vendor before your first scan — unless you are deliberately testing whether they notice, which is a legitimate reason not to.

7.3 Timing. Scans run in the windows and at the intensity your plan and profile allow. Choose a low-traffic window for your first scan of a production system.

7.4 Stopping a scan. You can stop any running scan from the application at any time. For anything urgent — including a report that we are testing a system that should not be tested — contact ABUSE_EMAIL, and we will activate the kill switch for the account and halt in-flight jobs.

7.5 Our right to stop. We may pause or stop testing at any time if we believe it is causing harm, is out of scope, or is not properly authorised.

8. Risks you accept

Security testing carries inherent risk. Although SecQon is designed to be non-destructive, bounded and rate-limited, you acknowledge and accept that testing of your Authorised Assets may:

• degrade performance or increase latency during a scan;
• trigger application errors, exceptions and unexpected behaviour;
• generate large volumes of log entries, alerts and security notifications, including pages to your on-call staff;
• cause a WAF, CDN, rate limiter or upstream provider to block our traffic — or, in some configurations, to block or throttle other traffic;
• cause account lockouts or rate-limit responses on authentication endpoints;
• write test data into forms, records, queues, tickets, analytics or email triggered by your application;
• in rare cases, cause a service to become temporarily unavailable.

You accept these risks in respect of your own Authorised Assets, and you are responsible for maintaining current backups and for choosing an appropriate scan window and profile. Where an Asset is business-critical, test a staging equivalent first.

9. Your responsibilities

1. Add only Assets you are entitled to authorise, and keep that entitlement current.
2. Keep verification records in place; if a DNS TXT record or hosted token is removed, verification lapses and testing stops.
3. Maintain a technical contact on the account who can be reached quickly.
4. Maintain current backups and a rollback path.
5. Inform the people who will see the alerts.
6. Remove an Asset immediately if your authority over it ends or is contested, and tell us at ABUSE_EMAIL.

10. Term, revocation and survival

10.1 This RoE takes effect when you accept it and continues for each Asset for as long as that Asset is verified and your account is active.

10.2 You may revoke authorisation at any time for an Asset by removing it, or entirely by closing your account. Revocation is effective immediately for new scans; in-flight scans are stopped as soon as practicable.

10.3 Sections 2, 8, 11 and 12 survive revocation and termination.

11. Indemnity

11.1 You defend, indemnify and hold harmless Infiqon, its affiliates, and their directors, officers, employees, contractors and agents against all third-party claims and resulting losses, liabilities, damages, fines, penalties, settlements and reasonable legal and expert costs arising out of or relating to:

1. testing of a system you were not entitled to authorise, or testing in excess of the authorisation you actually held;
2. your breach of this RoE, the Acceptable Use Policy, or Section 5 of the Terms;
3. any effect of authorised testing on any system or on any third party, including disruption, downtime, data alteration or data loss, and including claims by your own customers, users, or by a hosting, cloud, CDN, WAF, DNS or transit provider or another tenant of shared infrastructure; and
4. any regulatory or law-enforcement action arising from your use of SecQon, including under India's Information Technology Act, 2000 or any equivalent computer-misuse or cybercrime law of any jurisdiction.

11.2 This indemnity is the same obligation as Section 15 of the Terms, restated here because it is the consequence of the authorisation you are giving. Section 15.2 of the Terms governs the defence procedure, the indemnity is not subject to the liability cap, and it survives termination.

11.3 It does not apply to the extent the loss is caused by our gross negligence or wilful misconduct, or by our testing of a target outside the scope you authorised.

12. Legal compliance and record

12.1 You confirm that the testing authorised here does not breach any applicable law, including the Information Technology Act, 2000 (India) and equivalent computer-misuse, unauthorised-access and data-protection legislation in any jurisdiction where an Asset is hosted, operated or reachable.

12.2 Every authorisation event is recorded in an append-only, cryptographically chained audit log: your acceptance of this RoE and its version and text hash; the per-asset attestation you make when adding each Asset; the per-scan attestation you make when launching each Scan; every verification result; and every out-of-scope denial by the scope guard. These records are our evidence, and yours, that testing was authorised.

12.3 You agree that this electronic record is a valid electronic record and signature under the Information Technology Act, 2000 and the Indian Contract Act, 1872.

---

What you are agreeing to, in plain language

• We only test what you have proven you control and told us you may authorise.
• You are telling us you have the right to authorise it — and you carry the consequences if that turns out not to be true.
• We will never do anything destructive, and we will stop the moment you ask.
• Testing can still cause disruption, and you accept that risk for your own systems.
• Every one of these authorisations is logged, with the exact text you accepted.

Emergency stop and abuse: ABUSE_EMAIL · Questions: LEGAL_EMAIL