Six stages, locked.

A short call with the service lead. The goal is to understand your system, threat model, and what success looks like — no commitment, no sales pressure.

Tatiana leads discovery for IoT, automotive, and robotics; Gleb leads for AI/ML, application security, and cloud.

Discovery is also where we check whether Melina is the right firm. Sometimes the answer is "this is outside our depth" — for instance, ICS pentest for a power utility substation is not a Melina engagement. We say so during discovery rather than during reporting.

A written Statement of Work with concrete in-scope and out-of-scope listings, Rules of Engagement, timeline, deliverables, and pricing.

We do not proceed without a signed SOW; we do not ask for verbal commitments.

The Rules of Engagement document — derived from our published Rules of Engagement policy — establishes what we will and will not do, what evidence we capture, how we handle sensitive data discovered during testing, how we disclose findings to the vendor if applicable, and the escalation path if we encounter anything outside scope.

STRIDE, PASTA, or LINDDUN depending on system class. TARA per ISO/SAE 21434 for automotive engagements.

STRIDE for general application threat modeling, PASTA for process-oriented engagements with stakeholders, LINDDUN for privacy-driven work (particularly relevant for PIPL-compliance engagements).

Threat modeling identifies the attack surface and prioritises testing depth. It is also where we surface architectural issues that would not appear during testing — issues you can fix in design rather than patch later.

Exploit-validated findings. Every reported finding has been demonstrated end-to-end. We do not report scanner output. We do not report "potential vulnerabilities" without proof.

Hardware-heavy engagements (silicon teardown, fault injection) extend testing; cloud-only engagements compress it.

We send weekly status updates and surface high-severity findings immediately rather than batching them for the final report — buyers should not learn about critical vulnerabilities at the closing meeting.

Bilingual EN + 中文 report with two layers: an executive summary for decision-makers and a technical findings section for engineering.

Executive summary (3–5 pages): risk framing, business impact, recommended actions, time-to-fix budget. Decision-maker readable.

Technical findings: one section per finding with reproduction steps, evidence files (screenshots, code, captures), CVSS rating, exploit complexity, remediation guidance, time-to-fix estimate.

Each language version is reviewed by a technical reader fluent in that language for accuracy — not translated. The reporting workshop, a 2-hour synchronous deep-dive with your engineering team, is included on standard+ engagements.

We verify that remediations work and findings are closed. The engagement does not close until remediation holds.

The 60-day window is chosen deliberately. 30 days is too short — engineering teams have not shipped the fix. 90 days is too long — assessment context starts to fade. 60 days matches typical remediation cycles for high-severity findings in a competent engineering organisation.

Re-check is not a re-test of the entire scope. It is targeted verification of specific findings: did the fix work, did it introduce regression, did it cover all instances of the underlying issue. If a fix is incomplete or introduces new failure modes, we document it and your team has a clear next-step list.