Modern Attachments: Pointers Are Not the Problem When It Comes to Preservation

In this second article of our series addressing discovery challenges associated with pointers, i.e., “modern attachments” in the Microsoft 365 (“M365”) ecosystem, we turn to preservation. When it comes to preservation, pointers are not the problem; they are easy to preserve as part of the sent message.

The problem with preservation pertains to referenced content and whether organizations need to retain “as sent” versions of content referenced in messages with pointers. We explained in our previous article that no family relationship exists between messages with pointers and referenced content; thus, there is no duty to retain “as sent” versions of referenced content (where that is even possible) to ensure those versions are available for preservation at some later date.

We are not suggesting organizations do not have a duty to preserve relevant referenced content where it is stored when a duty to preserve attaches. When a preservation duty arises, organizations should take reasonable and proportional steps to identify and preserve relevant data in their possession, custody, or control, wherever the data may reside at that time. In M365, this means evaluating messaging sources (e.g., email and Teams) and the locations where referenced content may be stored (e.g., SharePoint and OneDrive), and then taking steps to preserve relevant data in these locations, which will include whatever versions are available in the system when the legal hold is set. Organizations are not obligated, however, to proactively retain “as sent” versions of referenced content associated with messages with pointers before the duty to preserve attaches just in case these “as sent” versions are needed for future discovery (versus whatever versions, if any, are available when the preservation duty arises).

As Sent Versions or Close-to-As-Sent Versions?

We base this assessment on current M365 functionality, which we recognize is constantly evolving and may differ from what is described herein by the time of publication or at some point in the future. The M365 system, depending on configuration, will continually create and store versions of documents as users create and modify them. What modifications constitute a new version in M365 is not always easy to discern, since multiple users can collaborate continually on an open document. At no time does sending a message with a pointer to referenced content ensure that the exact “as sent” version of the document referenced by the pointer is saved as a new version within the SharePoint or OneDrive site where it is stored. While it is possible the M365 system will store a “close-to-as-sent” version of the document based on the timing of versioning, when version limits are met for a particular document (e.g., 500 versions), the system will overwrite the earliest version without notice. Moreover, organizations may have configured retention policies that will purge data after the configured retention period is reached (which may be well below 500 versions), rendering those versions unavailable for later discovery as well.

Microsoft Purview currently has no functionality available in the general release that automatically preserves “as sent” versions of content referenced by pointers at the time messages are sent. Microsoft is previewing features that will make it easier for organizations with certain licensing (likely only E5 or equivalent) to retain “as sent” versions of referenced content, but organizations have to decide whether to use these new features before any duty to preserve attaches. These new features will be released as a retention policy, which, when configured in the M365 tenant, will retain a copy of “as sent” versions of referenced content in the Preservation Hold Library (“PHL”) of the site where the files are stored. If referenced content is modified and shared in a new message, a copy of the modified version “as sent” is also retained in the PHL. These “as sent” copies are retained for the duration of the defined retention policy and deleted when the retention period and M365 deletion workflow expires:

Figure: Microsoft 365 Retention Deletion Workflow

Notably, this proposed retention policy feature is not retroactive. Organizations who want the option to conduct further discovery with “as sent” versions will need to set this retention policy in the M365 tenant prior to sending messages with pointers. Otherwise, “as sent” versions of referenced content will not be retained in M365 and will not necessarily be available for future discovery when a preservation obligation is triggered.

Is There a Duty to Proactively Retain “As Sent” Versions?

This raises the question of whether organizations have any duty to use these forthcoming features to proactively retain “as sent” versions of referenced content “just in case” they are later needed for discovery purposes. We posit that there is no such proactive duty. Nonetheless, as part of an organization’s overall information governance program, it should consider whether there are business or regulatory reasons to retain referenced content as it exists when messages with pointers are sent. If the answer is in the affirmative, organizations may decide to use Microsoft’s forthcoming features to do so, which would have downstream implications to eDiscovery workflows.

The authors acknowledge that Microsoft will continue to develop these features. As they design updates, one option may be to provide for the automatic inclusion of “as sent” versions as one of the versions in the standard versioning workflow that would be stored for the duration of a configured standard site retention policy (if any). Doing so would allow that specific version of referenced content, if still available when the duty to preserve attaches, to be readily re-associated with the message that points to it during the collection process if an organization and its discovery counsel determine it is needed. We suggest that this functionality could provide better alignment with an organization’s defined information governance practices while helping organizations avoid potential over-retention of data. (We will discuss re-association in our next article addressing the challenges posed by the collection and review of pointers and referenced content).

eDiscovery practitioners recognize that preserving “as sent” versions of referenced content using the currently available M365 functionality is a challenge. The problem arises, at least in part, from the fiction that referenced content forms a “family” with messages with pointers. Organizations and their discovery counsel may conclude that the risks associated with a particular matter, or presented by the organization’s litigation profile, justify creating an artificial family relationship for discovery purposes; it is certainly their prerogative to do so. We posit, however, that organizations and their discovery counsel also have the prerogative to conclude that there is little or no benefit to treating messages with pointers and referenced content as a family and should be free to make decisions as to retention and preservation that align with that position. Simply stated, there is no obligation that parties retain “as sent” versions of referenced content for preservation that might arise in the future. Moreover, if those versions are not available when a party reasonably anticipates litigation and implements a legal hold, that absence should not be treated as a problem or deficit in the legal hold process.