Rules of engagement

VillainStrike is a contracted security testing provider. Everything we do is performed with the prior written authorisation of the organisation that owns or lawfully controls the systems being tested. These rules are not marketing copy: they are the conditions under which we accept work, and they form part of every engagement contract we sign.

1. Written authorisation comes first

No testing activity of any kind begins before a statement of work is signed by an authorised representative of the client. That document names the systems in scope, the testing window, the techniques permitted, the named contacts on both sides and the escalation path for anything high-risk. A verbal go-ahead, an email saying "sounds good" or a purchase order on its own is not sufficient authorisation, and we will not act on one.

We also confirm that the person signing has the authority to grant it. Where a system is operated by a subsidiary, a joint venture or a department that does not own it outright, we ask for confirmation from the party that does.

2. We test only systems the client owns or controls

Every target is listed explicitly by hostname, IP range, application or account. Anything not on that list is out of scope, including systems that merely appear during reconnaissance. If we discover an asset that looks like it belongs to the client but is not listed, we report it and ask before touching it — we do not assume permission.

We do not accept engagements aimed at a third party. If the objective of a request is to obtain access to systems, accounts or data belonging to someone other than the requesting organisation, we decline it.

3. Hosted and shared infrastructure

Where systems run on infrastructure operated by someone else — a cloud provider, a managed host, a SaaS platform — the client's authorisation alone may not be enough. We check the provider's testing policy and, where required, ask the client to obtain or confirm the provider's permission before the window opens. Providers who require advance notification get it.

4. What we exclude by default

• Denial-of-service and load-based attacks against production systems.
• Destructive actions: deleting, encrypting or corrupting data.
• Bulk extraction of personal data. Where access to data proves a finding, we take the minimum evidence necessary — typically a redacted record count or a single screenshot — and nothing more.
• Social engineering of individuals who have not been included in an agreed, consent-based awareness programme.
• Physical intrusion, unless separately scoped and authorised in writing by the site owner.
• Persistence: we do not leave implants, backdoors or accounts behind. Any change made during testing is documented and reverted.

Each of these can be brought into scope, but only deliberately, in writing, and with the risks discussed first.

5. Handling what we find

Findings are the client's property. Reports are delivered over encrypted channels to named recipients only. Evidence is stored encrypted for the retention period stated in the contract and then destroyed. We publish nothing — no client names, no logos, no case studies — without specific written agreement, and our published case studies are anonymised to the point where the organisation cannot be identified.

If we find evidence of an existing compromise, or a vulnerability that puts third parties at immediate risk, we stop and contact the named escalation contact straight away rather than continuing the test.

6. Stopping

Authorisation can be withdrawn at any moment, for any reason, by the named client contact. Testing halts immediately on request, and we confirm in writing what had been performed up to that point. We also stop of our own accord if a target behaves unexpectedly, if we suspect we have moved outside the agreed scope, or if continuing would risk service availability.

7. Work we decline

We regularly turn down enquiries. The recurring categories are requests to access an account or device belonging to a partner, family member or employee; requests to test a competitor; requests to recover data from a system the requester cannot demonstrate ownership of; and requests to leave access in place after an engagement ends. We do not provide these services at any price, and we do not refer them elsewhere.

8. Legal framework

Our work is carried out under Portuguese and EU law, including Law 109/2009 on cybercrime and the GDPR. Authorised security testing performed within a contractual scope is lawful; the same activity without authorisation is not, which is precisely why the authorisation step is not negotiable for us. Personal data encountered during an engagement is processed as described in our Privacy Policy, and the commercial terms are set out in our Terms of Service.

9. Questions and disclosures

If you believe an engagement has affected you, if you want to verify that a test you have noticed is authorised, or if you want to report a security issue in our own systems, write to [email protected]. We answer within one business day.

If you have received traffic you believe came from us and you have not authorised a test, contact us immediately with the timestamps and source addresses. We will verify against our engagement records and confirm within the same business day.