**How a Melina engagement runs, from first call to remediation re-check** Our methodology is locked at six stages. It's consistent across services and verticals — IoT, automotive, AI/ML, robotics, cloud, GRC. We document each stage publicly because methodology transparency is part of how we earn trust with engineering teams that have been burned by vendors who treat process as proprietary. [Talk to us about a project →](/contact/request-assessment/) --- ## The six stages at a glance 1. **[Discovery Call](/methodology/discovery/)** — 30-60 minutes. No commitment. 2. **[Scoping & Proposal](/methodology/scoping/)** — written SOW with concrete in/out-of-scope. 3. **[Threat Modeling](/methodology/threat-modeling/)** — STRIDE / PASTA / LINDDUN applied to your system. 4. **[Testing & Exploitation](/methodology/testing/)** — exploit-validated, not scanner-flagged. 5. **[Reporting](/methodology/reporting/)** — bilingual EN+ZH; executive + technical layers. 6. **[Remediation Re-check](/methodology/re-check/)** — 60-day verification window. Total engagement runs 3–10 weeks depending on scope; re-check appointment scheduled 60 days after engagement close. --- ## Why six stages, locked Most offensive-security firms collapse Discovery and Scoping into a single sales call. We separate them because they have different goals: - **Discovery** is for understanding the system. Sales pressure here corrupts the technical decision. - **Scoping** is for defining the engagement. Without a clean discovery first, scoping defaults to what the buyer already thinks they need — which is often not what they need. We also separate Reporting from Remediation Re-check, because most engagements end at the report. We end at re-check. The 60-day window — locked per our [Architecture Decisions §6](/about/company/#architecture-decisions) — is what makes the engagement complete. A report without follow-up verification is a document; a report plus a re-check is a closed remediation loop. --- ## Stage 1 — Discovery Call [Discovery Call detail page →](/methodology/discovery/) A 30-60 minute call with the service lead (Tatiana for IoT / Auto / Robotics; Gleb for AI-ML / AppSec / Cloud). The goal is to understand the system, your threat model, and what success looks like. No commitment is required at this stage. If a discovery call doesn't lead to an engagement, that's fine — we'd rather not start a project than start a project scoped on guesswork. The discovery call is also where we check whether Melina is the right firm. Sometimes the right answer is "this is outside our depth" — automotive cybersecurity for OEMs without a connected vehicle is not a Melina engagement; ICS pentest for a power utility's substation is not a Melina engagement. We say so during discovery rather than during reporting. --- ## Stage 2 — Scoping & Proposal [Scoping & Proposal detail page →](/methodology/scoping/) Output of this stage: a written Statement of Work with concrete in/out-of-scope listings, Rules of Engagement, timeline, deliverables, and pricing. We don't proceed without a signed SOW; we don't ask for verbal commitments. The Rules of Engagement document — derived from our published [Rules of Engagement](/trust/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. --- ## Stage 3 — Threat Modeling [Threat Modeling detail page →](/methodology/threat-modeling/) We apply STRIDE, PASTA, or LINDDUN depending on the system class — STRIDE for general application threat modeling, PASTA for process-oriented engagements with stakeholders, LINDDUN for privacy-driven work (particularly relevant for PIPL-compliance engagements). For automotive engagements we use TARA per ISO/SAE 21434. Threat modeling identifies the attack surface and prioritizes testing depth. It's also where we surface architectural issues that would not appear during testing — issues you can fix in design rather than patch later. --- ## Stage 4 — Testing & Exploitation [Testing & Exploitation detail page →](/methodology/testing/) 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. This stage runs 2–6 weeks depending on system scope. 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. --- ## Stage 5 — Reporting [Reporting detail page →](/methodology/reporting/) Bilingual EN+ZH report with two distinct audiences: - **Executive summary** (3-5 pages) — decision-maker readable. Risk framing, business impact, recommended actions, time-to-fix budget. - **Technical findings** — one section per finding with reproduction steps, evidence files (screenshots, code, captures), CVSS rating, exploit complexity rating, remediation guidance, time-to-fix estimate. The bilingual mandate is not translation. Each language version is reviewed by a technical reader fluent in that language for accuracy. The reporting workshop — a 2-hour synchronous deep-dive with your engineering team — is included on Standard+ engagements. --- ## Stage 6 — Remediation Re-check [Remediation Re-check detail page →](/methodology/re-check/) Within **60 days** of engagement close, we verify that remediations work and findings are closed. This is included on Standard+ engagements per our [locked Architecture Decisions §6](/about/company/#architecture-decisions). The 60-day window is chosen deliberately. 30 days is too short — engineering teams haven't shipped the fix. 90 days is too long — the assessment context starts to fade. 60 days matches typical remediation cycles for high-severity findings in a competent engineering organization. Re-check is not a re-test of the entire scope. It's targeted verification of specific findings: did the fix work, did it introduce regression, did it cover all instances of the underlying issue. If we find that a fix is incomplete or introduces new failure modes, we document it and your team has a clear next-step list. --- ## Statistics across our engagements --- ## See it in practice For day-by-day detail including a sample evidence package, NDA flow, and how a typical engagement closes, see: **[Inside a Melina Engagement →](/methodology/inside-an-engagement/)** --- ## Authorized testing disclaimer All techniques applied during Melina engagements are performed under authorized rules of engagement with the system owner per a signed Statement of Work and a Rules of Engagement document. Unauthorized access to systems is illegal. --- ## Ready to start? [Request Assessment →](/contact/request-assessment/) — a discovery call with the service lead takes 30 minutes and is the first stage of this methodology.