How to prepare for an engagement

Preparation decides how much of an engagement is spent on the work and how much on waiting. Three things need to exist before the first day: a scope written down, read-only access provisioned, and named people who can settle a question without escalating it. This article covers all three, in the order they tend to block each other. The authoritative inputs sheet for each engagement sits on its own page in the engagement catalogue, and nothing here restates it.

#Choose the engagement first

Preparation differs by engagement, so the choice comes before the checklist. What each one covers, and what it explicitly does not, is set out on its own page; the Scope Builder assembles a combined scope summary if more than one applies. One distinction matters for preparation. Four engagements open from a scope you nominate. Migration Engineering and the Executive Briefing open from an exposure position that already exists, and if none exists an Estate Inventory is the usual way to produce one.

#The shape of every inputs sheet

Each engagement page carries an inputs sheet, and every sheet uses the same small set of headings. Knowing what each heading asks for is most of the preparation.

Duration

Stated on the engagement page and nowhere else. It is a placeholder there today, and an unfilled figure is better than a plausible one.

Scope you nominate

The repositories, environments, hostnames, certificate authorities, key services or host fleets in scope, agreed in writing before we begin.

Precondition

A current Exposure Register, or an equivalent exposure position your own team holds. Carried instead of a scope list by Migration Engineering and the Executive Briefing.

Access we need

Read-only access to the surfaces named on that engagement page. Metadata and configuration, never key material.

People we need

Named owners who can answer a question and settle a scope dispute inside one conversation. The roles are listed per engagement below.

What we never ask for

Private keys, production credentials, customer data, and write access to anything. The companion article, What we ask for and what we never ask for, states this in full.

Handover

A walkthrough of the output with the owners who will act on it. Book it at the same time as the kickoff, not after the report lands.

#Who needs to be available

A named owner who can decide is worth more than three who can only escalate. These are the roles each engagement page asks for.

#Access is read-only, and metadata rather than material

Every engagement in the catalogue reads. None of them writes. The access we ask for falls into a small number of categories, and each has a read-only form your platform team can issue and revoke without our involvement.

• Source and build metadata. Repositories, dependency manifests, the library versions a build actually resolves, and the pipeline steps that sign what you ship.
• Deployed configuration. Cipher suites, algorithm parameters and protocol versions as deployed rather than as documented, read from your configuration management or from a non-production environment representative of production.
• Certificate inventories. Issuers, chains, key types, key sizes and validity windows, including internally issued material.
• Key metadata and policy. Algorithm, size, purpose, state, custody boundary and rotation history. Metadata, not material.
• Issuer metadata and published key sets. Token and assertion signing configuration, published key sets, and host key inventories.
• A representative environment and a load profile. Migration Engineering measures performance on your own workload, which needs somewhere to measure it and traffic that resembles production.

#The sequence before kickoff

1. 1

   Pick the engagement

   Read the scope band on its page in the engagement catalogue. If more than one applies, the Scope Builder assembles the engagements, the artefacts and the inputs into one summary you can circulate.

2. 2

   Write the boundary down

   Business units, environments, regions, repositories, hostnames, key stores and appliances in scope, and everything explicitly out of scope. A boundary that two people describe differently is a finding, and it is cheaper to settle now than mid-run.

3. 3

   Nominate the scope in writing

   The written scope is what the work is measured against and what the Posture Attestation names. An asset outside it is reported as uncovered, never as safe.

4. 4

   Provision read-only access

   Issue credentials scoped to the agreed sources, held and revocable by your own team. Confirm every source is reachable before the start date rather than on it.

5. 5

   Name the people

   One owner per in-scope system, plus the roles in the table above for the engagement you chose. Where a role has no current owner, say so; unowned cryptography is one of the more common findings.

6. 6

   Book the handover

   The closing walkthrough is where triage starts, so the people who will do the triage need to be in it. Put it in diaries alongside the kickoff.

How long the preparation itself takes depends almost entirely on how quickly access requests clear in your organisation, which is usually the longest pole. [PLACEHOLDER: lead time between an agreed scope and a kickoff date]

#If you are preparing for a platform assessment instead

An engagement and a first assessment inside the platform need the same discipline in different order. The Knowledge Base covers the platform side in What to have ready before we start and What the first thirty days look like. The task-based topics on the Help Desk cover the mechanics: connecting a source, setting the estate boundary, and provisioning read-only access.