How to onboard a new security client without losing the first three weeks to email tag.
This is the actual process, written down. Pre-engagement questions, intake forms, the access you need on day one, the kickoff, and the first 90 days. Every template is here to copy and use. Nothing is held back.
These are blank templates. No client data lives in this repo, and none ever will.
Most security engagements start badly. Not because the consultant is bad. Because nobody agreed on what "done" looks like, who decides, or what access is needed. Three weeks later everyone is frustrated and the work has not started.
The fix is boring. Ask better questions before you sign. Ask for the right access on day one. Say out loud what you will not do. Write the first 90 days down.
That is all this repo is.
- Fractional CISOs and vCISOs starting a new engagement
- Consultants and small security firms who keep rebuilding the same intake forms
- Internal security leaders inheriting a program and needing the same answers
- Clients who want to see how a good consultant works before hiring one
If you are a buyer, read pre-engagement/discovery-questionnaire.md. If a consultant is not asking most of that, keep shopping.
- Copy this repo, or just copy the files you need
- Work through the folders in order. They are numbered by when you need them
- For the fastest start, send the eight one-pagers in
forms/. One page per person beats one giant document for everyone - Keep the filled-in copies somewhere private. Not here, not in any public repo
- Delete what does not apply. A form nobody answers is worse than no form
| Folder | When | What is in it |
|---|---|---|
forms/ |
Send on day one | Eight one-page fill-in sheets, split by who answers them. Start here |
pre-engagement/ |
Before you quote | Discovery questions, scoping, go or no-go, red flags |
intake/ |
After signing, before kickoff | Tech stack, compliance drivers, incident history, vendors, data map |
access/ |
Week one | What access you need, what you should refuse, how to ask |
legal/ |
Before work starts | Scope boundaries, document checklist, authorization letter |
kickoff/ |
Week one | Agenda, stakeholder map, RACI, communication norms |
first-90/ |
Weeks one to thirteen | 30/60/90 plan, week one checklist |
evidence/ |
Rolling | The document request list |
offboarding/ |
The end | Handover, data destruction, credential return |
If you read nothing else:
- Ask what they are afraid of. The real driver is usually a lost deal, a scary insurance renewal, or a near miss nobody talks about
- Get read access, not admin. You are there to see, not to change. Admin comes later, if ever, and with a reason
- Write down what you will not do. Scope creep kills engagements faster than bad work
- Name one decision maker. Not a committee. One person who can say yes
- Plan the exit on day one. The client should be able to run the program without you
- Security-Program-Starter for the policies you will hand them
- vCISO-Playbook for how to run the engagement once it starts
- The-Board-One-Pager for reporting up
- TPRM-RightSized for the vendor work that always follows
CC BY 4.0. Use it, change it, sell services with it. Credit is nice, not required.
There isn't one. The value is doing the work, not owning the checklist. Take all of it.