A project handoff needs enough context for the next person to act, even when they cannot read the original meeting notes or client files.
Write a short, permitted action brief: the task, the relevant decision, the materials the recipient can use, the limits on the work, and who resolves unanswered questions. Then ask the recipient to check the brief against the work they are about to do.
Start with the next action. “Update the onboarding checklist” needs different information from “approve the client's commercial terms.” Sending both people the same meeting summary can leave one without useful instructions and give the other information they should not receive.
This guide is for project managers and team leads passing work between people with different access. The checklist and example are a practical method, not a substitute for your organization's sharing rules.
Decide what the recipient needs to do
Write one sentence describing the expected output and who will check it. For example: “Revise the internal onboarding checklist to include the new confirmation step; the service lead will review it before use.”
Then work backward. Which decision explains the change? Which current document should the person edit? What must remain unchanged? Where should a question go?
NASA's guidance for incoming staff uses a similar starting point for knowledge transfer: responsibilities, useful references, contacts, deadlines and access to information. Its setting is a role transition; the action brief below adapts those questions to an individual handoff. NASA knowledge-continuity guide
A recipient does not need the full history of a meeting to do every task. They do need the reasoning that affects the task. If the team changed a step to prevent incomplete requests, explain that permitted operational reason rather than simply saying, “The client asked for it.”
Check what can be shared before writing the brief
Reading a source document and passing its contents to someone else are separate permissions. Removing names or shortening a paragraph does not establish that the remaining information can be shared.
Use the existing information owner or authorized reviewer to settle uncertain cases. NIST's definition of least privilege limits access to what is needed for assigned tasks; it does not grant permission to release a summary of restricted material. NIST: least privilege
Sort the task's inputs into three groups:
| Input | What to do in the handoff |
|---|---|
| The recipient may already use it | Link to the current, permitted version and confirm they can open it. |
| A task-specific instruction may be shared under the applicable rules | Include that instruction, with enough approved context to interpret it. Keep the original record in its existing location. |
| Permission or necessary context is unresolved | Name the person who must resolve it and identify which action is blocked. Do not fill the gap from memory. |
If the person needs restricted information to make the decision, a shorter brief may be insufficient. The owner needs to arrange appropriate access, provide an authorized answer, or assign that part of the work to someone who can do it.
A verbal explanation or screen share follows the same boundary. It is not a workaround for information that cannot be put in the brief.
Write an action brief the recipient can use
Keep the instructions with the task in an existing, appropriately restricted work system. Give the brief a date or version so a later change can be identified.
Use this project handoff checklist:
| Field | What to record |
|---|---|
| Task and owner | The specific output and the person responsible for producing it. |
| Decision and reason | What was decided, what changed, and the permitted context that affects the work. Separate decisions from proposals. |
| Materials | The current documents or inputs the recipient is allowed to use. |
| Scope | What the person can change and what must stay as it is. |
| Completion | The due date, reviewer and observable conditions for accepting the output. |
| Open questions | What remains unresolved, who owns the answer, when it is needed, who to contact if it is late, and whether work can proceed meanwhile. |
| Confirmation | The recipient's understanding of the next action, access check and remaining blocker. |
“Review the notes and proceed” leaves the recipient to infer most of these fields. “Draft the revised checklist using version 3; keep the escalation route unchanged; send it to the service lead for review” gives them a usable start.
Keep the source reference somewhere an authorized reviewer can trace it. If the reference itself exposes restricted information, it belongs in the restricted record rather than the recipient's brief. The handoff can name the owner to contact without disclosing the source's contents.
Worked example: a checklist update after a client call
The following people, documents and events are fictional.
A service manager has attended a client call. An operations coordinator must update an internal onboarding checklist but is not allowed to read the call notes or customer contact list. The information owner has confirmed that the operational instruction below may be shared with the coordinator.
The handoff is labeled H-17, revision 1, October 7, 2026. Its version identifies these instructions, separately from the checklist being edited:
Task: Maya will draft the update to Internal Onboarding Checklist v3.
Decision: Add a check that the assigned service lead has confirmed the onboarding contact before the welcome message is sent. Incomplete contact confirmation is the operational problem this change addresses.
Materials: Internal Onboarding Checklist v3 in the team's permitted work folder. The task does not require the customer contact list.
Scope: Add the confirmation step and state that the welcome message stays on hold if confirmation is missing; refer that case to the service lead through the existing escalation route. Keep that route unchanged. Do not send customer messages or change customer records.
Completion: Send the draft to Rowan, the service lead, by Thursday, October 8, at 15:00 Eastern. Rowan will check that the step identifies who confirms the contact and what happens when confirmation is missing. The revised checklist must be approved before use.
Open question: Where should confirmation be recorded? Rowan will answer by Thursday, October 8, at 12:00 Eastern. If no answer arrives, Maya will flag the gap to the project lead and submit the draft with that field marked pending. The checklist cannot be approved while it remains unresolved.
Maya checks the document and replies:
I can open v3 and will draft the confirmation step, including the hold and referral if confirmation is missing. I will flag the recording-location question if it is still unanswered at noon, submit the draft by 15:00 and make no customer-record changes.
That response exposes both the intended action and the unresolved dependency. Rowan can then provide an authorized instruction about where to record confirmation. If that location needs different access, the owner must resolve it before the procedure is put into use.
The example is complete as a handoff for a draft. It is not permission to use the revised procedure. Making that distinction keeps an open question from disappearing behind a “done” label.
Confirm understanding, then keep changes visible
Ask the recipient to explain the next action in their own words and open the materials they will need using their own authorized account. This is a check on the handoff: an inaccessible file or ambiguous instruction is something for the sender to resolve.
Confirm the destination as well as the content. A permitted brief can still be put in a folder with the wrong audience. The UK's National Cyber Security Centre advises organizing information and permissions around its access requirements, including different confidentiality needs. NCSC guidance on SaaS permissions
When instructions change, update the current brief, identify what changed and tell the people working from it. Keep prior versions according to existing record rules, clearly distinguished from the current instruction. Avoid leaving conflicting instructions in a task, chat message and separate attachment.
If a follow-up conversation resolves a question, put the permitted answer back into the brief. Otherwise the next person to join the work will face the same gap.
For your next handoff, start with one work item and the checklist above. Before calling it ready, confirm that the recipient can name the output, open the permitted materials, explain the limits and identify who will resolve anything still missing.