How we handle offensive and defensive security work
EINEVA Labs works on both sides of security. Our offensive work is penetration testing, red teaming, and vulnerability research. Our defensive work is monitoring, hardening, incident response, and secure engineering. The offensive side exists only to serve the defensive side.
We are a research lab, not an actor in the threat economy. We do not break into systems for access, do not sell access or data, do not deploy ransomware, and do not build tools intended to harm people or infrastructure. Everything we do is meant to leave a client stronger than we found it.
No offensive work begins until the following are in place and in writing:
Verbal permission, implied permission, or an assumption that a system is "probably fine to test" is never sufficient. If authorisation is unclear, we pause until it is resolved in writing.
Every engagement has documented rules of engagement agreed before any testing occurs. These normally set out the testing window and time zone, the techniques that are permitted and those that are prohibited, the test accounts and IP addresses we will use, the escalation path, and the stop conditions that end testing immediately.
We stay strictly inside that agreed boundary. Discovering a system that is not in scope does not entitle us to test it; it becomes a finding we report to the client instead.
We are assessing your security, not disrupting your business. Our default approach is to avoid actions that could degrade service, corrupt data, or affect real users, even where such an action would technically be within scope. Destructive techniques, denial-of-service testing, and social engineering of your staff are excluded unless the client requests them in writing as a specific, separately agreed objective.
Assessment evidence is sensitive and treated accordingly. We collect the minimum data needed to demonstrate a finding, avoid copying production or personal data unless it is strictly necessary and specifically agreed, encrypt evidence in transit and at rest, restrict access to the named engagement team, and return or securely destroy all client data and credentials on request or at the end of the engagement.
Findings are reported to the client first, with enough detail to reproduce and fix each issue, and with a severity rating and a practical remediation path. We agree a disclosure timeline with the client so they can remediate before anything becomes public.
We do not publish client details, working methods, or exploit code that would harm the client without their written consent. Where a vulnerability affects a system we do not own, we follow a coordinated disclosure process and give the owner a reasonable opportunity to fix it.
These are firm limits on our work, in any engagement and in any research we publish:
We operate in accordance with applicable law, including Zimbabwe's cybercrime legislation and the laws of each jurisdiction in which an engagement is performed, and we work to align with recognised professional standards and ethical codes in the security testing field. When a request would require us to act outside the law, outside the agreed scope, or outside these commitments, we decline it.
If you find a weakness in one of our own systems, please tell us rather than exploiting it. Email info@eineva.co.zw with a description of the issue and how you reproduced it. We will acknowledge your report, work to validate and fix it, and coordinate any public disclosure with you. We do not take legal action against researchers who act in good faith within this process, and we ask that you avoid accessing data, degrading service, or disrupting other users.
If you need clarification about this policy, or you want to confirm the authorisation and scope of work we are doing for you, contact us at info@eineva.co.zw or our contact page. We will put the relevant authorisation and scope documentation in writing on request.