vCISO Client Onboarding Checklist

What this checklist is for

A signed contract is not an operating model. The first month of a vCISO engagement has to establish what the client expects, what evidence exists and who can make decisions. If those facts remain vague, the first risk assessment becomes a long request list and the roadmap becomes guesswork.

This checklist is designed for an MSP onboarding a new vCISO client. It can also be used by an independent vCISO or an internal security lead taking over an existing programme. It follows a simple sequence: confirm the mandate, collect the minimum evidence, establish the current position, agree priorities and put a delivery rhythm in place.

The checklist is deliberately not tied to one framework. NIST explains that an organisation can use a Current Profile to describe its present outcomes and a Target Profile to describe the outcomes it wants to achieve. That distinction is useful during onboarding because it separates observed facts from the future plan.

Before the kickoff meeting

Complete these items as soon as the engagement is signed. Do not wait for the first workshop to discover a scope disagreement.

• Store the signed scope of work, order form and relevant proposal in the delivery workspace.
• Record the legal entities, business units, locations and systems included in the engagement.
• List explicit exclusions, such as penetration testing, 24-hour incident response or hands-on remediation.
• Name the client sponsor and the person authorised to accept risks and approve priorities.
• Name the operational contacts for IT, cloud, HR, legal, privacy, procurement and business continuity.
• Confirm the primary framework or control set, if one has been agreed.
• Record regulatory, customer and insurance obligations already known to the client.
• Agree how sensitive evidence will be transferred, stored, retained and deleted.
• Schedule the kickoff, evidence review and first steering meeting.

Send a short pre-read rather than a large questionnaire. It should explain the purpose of onboarding, the people needed and the decisions expected. Clients respond better when they know why each person is in the room.

Kickoff meeting agenda

Use 60 to 90 minutes. The objective is not to complete an assessment in the meeting. It is to establish the engagement rules and expose assumptions early.

1. Confirm business context

Ask the sponsor to describe the business in practical terms:

• Which services or products create revenue?
• Which systems would stop those services if unavailable?
• What sensitive data is held, where and for whom?
• Which customers, regulators or partners can impose security requirements?
• What changes are planned in the next 12 months, such as acquisitions, new markets or major platform migrations?

Capture answers in the client’s language. A board is more likely to act on a risk to customer payments than a risk labelled only as “PR.AA-01”. Framework references can be attached afterwards.

2. Reconfirm the mandate

Read back the outcomes, boundaries and decision rights. Clarify whether the vCISO advises, approves, operates or assures each workstream. Confirm who owns remediation. An MSP can coordinate a plan without owning every technical change.

3. Agree ways of working

Set the meeting cadence, reporting dates, escalation route and normal response times. Decide where actions, evidence, risks and decisions will be recorded. Avoid spreading the working record across email threads, spreadsheets and ticketing systems without a clear source of truth.

Minimum evidence request

Ask for evidence in waves. Start with documents and system outputs that materially affect the baseline. A 100-item request on day one usually creates delay without improving the assessment.

Organisation and governance

• Organisation chart and named technology or security responsibilities.
• Current security policies and the policy approval record.
• Previous risk assessments, audits, penetration tests or certification reports.
• Security-related customer contracts, regulatory notices and cyber insurance conditions.
• Current security roadmap, budget and open audit actions.

Technology and access

• Asset inventory or the best available substitute.
• Identity provider configuration summary and privileged access list.
• Endpoint, server, cloud and network security tool inventory.
• Recent vulnerability, patching and backup reports.
• Logging, alerting and managed detection coverage.
• Critical supplier and software-as-a-service inventory.

Resilience and response

• Incident response plan and recent exercise report.
• Business continuity and disaster recovery plans.
• Backup scope, test results and recovery objectives.
• Contact list for legal, privacy, insurance, communications and external response support.

For each request, state the reason, expected format, owner and due date. Mark evidence as received, unavailable, outdated or not applicable. “No document exists” is a finding, not a reason to keep chasing the same request.

Establish the current profile

Use interviews and evidence together. A policy saying that multifactor authentication is required does not prove that it covers administrators, remote access and cloud applications. Conversely, a missing policy does not mean no control operates.

For each outcome you assess, record:

1. Observed state: what the evidence and interviews show.
2. Evidence reference: the document, configuration or report that supports the observation.
3. Gap or exposure: the difference between the current state and the required outcome.
4. Business effect: which service, obligation or decision is affected.
5. Confidence: high, medium or low, based on evidence quality.

Use CISA’s Cybersecurity Performance Goals as a useful check for a minimum baseline, particularly where a smaller client has no established control set. They are a starting point, not a substitute for the client’s legal, contractual and sector requirements.

Build the first risk and action register

Do not turn every missing document into a top risk. Group related control gaps around plausible events and business consequences. For example, weak administrator authentication, unmanaged service accounts and limited identity logging may form one identity compromise scenario.

Each risk should contain:

• a concise event and consequence statement;
• affected business services or data;
• existing controls and evidence;
• likelihood and impact using the client’s agreed method;
• a named risk owner;
• the proposed treatment and target date;
• the decision status: treat, tolerate, transfer or terminate.

Create actions separately from risks. One risk may need several actions, and one action may reduce several risks. This makes progress reporting clearer.

Agree the 30-day delivery plan

By the end of onboarding, the sponsor should receive a short plan rather than a surprise assessment report. Divide it into three horizons.

Immediate: days 1–10

• Close any urgent exposure that can be confirmed quickly.
• Resolve missing access or evidence that blocks the baseline.
• Confirm incident escalation contacts and critical suppliers.
• Record scope changes and decisions from the kickoff.

Baseline: days 11–20

• Complete the agreed current profile.
• Validate the main findings with control owners.
• Draft the initial risk register.
• Identify dependencies, cost ranges and delivery owners.

Decisions: days 21–30

• Present the highest-priority risks in business terms.
• Agree the target profile and near-term priorities.
• Approve the first roadmap and reporting measures.
• Record accepted risks and deferred actions explicitly.

Definition of done

Onboarding is complete when the engagement can run without relying on undocumented assumptions. Check that:

• scope, exclusions and decision rights are recorded;
• stakeholders and escalation contacts are confirmed;
• the evidence register shows what was received and what remains missing;
• the current profile has been validated with relevant owners;
• the initial risks have named owners and decision dates;
• the 30-day priorities and next reporting date are agreed;
• access to client systems and evidence follows the agreed security rules;
• the client knows what the vCISO will deliver next and what it must provide.

Common onboarding failures

Starting with a generic questionnaire. It produces answers without context. Start with the business services, obligations and scope, then request evidence that tests the relevant outcomes.

Treating framework completion as the objective. A framework structures the work; it does not decide the client’s risk appetite or priorities.

Accepting verbal assurance as evidence. Record it as an interview statement and seek corroborating evidence. Be clear about confidence when evidence is unavailable.

Leaving ownership implicit. Every risk, action and decision needs a named client owner. The vCISO facilitates and advises, but the client remains accountable for its risks.

Promising a finished programme in 30 days. The first month should produce a defensible baseline and an agreed plan. Remediation and assurance continue after onboarding.

Handoff note for the client

End the onboarding phase with a one-page note. State what was reviewed, what could not be verified, the three to five decisions required, the immediate actions and the next reporting date. Attach the detailed evidence, risk and action registers rather than forcing all detail into the executive summary.

That note becomes the reference point for the engagement. When scope, evidence or priorities change, update the record and explain the effect on the roadmap. A disciplined handoff prevents the assessment from becoming a static document and gives the MSP a repeatable starting point for every new vCISO client.