[Partner name] | Partner-Craft POV | Engagement Report | [Client name] | Confidential
[Field: Partner logo]
About This Report
The methodology and materials contained in this document were developed in collaboration between [Partner name] and McPhail Security. All client-facing content is the property of [Partner name] for use within this engagement.
This report captures what was built, what was found, and what happens next. It is a record of decisions made and a methodology handed over.
| Field | Value |
|---|---|
| Client | [Field] |
| Partner | [Field] |
| Vendor | [Field] |
| Archetype | [Field: e.g. A4 — PKI / PQC / Crypto Lifecycle] |
| Engagement Period | [Field: Start date] – [Field: End date] |
| Engagement Lead | Mike McPhail / McPhail Security |
| Report Version | v1.0 |
| Date | [Field: Month Year] |
[Write one paragraph in plain language. Describe the specific problem this partner was trying to solve and the methodology that was built to address it. Do not use boilerplate. This should read like something a senior practitioner wrote about this specific engagement.]
Two to three paragraphs. Written to orient anyone reading this report who was not in the room. Do not use the partner’s own marketing language.
[Describe the partner’s business model, primary client base, and how they typically go to market. Include sector focus, geographic focus, and deal size if relevant.]
[Describe the partner’s typical client: sector, size, the role of the buyer, and the problems those clients are most focused on. Use the language that surfaced in the discovery sessions, not the vendor’s language.]
[Describe specifically what the partner came in without and what this engagement was designed to give them. Be candid. This section should explain why a generic vendor kit would not have worked.]
Use the archetype-specific version from the Archetype Variants section at the end of this document
[Replace this placeholder with the relevant Engagement Motion from the Archetype Variants section below.]
The partner now owns the following facilitated session structure:
| Session | Focus | Who’s in the Room | Output |
|---|---|---|---|
| Kickoff | Scope alignment, partner discovery, vendor role setting | Partner lead, vendor, MM | Completed Discovery Questionnaire |
| Session 2 | [Archetype-specific focus] | Partner lead, MM | Session output summary |
| Session 3 | [Archetype-specific focus] | Partner lead, MM, vendor on request | Draft methodology package |
| Session 4 | [Archetype-specific focus] | Partner lead, MM | Refined methodology |
| Session 5* | [Archetype-specific focus — if applicable] | Partner lead, MM, vendor | Complete engagement package |
* Session 5 applies to archetypes A2, A3, and A6 only.
[Summarize the three to five most effective discovery questions that emerged from the session worksheets. These are not the generic worksheet questions — they are the refined versions that actually landed in this engagement.]
| Document | Description | Location |
|---|---|---|
| Session Facilitation Guide | MM-facing: how to run each session, prompts, timing | [Shared folder] |
| Client Session Worksheet | Used in-session with client to capture structured outputs | [Shared folder] |
| Gap Analysis Tracker | All gaps identified during engagement, with resolution status | [Shared folder] |
| Engagement Status Tracker | Phase, milestone, action item, session, and risk records | [Shared folder] |
| Engagement Report (this document) | End-of-engagement deliverable under partner brand | [Shared folder] |
Drawn from the completed Gap Analysis Tracker. Vendor Summary tab. All client and partner-specific context removed.
[List gaps that were identified and resolved before engagement close. For each: what the gap was, how it was resolved, and who resolved it.]
This section may be shared with the vendor with the partner’s knowledge and agreement. Written clearly enough that the vendor can act without follow-up questions.
[List gaps that require vendor action. For each: what the gap is, why it matters, and what specifically the vendor needs to produce or address. Be direct.]
[List gaps that were identified, discussed, and accepted as known limitations. Include any agreed workarounds. A clean list here shows the engagement was thorough, not that the vendor is deficient.]
Three to five specific, actionable recommendations. Not generic best practice. Every recommendation must be tied to something that surfaced in this engagement.
What: [The specific action]
Why: [What specific engagement finding this addresses]
Who: [Who owns it]
By when: [Realistic timeframe]
What: [The specific action]
Why: [What specific engagement finding this addresses]
Who: [Who owns it]
By when: [Realistic timeframe]
What: [The specific action]
Why: [What specific engagement finding this addresses]
Who: [Who owns it]
By when: [Realistic timeframe]
Populated in the final session with the partner and vendor present. Nothing goes in here that was not agreed in the room.
| Action | Owner | Due Date |
|---|---|---|
| [Field] | [Field] | [Field] |
| [Field] | [Field] | [Field] |
| [Field] | [Field] | [Field] |
| [Field] | [Field] | [Field] |
| [Field] | [Field] | [Field] |
| [Field] | [Field] | [Field] |
Internal and partner use only — not shared with vendor unless partner explicitly agrees
[Two to three specific observations about what worked in this engagement. Not generic praise. Specific dynamics, decisions, or structural choices that produced good outcomes.]
[Two to three honest observations about what would be done differently. Session structure, timing, vendor management, partner preparation. Be specific enough to be actionable.]
[Any patterns in how this vendor and partner interact that are relevant to future engagements. Power dynamics, trust levels, communication styles, gaps in mutual understanding. Write it plainly.]
Section 3.1 — Engagement Motion
Use the version below that matches your engagement. Replace Section 3.1 in the report with the relevant archetype motion. All other sections remain identical.
e.g. Mimic and similar established security vendors
The partner enters client conversations through existing security review relationships or incident-driven conversations. The vendor’s capability is positioned not as a new product category but as a measurable improvement on what the client is already doing. The discovery conversation focuses on where the client feels most exposed and least confident in their current stack. The progression moves from exposure mapping to a focused proof of concept scoped around one realistic threat scenario, with a clear success criterion agreed before the POC begins.
e.g. WI-SUN Alliance, Toyota Tsusho context
The partner enters through existing OT or industrial relationships, often at the engineering or operations level rather than through the CISO. The conversation starts with operational continuity and production risk, not security posture. Security is introduced as a condition of operational reliability, not as a separate discipline. The progression moves from operational impact mapping to IT/OT boundary assessment to a scoped engagement that produces a clear picture of OT exposure without requiring the client to have a mature security program already in place.
e.g. WitnessAI and AI governance vendors
The partner enters through existing compliance or governance relationships, often with legal, risk, or the CIO rather than the CISO. The conversation starts with regulatory exposure and board-level AI risk, not with product capability. The vendor’s solution is positioned as a governance and oversight layer, not as a surveillance or control product. The progression moves from regulatory mapping to a data handling assessment to a scoped pilot that produces evidence of compliance posture improvement, with data residency and sovereignty addressed explicitly before any technical work begins.
e.g. Keyfactor, OmniTrust
The partner enters through existing infrastructure or compliance relationships. The conversation starts with certificate visibility and operational risk: outages, expired certificates, and audit findings are the most common entry points. Quantum risk is introduced once the client has acknowledged that their current crypto posture is not fully visible or managed. The progression moves from certificate discovery to inventory assessment to a PQC readiness conversation anchored to a specific regulatory timeline the client already has on their radar.
e.g. Northern Tech Mender
The partner enters through existing managed service or infrastructure relationships. The conversation starts with the gap between what the client believes their patch status to be and what it actually is. The vendor’s capability is positioned as a managed remediation motion, not a point tool. The progression moves from hygiene baseline assessment to a prioritized remediation roadmap to a recurring managed service model that gives the client continuous visibility and the partner a predictable revenue stream.
e.g. Agentic SOC vendors, autonomous detection and response
The partner enters through existing SOC, MSSP, or security operations relationships, often where the client has expressed frustration with their current provider’s responsiveness or visibility. The conversation starts with what the client does not know about their own environment and what decisions they are currently unable to make because the intelligence sits with a third party. The vendor’s capability is positioned as returning control and intelligence to the client, not as replacing one outsourced service with another. The progression moves from current state SOC assessment to a detection engineering readiness conversation to a structured transition plan that the client owns and the partner delivers.