Policy Document Version vs Entity Adoption: Why Both Records Matter

Policy Version vs Entity Adoption

A policy version is one approved text of the policy, with the date that text takes effect. An entity adoption is one organization’s act of taking the policy up, dated the day that organization acted. Keeping policy version vs entity adoption straight across a group of legal entities takes one version record per text and one adoption record each time an organization adopts a version, and the two change on different events.

What a Version Record Answers

A version record says what the policy said and from when. It holds a version identifier such as v2.0 or v2.1, the text itself, and the effective date of that text. A policy document version is the approved text a version record points to. When a new text arrives, the earlier ones stay on file, and the version records in order are the policy version history.

Management-system standards treat this as basic housekeeping. ISO 9001:2015, the voluntary quality management standard, lists “control of changes (e.g. version control)” in clause 7.5.3.2 c) among the activities an organization applying it addresses, as applicable, when it controls documented information.

In practice a version record is short. It carries the identifier, the approval date, the effective date, a line on what changed from the version before, and a pointer to the approved text. In the example below, v2.1 adds a pre-approval step for hospitality offered to public officials, and that single line is what separates it from v2.0.

What a version record cannot hold is the list of organizations that took the text up. Who adopted the text is a fact about each organization, so it belongs on an adoption record.

What an Adoption Record Answers

An adoption record says which organization took the policy up, and when. There is one record per organization for each version it adopts, it is dated the day that organization acted, and it names the version adopted.

Gifts and hospitality make a natural case for records at subsidiary level. The OECD’s 2021 Anti-Bribery Recommendation addresses them in Annex II, the Good Practice Guidance on Internal Controls, Ethics and Compliance, which the Guidance itself calls “non-legally binding guidance” to companies. Section A, item 5, points to ethics and compliance programs or measures designed to prevent and detect foreign bribery. These are “applicable to all entities over which a company has effective control, including subsidiaries”, on areas that include “gifts” and “hospitality, entertainment and expenses”. The Guidance does not say whether or how each subsidiary takes a policy up. Where subsidiaries act on the policy themselves, the adoption record documents how and when each one did, so a compliance officer can show an auditor which subsidiaries had adopted it, and from when.

Whether that list lives in a company policy register in Excel or in entity management software, each adoption is a fact about one organization. Employee acknowledgment is a third record, often kept in the HR system or learning management system where sign-offs are collected, and it sits apart from both records here.

Gifts and Hospitality Policy, Event by Event

Sample Thornbury Group Inc. has two subsidiaries, Sample Thornbury Freight LLC and Sample Thornbury Labs Inc., and forms a third, Sample Thornbury Retail LLC, later in the year. Its policy is the Sample Gifts and Hospitality Policy, first v2.0 and then v2.1. Every row below is one dated event, and the last two columns show which record it changed. The names, versions and dates are invented for illustration, and none of this is legal advice.

Five Events in Date Order

1. v2.0 approved. The parent’s approval sets the text and its effective date, so the version record changes. That vote is also the parent’s own act on the policy, and a group that tracks the parent can add an adoption record for it dated 2025-03-18. This sample follows only the subsidiaries, each of which takes the policy up by a separate action, so no adoption record changes yet.
2. Freight adopts. Freight’s adopted date matches v2.0’s effective date. That is a coincidence of scheduling, and the two dates are still two facts on two records. A group whose first adopter acted on the effective date may not notice it needs two dates until a later adopter separates them.
3. Labs adopts later. Labs adopts 71 days after v2.0 took effect. The version’s effective date stays where it was, because it belongs to the text, and Labs’ record carries 2025-06-11, because it belongs to Labs’ act.
4. v2.1 approved. Only the version record changes, and v2.0 stays on file. Whether an existing adoption of v2.0 reaches v2.1 depends on what that adopting action and the policy’s own terms say, read with the organization’s governing documents. One action may name “version 2.0” alone, while another adopts the policy “as amended from time to time” or provides that later amendments approved by the parent apply without a new vote, so confirm with counsel how each reads.
5. Retail adopts the current version. Retail never adopted v2.0. Its first adoption record names v2.1, the text current on the day it acted. If adoption records named no version, Freight’s record and Retail’s would read alike, though the two took different texts.

For the same two records laid out as rows, one per organization per version, see the policy adoption matrix.

Effective Date vs Adopted Date

The effective date belongs to a version: one per text, set when that text was approved. The adopted date belongs to one organization’s adoption: one per organization, the date of that organization’s own act. Which record each date sits on settles the policy adoption date vs effective date question.

Read the three pairs off the timeline. Freight has 2025-04-01 and 2025-04-01. Labs has 2025-04-01 and 2025-06-11. Retail has v2.1’s 2025-10-01 and 2025-11-04 for Retail’s act, 34 days later. Record both dates and never overwrite one with the other. An adopting action can also set its own start date for that organization, and that date stays with the adoption, as the action states it. Freight’s two dates are equal, but a group that stored only one could not tell later which it had kept, as Labs and Retail show.

When Only One Record Exists

A version list alone says what the policy said and from when. It cannot say which organizations adopted it, or since when. Read only the versions, and on 2025-05-01 Labs, which had not yet acted, looks the same as Freight, which had. COSO’s Internal Control—Integrated Framework, in its May 2013 Executive Summary, says in Principle 12 that “the organization deploys control activities through policies that establish what is expected and procedures that put policies into action”. The same summary describes internal control as “flexible in application for the entire entity or for a particular subsidiary, division, operating unit, or business process”. Where a group deploys a policy organization by organization, adoption records show where each organization took it up.

Adoption records alone fail in the other direction. Once v2.1 exists, a record that shows an organization and a date cannot say which text was adopted. Someone may try to infer the version from the adopted date, and that breaks for an adoption dated between a new version’s approval and its effective date. An adoption dated 2025-09-25 falls after v2.1 was approved (2025-09-22) and before it took effect (2025-10-01), so the date cannot say which text was meant. The practical fix is to name the version on the adoption record and in the adopting action.

A board resolution adopting a group policy, or a written consent to the same effect, can name the version it adopts. One draft reads “RESOLVED, that the Company hereby adopts the Sample Gifts and Hospitality Policy, version 2.1 (bearing an effective date of 2025-10-01), in the form attached to this resolution as Exhibit A, effective as of the date of this resolution”. That ties the adoption to one text. Whether the same action should, or can, also reach later amendments is a question to settle with counsel, and the minutes or consent that records the adoption should carry the same wording. Kept together, the two records let someone answer, for any subsidiary, what text it had taken up on a given day.

Versions and Adoptions in Lextree

In internal policy tracking in Lextree, one Policy record holds two separate lists: Documents and Adoptions. The Documents list has one Policy Document per instrument. The Document type is Original policy, Amendment, Restatement or Translation, each row carries an Effective date, and an optional Document name such as “v2.1” identifies the version. The policy’s own Effective date is copied from the Original policy row, so it stays the original’s while each later version keeps its date on its own row. For the sample group, v2.0, the first text on file, is the Original policy row, so the policy’s Effective date reads 2025-04-01. Version 2.1 goes in as an Amendment row named “v2.1”, effective 2025-10-01, with a Summary noting its pre-approval step for hospitality offered to public officials.

The Adoptions list holds a Policy Adoption for each organization that adopted the policy, with the Adopting organization, an Adopted date (the board or management approval date) and Notes. A Policy Adoption links to its policy and to no single Policy Document, so the version named, v2.0 or v2.1, goes in Notes or in a custom field your team adds. Seeded fields are defaults, and Lextree is customizable. Freight’s written consent and Labs’ minutes stay in each company’s minute book, and the resolution that adopted it can sit in Governance with that body’s other resolutions and consents.

The same adoptions show from two directions. The policy list has an Adopting organizations column, and each Organization record shows a Policy Adoptions sublist, so Labs’ record lists the Gifts and Hospitality Policy with 2025-06-11. Rows go where an organization acted on its own, and a policy that applies to the whole group by its own terms can leave the Adoptions list empty, which reads as group-wide. With v2.0 named in its Notes, Labs’ row keeps 2025-06-11 and v2.0’s Policy Document keeps 2025-04-01, each date on the record it belongs to. To lay the same records out as rows before loading them, start from the policy adoption matrix.