Rules of engagement

Every Cetonix penetration test runs under a written rules of engagement document, signed by you before a single packet is sent. This page sets out what that document contains. It is the contract between what you authorised and what we actually do.

1. Authorisation

Testing is performed only against systems you own or are contractually authorised to test. Before testing begins you confirm in writing that you have the authority to authorise it, and where a third party hosts or operates a system in scope, that you have obtained their permission. We will ask you to confirm this explicitly rather than assume it.

Without signed authorisation, no testing takes place. There are no exceptions and no verbal approvals.

2. Scope

The document lists, precisely:

• In scope: hostnames, IP ranges, application URLs, API base paths, mobile build identifiers and versions.
• Out of scope: systems explicitly excluded, including shared infrastructure, third-party services and any environment you have not authorised.
• Roles and credentials: which accounts we receive, at which permission levels, in which tenants.
• Environment: production, staging, or a production-parity environment, named explicitly.

Anything not listed as in scope is out of scope. If we find something interesting that sits outside the boundary, we report its existence and stop — we do not test it and then ask.

3. Testing windows and rate limits

Agreed in advance: permitted days and hours, any blackout periods, and rate limits on automated requests. Where testing could plausibly affect availability, we agree a lower-intensity profile or an out-of-hours window.

4. Prohibited techniques

Unless you specifically authorise them in writing, the following are excluded from every engagement:

• Denial of service and resource exhaustion testing.
• Destructive payloads, and any action intended to delete, corrupt or encrypt data.
• Social engineering of your staff, including phishing and pretexting.
• Physical security testing.
• Attacks on third parties reachable from your environment.
• Bulk extraction of personal data. Where a vulnerability exposes records, we count and classify them; we do not copy them out.

5. Contacts and escalation

You provide a named technical contact reachable during the test window, and an escalation contact. We provide the named engagement lead and their direct contact details.

We stop and call you immediately if we believe testing has affected availability, we encounter evidence of a pre-existing compromise, or we find a vulnerability whose exploitation would cause harm we have not been authorised to risk.

6. Critical findings

Critical and high-severity findings are reported to your named contact the day we confirm them, with reproduction steps, so remediation can start before the report exists. They are never held for the report or for a scheduled call.

7. Evidence

We record what is necessary to evidence a finding and no more. Credential values, personal data and images are masked in the report. Evidence is encrypted, access-controlled, and destroyed at the end of the retest window or earlier on your written request, with written confirmation. See our DPA and security practices.

8. Identifying our traffic

On request we provide the source IP addresses we will test from and a custom User-Agent string, so your monitoring team can distinguish our activity from a real attack. Where you want detection capability tested instead, we agree that explicitly and do not announce ourselves.

9. Changes

Any change to scope, windows or permitted techniques is agreed in writing and appended to the document before it takes effect. We do not expand scope mid-engagement and invoice for it afterwards.

10. Your right to stop

You may suspend or terminate testing at any time, for any reason, by contacting the engagement lead. We stop immediately. Fees for work already performed remain payable; nothing else does.

Request the current template via our contact form or support@cetonix.com.