Board operations

Building a Board Packet Version Register for the Executive Office

A practical version register that keeps board packet changes visible from first draft through the meeting and the follow-up.

5 min readHireExecutiveTeam editorial
Building a Board Packet Version Register for the Executive Office article illustration

Name the packet version before the meeting

A board packet changes as finance updates a number, legal reviews a resolution, and the CEO adds a note. Without a version name, two directors can discuss different documents while believing they have the same packet. Start the register with a version label, the date, and the person who assembled it. The label should appear on the cover page and in the distribution message.

Use a simple sequence such as draft, review, final, and meeting. The sequence should describe the packet's state, not the importance of the person who touched it. If a director asks for the packet, the office can say which version is current and what changed. That answer is more useful than sending the latest file without context.

Keep the register in the same system as the packet, not in a separate personal folder. A shared register lets the executive assistant, the chief of staff, and the board liaison see the same history. It also prevents a late file from being mistaken for the approved version. The register is a control, not an extra administrative task.

A version label should be short enough to say aloud in a meeting. Use a date and a sequence, such as October board packet, version three. Avoid labels that require a decoder or a separate legend. The chair should be able to confirm the version without opening a file.

Record what changed between versions

Each version should have a short change note: what changed, who requested it, and when it was accepted. A note that says updated is not enough because it does not say which section moved. Record the page or section reference when the packet is long. A reader should be able to compare two versions without opening every file.

If a number changes, record the source and the date of the new figure. If a resolution changes, record the reviewer and the approval state. If a cover note changes, record the author. The type of change matters because it tells the reader how much of the packet needs a fresh review.

Do not delete the earlier version when a new one is issued. Keep the versions in a read-only archive with the register entry that explains the difference. The archive protects the office when a director asks why a recommendation changed. It also gives the next assistant a record of how the packet was assembled.

If a change is requested after the packet is distributed, record the request and the decision separately. A late request that is accepted should produce a new version, not a silent edit. A late request that is declined should be recorded too. The director knows why the packet did not change.

Keep access and distribution separate

The register should show who received which version and when. Distribution is a separate event from access to the folder. A director may have access to the archive but not to a draft that is still under review. Record the distribution list and the channel for each version, not only the folder permissions.

Use the approved board portal or a secure sharing method for the packet itself. Do not put the packet in a general channel or an unapproved personal drive. If a director asks for a copy by email, follow the board's policy for secure delivery. The register can note the request without becoming a copy of the packet.

Review access when the board composition changes or a staff member leaves the board support role. Remove access that is no longer needed and record the date. A register that shows old recipients is a security risk, not just a stale list. The NIST Privacy Framework offers a useful vocabulary for limiting information to its purpose.

The distribution message should name the version and the meeting. Do not send a file with a generic subject line such as board materials. A specific subject helps a director find the right document later. It also gives the register a searchable reference.

Use the register at the meeting

At the start of the meeting, state the packet version that the board is using. If a director has a different version, resolve the difference before the discussion begins. The chair can confirm that the version on the screen matches the register. That small step prevents a decision from being based on an outdated number.

Record any change made during the meeting as a new version or a meeting note. Do not overwrite the final packet with the discussion edits. The meeting record should show what the board reviewed and what it changed. The next packet can then start from a known baseline.

If a decision is deferred, record the version that was deferred and the questions that remain open. The next packet should show how those questions were addressed. A deferred item without a version reference is easy to lose between meetings. Record the evidence and the next owner before the packet leaves the office. Keep the note usable by the next reviewer.

If a director joins remotely, confirm that the shared screen shows the same version as the register. A remote participant may have downloaded an earlier file. The chair can ask for the version label before the first vote. Record the evidence and the next owner before the packet leaves the office. Keep the note usable by the next reviewer.

Close the packet after the decision

After the meeting, mark the packet as approved, noted, or superseded. Record the decision date and the person who confirmed the close. A packet that stays in final forever becomes ambiguous when the next meeting begins. The close is what turns a working document into a record.

Link the approved packet to the minutes and the follow-up actions. If an action changes the packet later, create a new version rather than editing the approved file. The link should let a reader move from the minutes to the exact document the board approved. Record the evidence and the next owner before the packet leaves the office. Keep the note usable by the next reviewer.

Review the register at the end of the board cycle. Look for packets that were distributed without a version, changes without a note, or versions that were never closed. Use the pattern to improve the template or the distribution step. The [board packet research](/research/measuring-board-packet-version-control-in-an-executive-office/) describes how to sample the register.

At the close of the cycle, archive the approved packet and the register together. The archive should be read-only for the board support team. A future assistant should be able to see how the packet moved from draft to approval without asking a colleague. Record the evidence and the next owner before the packet leaves the office. Keep the note usable by the next reviewer.

Read also: Board packet version register and Decision brief research.

Frequently asked questions

Should one assistant support the whole executive team?

Sometimes. It works when priorities are clear and executives share one operating rhythm.

What should happen before a consult?

List the meetings, inbox rules, recurring reports, and decisions that need support.

Ready to define the role?

Use a recent leadership week to scope the support that would make the biggest difference. The consultation is a working conversation, not a generic pitch.

Book a consultation
On this page
  1. Name the packet version before the meeting
  2. Record what changed between versions
  3. Keep access and distribution separate
  4. Use the register at the meeting
  5. Close the packet after the decision
  6. Frequently asked questions