Melina Security conducts offensive-security engagements under written Rules of Engagement (ROE) that establish what we will and will not do during testing, what evidence we capture, how we handle sensitive data discovered during testing, and how we escalate findings or scope concerns. The ROE document is part of every Statement of Work and is signed by both Melina and the client before testing begins.
This page summarizes the standing ROE that informs engagement-specific ROE documents. For the engagement-specific document, see the SOW you receive after Scoping & Proposal.
1. Authorization
We do not begin technical testing on any system without:
- A signed Statement of Work specifying the in-scope systems by identifier (domain, IP range, device serial, firmware build, repository, etc.)
- A signed ROE document attached to or referenced by the SOW
- Written confirmation from a client signatory with authority over the in-scope systems
- For third-party assets (cloud providers, vendor-controlled infrastructure, partner systems), additional authorization from the responsible party before testing those components
If during testing we discover an asset that is in scope by reference (e.g., “all cloud infrastructure of company X”) but turns out to be operated by a third party not represented in the SOW, we pause testing on that asset and request additional authorization before resuming. We do not assume implicit authorization.
2. Testing scope and boundaries
Testing scope is concrete in/out-of-scope lists agreed in the SOW. The ROE document specifies:
- What we test — systems, components, attack surfaces, time windows
- What we do not test — exclusions, including any system the client wants protected from disruption
- Acceptable impact levels — read-only / non-destructive / destructive in lab only / destructive in production permitted
- Time-of-day windows — for engagements where testing impact must be confined to maintenance hours
- Pre-coordination requirements — for actions that require notice to a SOC, IT operations, or law enforcement liaison
If during testing we identify an attack path that crosses an out-of-scope boundary, we pause that line of testing and document the path. We do not exploit it without amended authorization.
3. Evidence handling
We capture evidence of findings — screenshots, network captures, code, sample data — only to the extent required to demonstrate the finding and inform remediation. Specifically:
- Personal data discovered during testing is captured only when necessary to demonstrate the finding; captures are minimized to the smallest subset that proves the issue; data subjects are not identified in captures unless required by the finding context; captured data is redacted in deliverables before publish
- Credentials discovered during testing (password files, keys, tokens) are captured only as fingerprints (e.g., partial value, hash, “{type:redacted}”) in deliverables; full values are recorded in a secure engagement file shared only with the client signatory and destroyed at engagement close per the retention policy
- Proprietary code or design artifacts are captured only when necessary to demonstrate the finding; not redistributed outside the engagement team
- Captured artifacts are encrypted in transit and at rest within Melina’s engagement infrastructure; access is limited to the engagement team
- Retention: captured evidence is retained for 90 days after engagement close to support remediation verification, then destroyed unless the client explicitly requests longer retention for compliance reasons (see Security & Data Handling for retention details)
4. What we do not do
The following actions are excluded from all engagements unless specifically authorized in writing in the SOW + ROE:
- Destructive actions in production without explicit time-window authorization (data deletion, configuration changes that affect availability, denial-of-service)
- Social engineering against named individuals (we conduct social engineering only against the client’s organization as a whole, with HR notification, and never with personal coercion or impersonation that would damage individual reputation)
- Bribery or solicitation of corrupt acts by any client employee or contractor
- Real-world physical harm risk (we conduct physical-security assessment only in environments where physical risk is contained — e.g., we do not actually trigger fire-suppression systems, evacuate buildings, or activate emergency systems)
- Exfiltration of large data volumes beyond what is necessary to demonstrate the finding
- Actions against systems we are not authorized to test, including third-party systems incidentally reachable from in-scope systems
- Reverse engineering of vendor software for purposes outside the engagement scope (we do not produce general-purpose deobfuscated firmware copies for clients to redistribute)
- Actions that violate the laws of the jurisdiction where the system is hosted or where Melina personnel are operating from
5. Sensitive findings handling
If during testing we discover any of the following, we pause testing on the relevant attack path and notify the client signatory directly within the same business day:
- Evidence of an active or recent breach by a third party (not Melina) — we recommend the client initiate incident response and may pause our engagement to avoid contaminating the investigation
- Evidence of insider threat or unauthorized access by client personnel
- Information that suggests the client is in legal jeopardy (e.g., evidence of regulatory violation, evidence of a data breach not previously known)
- Personal data of categories considered sensitive under PIPL, GDPR, or other applicable law (children’s data, biometric data, health data) that is exposed in a manner the client may not be aware of
- Trade secrets or material non-public information that is exposed in a manner the client may not be aware of
These findings are reported through a dedicated handling path separate from the standard finding-report workflow.
6. Communication during engagement
- Status updates: weekly written update + ad-hoc immediate notification for high-severity findings
- Escalation: named escalation path with a primary client contact and a backup contact
- High-severity findings are surfaced immediately rather than batched in the final report; clients should not learn about critical vulnerabilities at the closing meeting
- Channel of record: all formal communication occurs through the channel specified in the SOW (typically encrypted email + a shared document workspace); informal discussion is not authorization
7. Reporting and disclosure
Reports are delivered bilingual EN + 中文 per our standard methodology. Findings are scored per CVSS, mapped to relevant frameworks (OWASP, MITRE ATT&CK, ISO/SAE 21434, OWASP LLM Top 10, etc.) where applicable, and accompanied by remediation guidance and time-to-fix estimates.
For findings that meet the threshold for public disclosure (typically: confirmed CVE candidates affecting widely deployed systems with no available patch), disclosure follows our Responsible Disclosure policy. We coordinate with the affected vendor and the client to time disclosure responsibly.
8. End of engagement
At engagement close:
- All captured evidence is reviewed for retention vs destruction per the retention policy
- Credentials discovered during testing are reported to the client for rotation; we destroy our copies once rotation is confirmed
- The 60-day remediation re-check is scheduled (see Re-check)
- A close-out memo is delivered with the engagement summary, deliverables index, and re-check appointment
9. Disputes and amendments
Any dispute over scope, ROE interpretation, or finding accuracy is resolved through direct discussion with the client signatory. Amendments to the ROE during the engagement require written confirmation from both parties before they take effect. We do not act on verbal amendments.
If the dispute cannot be resolved, the engagement is paused pending resolution and the SOW dispute-resolution clause is invoked.
10. Standing commitments
Beyond engagement-specific ROE, Melina makes the following standing commitments:
- No undisclosed conflicts: we disclose any prior relationship with a vendor whose product we are testing
- No vendor relationships that bias scoring: we do not accept vendor sponsorship that would bias finding-severity assessment
- No use of clients’ findings as marketing material without explicit consent (case studies require client permission per content-types.md type #12)
- No retention of client material beyond what’s necessary for delivery and re-check (per the Security & Data Handling policy)
11. Contact
Questions about Rules of Engagement: contact@melinasec.com.
For active engagements, contact your service lead (Tatiana K. — IoT / Automotive / Robotics; Gleb Z. — AI/ML / AppSec / Cloud) directly through the channel established in your SOW.
Authorized testing disclaimer
All testing performed by Melina Security is conducted under signed authorization. Unauthorized access to systems is illegal in most jurisdictions and is not covered by these Rules of Engagement.