How Securem Runs a Written Security Review: The Fixed-Scope Method, in Full

What "security review" should mean, and what it usually doesn't A regulated mid-market organization shopping for a security review encounters two market shapes that do not survive contact with a regulator. The first is the vendor scorecard. A third-party tool, sometimes open-source, sometimes a commercial scanner, runs against the buyer's environment, produces a branded PDF with a numeric score, lists findings categorized by CIS Benchmark or vendor-specific reference, and recommends a remediation queue. The artifact is a configuration scan dressed as an assessment. The artifact does not survive an auditor's first follow-up question because the artifact's evidence is the scanner's output, not a structured review of the architecture against the controls the regulator cites. The second shape is the consulting narrative. A boutique firm writes a forty-page document with executive narrative, architectural commentary, anonymized peer comparisons, and a strategic-recommendations section. The artifact reads well and tells the audit committee what they hoped to hear. The artifact also has no testable surface, no exhibit a SOC 2 auditor can pull and reproduce, no evidence a HITRUST assessor can map to the CSF citations, no remediation calendar with control owners and target close dates. The auditor reads the document, asks for the underlying evidence, and the engagement effectively starts over. A security review, in the form a regulated mid-market buyer needs, is neither of those shapes. It is a fixed-scope, written deliverable with the structural property that every finding is backed by an evidence artifact a third party can pull and reproduce, every recommendation has a target close date and a control owner, and the deliverable structure is the same every time so the buyer's compliance function and the buyer's assessors know exactly where to look. This is the method we run. It is fixed-scope, fixed-price, three weeks long, and produces a single deliverable the buyer keeps regardless of what they do with the engagement afterward. The method has been refined across mid-market healthcare, regulated SaaS, financial services, PE-backed portfolio companies, and M&A diligence work. The cloud changes; the identity provider changes; the framework citations change. The method does not. The five phases Phase 1, Scope contract (week zero) A security review starts with a written scope contract, a one-page document signed before any data collection begins. The contract names the in-scope tenant, subscription, application set, regulated record class, framework lens, and time period. It names the access we will be granted (read-only roles in the cloud, Compliance Administrator in M365, named API tokens, named SSO accounts), the people we will interview (typically four to eight: the engineering lead, the compliance lead, the IT operations lead, the security lead, the legal lead, and the executive sponsor), and the artifacts the buyer will provide before kickoff (current architecture diagram, current control documentation, prior-engagement deliverables if any, framework-citation map if a specific framework is in scope). The scope contract is short on purpose. It is the one-page reference both sides return to when a question of scope creep arises. The line we hold: anything not in the scope contract is out of scope unless we mutually agree in writing to extend. A security review whose scope drifts during the engagement does not produce a structured deliverable; it produces an undisciplined narrative. Scope discipline is the methodological precondition. The scope contract also names the deliverable structure, the eight-to-twelve domains that will be walked, the exhibits that will be included, the remediation calendar shape, the executive summary length, and the language. Buyers occasionally ask whether the deliverable can be in the form of a slide deck. The answer is no; a slide deck is not a defensible artifact for the audits we are writing for. The deliverable is a written document; we may produce a separate executive presentation as a derivative artifact. Phase 2, Evidence collection (week one) The first working week is evidence collection. The Securem partner running the review pulls the structured artifacts the deliverable will reference: the cloud configuration exports (covered in detail in the Azure Security Review Method for Azure-shaped tenants and equivalent in the AWS Security Review for AWS-shaped tenants), the identity-provider configuration exports (covered in the M365 + Entra ID Hardening Field Guide for Microsoft tenants), the compliance-content evidence (M365 Compliance + Audit Readiness for Purview-side evidence), the application-layer evidence (HIPAA AI architecture if applicable per the HIPAA AI Architecture Field Guide), the operational evidence (recent change records, recent incident records, recent audit-log queries, recent access reviews), and the framework-citation evidence (current control documentation, prior-assessment deliverables). The partner runs the four-to-eight interviews during this week, half-hour structured conversations with each named interviewee, walking the same five questions every time: what is the workflow you are responsible for, what controls are in place around it, what is the failure mode you worry about most, what would you change if you had ninety days, what should we be asking that we are not. The interview transcripts are not part of the deliverable; the structured findings derived from them are. The week ends with an evidence index, a working spreadsheet that names every artifact collected, the domain it belongs to, the framework citations it answers for, and the gaps where evidence is missing. The index is the working baseline for phase three. Phase 3, Control testing and finding generation (week two) The second working week is control testing. Each domain in the scope contract has an audit-passing baseline, the configuration state and the evidence shape that satisfies the framework citation it maps to. The partner walks the evidence collected in phase two against the baseline, scores each control as pass / fail / conditional, and produces a structured finding for every fail or conditional. A finding has a fixed shape: the named control, the framework citations it maps to, the audit-passing baseline (one paragraph), the current state (one paragraph with the evidence reference), the gap (one paragraph), the severity (high / medium / low), the recommended remediation (specific configuration changes or procedural changes), the target close date (typically thirty / sixty / ninety days based on severity), and the control owner. A typical engagement produces twenty to forty findings. A clean tenant produces fewer; a noisy tenant produces more. Findings are not editorial. The shape is the same regardless of severity, regardless of how the buyer's team feels about the finding, and regardless of whether the engineering team agrees with the assessment. The deliverable's defensibility rests on the consistency of the finding shape, an auditor reading the deliverable can pull the evidence reference for any finding and reproduce the assessment. The week also produces the executive summary. One page. Three paragraphs. What we walked. What we found at the highest priority. What we recommend in the next thirty / sixty / ninety days. The executive summary is written last in the working sequence, after the findings are settled, but it appears first in the deliverable. Phase 4, Deliverable assembly and review (week three, days one to three) The third week opens with deliverable assembly. The structure is fixed: Executive summary (one page). Scope and method (one page), the eight-to-twelve domains, the time period, the access we used, the people we interviewed. Architecture overview (two to four pages), the tenant / subscription / management-group structure, the regulated-workload posture, the data-flow narrative for the in-scope record set. Findings by domain (eight to twelve sections, one per domain), each section: the audit-passing baseline, the current state, the findings, the evidence artifacts. Remediation calendar (two to four pages), every finding ranked by severity, with target close dates, control owners, and the evidence artifact that will answer the auditor's question once the close is in place. Exhibits, the structured evidence artifacts the buyer keeps and uses in the next audit. The assembly process is mechanical because the working artifacts have been produced in the structured shape from phase three. A typical deliverable is forty to sixty pages, with the exhibits ranging from a short structured summary to multi-page evidence pulls depending on the engagement. Days one and two of week three are assembly. Day three is internal review, a second Securem partner reads the deliverable cold, without context from the engagement, and confirms two things: that the deliverable is internally consistent (the finding evidence references resolve, the remediation calendar reconciles to the findings, the executive summary reflects what the findings actually say), and that the deliverable is reproducible (a third party reading the document can pull the cited evidence and arrive at the same finding). Anything that fails either test is reworked before delivery. Phase 5, Delivery and disposition (week three, days four and five) The fifth phase is delivery. The deliverable is presented in a one-hour structured walkthrough with the executive sponsor, the compliance lead, and any other named stakeholders the scope contract identifies. The walkthrough is not a sales pitch; it is the partner walking the deliverable's structure, the highest-priority findings, the remediation calendar, and the disposition options. The disposition options are explicit. The buyer has three paths after delivery, and the engagement letter names them up front: first, take the deliverable and execute the remediation calendar with internal resources; second, take the deliverable and engage Securem on remediation through a separate engagement letter (typically a thirty-, sixty-, or ninety-day calendar); third, take the deliverable and engage a different partner, internal or external, on the remediation. The deliverable is the buyer's regardless of the disposition. The pricing for the review does not flex on the buyer's choice. The fifth phase also closes the access we were granted in phase two. Read-only roles are deprovisioned, named tokens are revoked, the evidence collected in phase two is held for the contractual retention period (typically one year for warranty support, longer if the engagement letter or the buyer's regulatory environment requires it) and then permanently destroyed. The closure procedure is documented in the engagement letter and exercised on a defined date. What changes by engagement type The five phases are fixed. The scope contract, phase one, flexes by engagement type. The most common shapes: Adopt-AI-Safely Diagnostic. Eight domains specific to AI architecture: model selection, BAA chain, audit-log surface for AI workloads, prompt-and-completion retention, RAG and retrieval governance, agent identity and permission scope, trust architecture (covered in the Trust Architecture Field Guide), and the 12-piece agent infrastructure (covered in the Agent Infrastructure Field Guide). The deliverable is the AI-architecture-specific cousin of the general security review. Microsoft 365 + Entra Tenant Review. Twelve domains specific to identity and tenant: the twelve controls in the M365 + Entra ID Hardening Field Guide, with the remediation calendar mapped to SOC 2, HITRUST, and HIPAA citations. Azure or AWS Security Review. Eight domains specific to cloud resources, walked in the order described in the Azure Security Review Method (the AWS shape is identical with the equivalent service substitutions). SOC 2 Type II Readiness. Framework-led: the Trust Services Criteria as the organizing structure, with the five (or six, including Privacy) categories as the domain set. The SOC 2 Type II Field Guide covers the framework-level method. HITRUST r2 Readiness. Framework-led: the HITRUST CSF as the organizing structure. The HITRUST Field Guide covers the framework-level roadmap. M&A Cyber Diligence. Time-compressed scope (typically twenty-one days), tuned to the diligence window. The M&A Cyber Tech Diligence Field Guide covers the diligence-specific method, and the Carve-Out Diligence Field Guide covers the harder seller-access-restricted shape. The five-phase discipline is constant across all of these. The scope contract names the domains, and the deliverable structure adapts to the domain count. A typical engagement runs eight to twelve domains; a focused engagement (say, an Entra-only review for a tenant that has just had a privileged-access incident) might run three. The minimum-viable engagement is a single domain, but we have not yet seen a regulated mid-market buyer for whom a single-domain review was the right shape. What the deliverable is and is not Three clarifications. First, the deliverable is not a replacement for the formal audit. A SOC 2 Type II audit is performed by a licensed CPA firm; a HITRUST r2 assessment is performed by a HITRUST-authorized External Assessor; an HIPAA investigation is performed by the Office for Civil Rights. The Securem deliverable is the buyer's evidence package and remediation calendar that the licensed assessor will read. It accelerates the formal audit; it does not substitute for it. Second, the deliverable is not a marketing artifact. The buyer's compliance function may extract sections of the deliverable for the audit committee, the board, or external customers (typically the executive summary and the architecture overview). The full deliverable is internal-confidential and stays inside the buyer's compliance function. The engagement letter names the confidentiality posture explicitly. Third, the deliverable is not a one-time artifact. The audit posture compounds; the most consequential return on the security review is the second engagement where the deliverable is updated against the prior cycle and the remediation calendar's closes are reaffirmed. Buyers who operate this way produce a multi-year audit posture that scales with the business. Buyers who treat the review as a one-time event re-run the same gap analysis the next time an audit cycle starts. What we recommend A regulated mid-market organization that has not run a structured written security review in the last twelve months should run one in the next ninety days. The pricing is fixed; the scope is fixed; the deliverable is fixed; the buyer keeps the artifact regardless of what they do next. The cost of running the review is meaningfully lower than the cost of discovering the gaps during an audit cycle, and the artifact's defensibility compounds across audit cycles, M&A diligence cycles, and customer-driven security review questionnaires. The engagement-letter template is one of the artifacts paired with this Field Guide. Buyers in active diligence cycles, in framework-readiness mode, or in the position of having to answer a customer or regulator security questionnaire should reach out for the engagement scope conversation. The conversation is short, the scope is concrete, and the deliverable starts within a week. Five phases. Three weeks. One written deliverable. The method holds across cloud, identity, and framework. Run it before the next audit asks for the artifacts you have not yet built.