Microsoft 365 provides two primary locations for end-users to create and capture document type content – OneDrive for Business (‘my files’) and SharePoint Online (‘our files’). Both of these can be accessed from the Chats (ODfB) and Team channels files (SPO) tabs in MS Teams.
Both OneDrive for Business and SharePoint (including via the Files tab in Teams) include the option to Sync content to Windows File Explorer or iOS Finder, allowing end-users to access both from a familiar interface.
In 2021, Microsoft added the option to ‘Add shortcut to OneDrive‘ from a SharePoint library or folder via the browser but not (yet) from the Files tab in Teams. As the name suggests, this creates a shortcut in OneDrive for Business to a SharePoint library or folder. While syncing only syncs to File Explorer or Finder, a short cut to OneDrive also makes the library or folder accessible from the browser version of OneDrive, the OneDrive mobile device app, and File Explorer/Finder.
This post explains the difference between Sync and Add shortcut to OneDrive and the potential impacts both of these options may have on managing records. In summary, both options are useful and likely to be popular but a range of records management related capability in SharePoint is neither visible nor accessible in File Explorer.
The Sync option, in both OneDrive For Business and SharePoint Online, allows content in those locations to be synced to and then accessed directly from File Explorer (Windows) or Finder (iOS). The option replaces earlier methods to map SharePoint document libraries to drives. The option is useful and popular because it means that end-users can continue to work in a familiar space.
On both Windows and iOS machines, syncing from both SharePoint and OneDrive is managed by the same OneDrive sync app. As the screenshot below shows, on Windows machines, the sync client adds separate sections in File Explorer for the content synced from SharePoint (‘andrewwarland’ is the tenant name) and OneDrive for Business (‘OneDrive’ – tenant name) as can be seen in the example below (a personal OneDrive section can also be seen).
Positives of syncing
Creating, accessing and managing ‘personal’ or working content in the synced OneDrive area of File Explorer makes a lot of sense and usually replaces ‘home’ drives.
Negatives of syncing
Creating, accessing and managing content synced from SharePoint via File Explorer minimises a range of records management functionality, including the visibility and editability of columns that can otherwise be seen in both the Teams Files tab and in SharePoint via a browser. For example:
A synced library does not display the unique Document ID, added columns, or retention and sensitivity information.
Content can be added even when a column is mandatory (an error message displays in the SharePoint site, but not in File Explorer).
For these reasons, syncing may be best suited for lower-level ‘working’ content and should probably disabled if this functionality needs to be visible or accessible.
In addition to the above, creating new folder in File Explorer at the top level of a synced Teams document library does not create a new channel in Teams.
Add shortcut to OneDrive
As the name indicates, the option to ‘Add shortcut to OneDrive’ allows an end-user to add a shortcut from a SharePoint document library (or a folder in that library) to their OneDrive for Business unless the library (or a folder in it) have already been synced, in which case an error message will appear.
The option is not yet available via the Files tab in a Teams channel.
Shortcuts to OneDrive can be accessed:
Via the browser version of OneDrive
In File Explorer/Finder, under the OneDrive – (Tenant name) section (along with any other synced OneDrive content).
Via the OneDrive app on a mobile device.
When a shortcut is added to OneDrive, a folder with the same name with a ‘link’ icon will appear in all three of the OneDrive options above. In the OneDrive – tenant name section of File Explorer, both library and folder shortcuts display as a folder (with the site name if there is a conflict) with a ‘link’ icon, as can be seen in the example below.
When shortcuts are added in this way, File Explorer displays the same (cloud/accessed) icons as for other synced content. The screenshot below shows the content in the ‘Documents’ library of the ‘Modern Site’ SharePoint site.
The cloud icon indicates that the content has not been accessed or downloaded (or fully downloaded for the content of folders).
The green circle/tick icon indicates that the content has been accessed and downloaded to the local machine.
Positives of adding shortcuts
The ability to add shortcuts to SharePoint content in OneDrive is likely to be useful and popular as, even though this option is more or less identical with syncing (in terms of the outcome), it means that SharePoint content can be accessed from a familiar location (and also on a mobile app).
Negatives of adding shortcuts
The main negative of being able to add shortcuts to SharePoint content in OneDrive, in addition to the issues with syncing already noted, is the potential for confusion.
There is no obvious indicator in SharePoint to say if a shortcut has already been added to OneDrive; only when the end-users tries to share it again will an error message appear.
End users who add shortcuts to SharePoint document library folders may not be aware of other folders in the same library. There is no visible hierarchical navigation to indicate that there may be other folders, or the position of a folder among others.
Despite having a ‘link’ indicator in the folder icon, end-users may treat the content in the shortcut folder as being in their ‘personal’ OneDrive space.
Additionally, that if a library or folder in a library has been added as a shortcut to OneDrive and is then deleted from SharePoint or the Teams/Files tab, the shortcut will still exist in the person’s OneDrive until they remove it. A shortcut folder can be removed at any time by an end-user also by using the remove option. This implies that end-users will proactively manage shortcuts in their OneDrive.
Creating, accessing and managing content in File Explorer/Finder is a common and popular way to work. However, if corporate records are being stored and managed in SharePoint, it is a good idea to ensure that end-users are aware of the various ‘levels’ of functionality:
SharePoint document libraries. These are a logical ‘container’ for storing records and provide the full set of document and records management options for managing records, including a wide range of system and added metadata, column information including added metadata, retention and sensitivity labels, check out/in, the ability to create multiple views, versioning, etc.
Teams Files tab. This area of Teams provides a slightly cut-down version of the document library experience and is focused on the default Documents library that comes with every Team; each new (non-private) channel creates a folder in that library. It is not (yet) possible to add a shortcut from the Files tab, and versioning is not visible.
File Explorer/Finder provides basic information only about the content stored in the document library although with Windows 10/11 it includes the ability to navigate to the SharePoint site and see the version history.
While both syncing and adding shortcuts provide a very similar outcome in File Explorer, good communication is important to ensure this functionality is used appropriately.
Records management standards (see below) state that a defining feature of records is that they are associated with metadata – both ‘point of capture’ metadata and ‘process’ metadata that continues to evolve throughout the life of the record.
For at least two decades, the requirement to capture and store metadata for digital records has driven the implementation of centralised electronic document and records management EDRM systems, many of which began life as databases used to record metadata about physical records (files and boxes).
EDRM systems were (and still are) used to store copies of digital records created or captured natively in other systems, primarily network file shares and email. End-users were required to copy individual records to the EDRMS, a process that mirrored the storage of records (including printed digital records) in physical files.
Network file shares and email systems were not considered to be suitable as recordkeeping systems because they could not ensure the authenticity, integrity and reliability of records over time, including to manage and preserve metadata about the records stored in them.
The increasing implementation of Office 365, and in particular the use of SharePoint for the storage of records, has highlighted the extent to which recordkeeping metadata can – or even should – be applied to the content stored in that system.
This post discusses the need for metadata in records stored in Office 365, including in both Exchange/Outlook, MS Teams, and SharePoint/OneDrive for Business. It concludes that most records stored in Office 365 do not need additional metadata but, where such metadata is required, there is unlimited capability to add it.
Records and metadata
The international standard for records management, ISO 15489:2016, defines a record as ‘information created, received, and maintained as evidence and as an asset by an organization or person, in pursuit of legal obligations or in the transaction of business’.
Records are said to be different from ‘non-records’ because they are associated or described with (mostly added) metadata that describes ‘the context, content and structure of records and their management through time’.
The standard for recordkeeping metadata is ISO 23081:2017. One records management professional (link at the end of the post) noted that there has been reluctant adoption of this standard, mostly because it was ‘too complex’ and ‘academic’, and used ‘foreign terms’. Unspecified vendors were said to have been dismissive of the standard.
Standard for managing digital records – ISO 16175
Part 2 of the standard ISO 16175:2011, ‘Guidelines and functional requirements for digital records management systems’ contains multiple requirements relating to metadata, across three broad categories:
Point of capture metadata. This includes metadata that forms part of the ‘metadata payload’ of the original record (e.g., date created, creator), other metadata added at point of capture, and metadata that provides additional context for the records.
Process metadata. This is metadata that records activities and changes to both the record and metadata over the life of the record.
The need to manage and control metadata over time.
This standard appears to reinforce the requirement for records to be stored and managed in dedicated recordkeeping systems.
On premise document and records management systems: These systems use metadata schema that specify metadata fields to be used in the system.
Cloud systems including Office 365: These systems can make use of enterprise ‘graphs’ that map people to documents and topics. The graph is built from the interactions of people with content across the different workloads of the suite.
Most people now accept the algorithm capabilities of Facebook, LinkedIn, eBay, Amazon and similar online systems to automatically connect us with information relevant to us, without having to add any metadata.
Given the volume and types of digital content, almost all of which has metadata ‘payloads’, how can we ever hope to add the required recordkeeping metadata?
Can’t we just rely on the algorithms and graphs?
How much metadata do you really need?
The answer to this question may depend largely on business, regulatory/compliance and/or government recordkeeping requirements relevant to the organisation and its jurisdiction. In my experience, across multiple very large and also very small organisations:
Most private sector organisations will likely have minimal metadata requirements beyond basic ‘point of capture’ and ‘process’ metadata already recorded in the system where the records are created or captured (including email), unless this is required for specific compliance or regulatory purposes, or where there is risk associated with poor recordkeeping. For example, in a major food processing company, records relating to the manufacture of food were very well documented and managed, while corporate records were managed haphazardly.
Most public sector organisations are required, for government accountability and transparency (and information retrieval) purposes, to apply a minimum set of both ‘point of capture’ and ‘process’ metadata for non-permanent records. Many government agencies have struggled to manage digital records effectively.
A small percentage of records captured or created in government agencies may require more extensive metadata, especially if those records are to be transferred to archival institutions for permanent retention.
Office 365 ‘workloads’
In Office 365, most business records will be created or captured in either Exchange/Outlook (includes MS Teams chats), or SharePoint or OneDrive for Business (for ‘working’ or personal content).
Exchange is a recordkeeping system in that it stores records with consistent metadata. The primary ‘weakness’, in terms of recordkeeping, is that ‘personal’ Exchange mailboxes aggregate records on a range of subjects by an individual user rather than by business subject. The mailboxes of Office 365 Groups, on the other hand, can be used to aggregate records about a business function/activity or subject.
SharePoint is a recordkeeping system that has extensive default metadata and almost unlimited additional metadata capability (see below). OneDrive for Business is a SharePoint service that has the same extensive default metadata capability.
There is, generally speaking, no requirement for organisations that have implemented Office 365 to allow the continued use of network file shares because the ‘save’ and ‘save as’ options in Office/Windows 10 points to SharePoint and OneDrive as the default save locations.
Metadata in Exchange mailboxes/MS Teams
Emails have the same metadata options in the header of every email:
Recipients (To, including CC and BCC)
(Plus more with routing information and security controls including DKIM, SPF, DMARC etc)
However, no other metadata can be added and some (or most) emails may never form part of the collated record of a given subject.
Because of this ‘limitation’, there has been an assumption ever since email was introduced that emails identified as records would have to be copied to a (separate) recordkeeping system.
In pre-digital days, this meant printing out emails and placing them on a paper file.
In organisations with EDRM systems, this meant copying the email to the EDRMs where additional metadata would be applied.
The original emails generally remained in place in individual mailboxes where they may be subject to backups and journaling in case they needed to be recovered for whatever reason including subpoenas (eDiscovery).
The Office Graph in Office 365 now provides the ability to connect the content in email with other content across that ecosystem, as noted in James Lappin’s post above. This is new – but it doesn’t rely on metadata or copying emails anywhere.
Metadata in SharePoint
As a SharePoint service, OneDrive for Business has the same default metadata columns. According it will not be described further here.
What metadata is required?
Organisations that plan to manage records in SharePoint should consider the following questions as part of their overall information architecture design to ensure records are kept in logical aggregations rather than randomly. This is important especially if end-users are allowed to create Office 365 Groups or Teams.
What point of capture and process metadata is required (for compliance, regulatory, recordkeeping purposes)? What is the source of this requirement?
Is there a difference in the metadata requirements for short-term (retain in the organisation) and permanent records that are to be transferred to archival institutions?
Do the required metadata columns already exist in SharePoint?
If they don’t exist, should the additional metadata columns be added as site columns or library columns?
Does any of the metadata need to be mandatory, and/or can it be a default setting – for example, a metadata column that has the default function and/or activity so the user doesn’t need to add this.
Where is the process metadata and how do you view or manage it? (See also below on this subject).
Information architecture and metadata
The information architecture of SharePoint, in terms of managing records as objects (e.g., documents, spreadsheets, images, etc), is relatively simple:
SharePoint site. The primary aggregation that can be linked to a business function (e.g., ‘Financial management’).
Document library/ies. Logical aggregations or containers of records that can be linked to business activities (e.g., ‘Meetings’).
Folders, document sets as content aggregations.
An effective site architecture can replace the requirement for metadata. For example, the name of the SharePoint site can map to a business function, and library names can map to activities, instead of applying a function and activity pair to each record. The URL address for the record provides the context:
If additional metadata is still required, SharePoint has extensive and almost unlimited capability.
Every new SharePoint site comes with a standard set of around 240 metadata ‘site columns’. The metadata columns include the Dublin Core metadata items.
New metadata columns can be created at the site level (‘site columns’). These are then can be used by all libraries and lists on the site. Here is a useful description of how to add new site columns from ShareGate: SharePoint 101: SharePoint Site Columns.
Every new SharePoint library comes with a standard set of metadata columns – see below. New metadata columns can be created at the library (or list) level, but these columns are only available to that specific library or list.
Default SharePoint document library columns
The default library metadata columns are as follows. Dublin Core metadata items are shown with [DC]:
App Created By
App Modified By
Check In Comment
Checked Out To
Compliance Asset Id
Created By [DC]
Document ID (when enabled as a feature)
Folder Child Count
Item Child Count
Item is a Record
Label applied by
Modified By Name [DC]
Retention label Applied
How metadata is added to records in SharePoint
Every digital record saved to SharePoint will have some form of native metadata (payload). Additional metadata may be added when the document is saved; this may be optional or mandatory.
When a digital record is saved to SharePoint, SharePoint only copies the title or name of the record, not the original created date or author.
When a Microsoft Office document is saved to a SharePoint document library, the Office document stores the library metadata (including the unique Document ID) in its own XML-based properties. This information is retained with the record even when the record is downloaded from SharePoint.
Viewing the metadata
The metadata that describes the content stored in the SharePoint document library may be viewed in multiple ways (via the edit view option), and may be exported (for example if records are to be destroyed or transferred).
Every record includes a version history that provides details of who modified the content, and when (but not what changes were made unless this is recorded).
Process metadata is metadata that records events relating to the record or the aggregation in which it is kept.
Examples of process metadata include when:
Records are viewed or downloaded (date and by whom).
Records are modified (date and by whom, and ideally what changes were made).
Records are copied or moved (date and by whom).
Security controls were changed (date, by whom, and what changes were made).
Records are deleted/destroyed (date and by whom, with what authority).
While ISO 16175 describes the general requirement to keep process metadata, the actual requirement is likely to differ between organisations. Organisations with high compliance requirements, such as certain types of businesses or government, are more likely to want process metadata to be created, accessed when required, and protected against unauthorised modification.
Office 365 process metadata
Office 365 records process metadata in multiple ways in Exchange and SharePoint.
Emails generally cannot be modified after they have been sent. Accordingly, the primary process metadata for emails and Teams chat is likely to be in the deletion records stored in the Office 365 Compliance admin portal audit logs.
SharePoint/OneDrive process metadata is recorded as follows:
Viewed or downloaded, modified, copied or moved: This is recorded in the Office 365 Compliance admin portal audit logs.
Modified: This is recorded in the Date modified and Modified by metadata, as well as the version history (which also keeps the previous actual versions that can be compared if required).
Security changes: This is recorded in the Office 365 Compliance admin portal audit logs.
Destroyed: Depends, but generally this requires the capture of information manually, then stored elsewhere. For example, if the content of a document library is to be destroyed, then the metadata (along with details of the original library URL) should be exported (manually) first and saved somewhere. This is a manual process.
Note that audit log data in Office 365 is only retained for 90 days with an E3 licences, 365 days for an E5 licence.
Exchange/Outlook email has basic metadata. It is unlikely that it will ever be possible to add other metadata, unless email is copied to SharePoint document libraries.
Chats from MS Teams are stored in hidden folders in Exchange mailboxes.
Organisations that need to keep certain emails for specific compliance, recordkeeping or archival purposes, should consider capturing these in SharePoint document libraries. Organisations might also consider making more use of Office 365 Group mailboxes for business-specific content as these Groups also include both MS Teams chat and have an associated SharePoint site.
The metadata capabilities of SharePoint are unlimited but not all records need the same degree of metadata.
The majority of records can probably be managed in standard SharePoint document libraries using the default metadata columns, or with one or two additional site or library metadata columns added, where required.
The Office Graph will increasingly be able to bring together records dynamically in the context of the business or the end-user via Project Cortex and Delve, respecting security controls that may be in place. The centralised content search and retention policy capability in Office 365 will also enable businesses to find, retrieve and manage content across both Exchange and SharePoint.
AS/NZS ISO 23081 series, Information and documentation – Records management processes – Metadata for records
The methods available to manage the retention of content stored by end-users in their Office 365 OneDrive for Business (ODfB) accounts are not always well understood.
Organisations may initially default (in their thinking) to backing up the content because that’s what was always done in the past. A change of thinking may be required.
Explains some of the key differences between ‘home drives’ and ODfB accounts.
Highlights the need for organisations to understand their business requirements for retention of ‘personal’ content, and not assume traditional backup methods are the only option.
Also highlights the need for organisations to understand the potential risks (and potentially unnecessary additional costs) associated with backing up Office 365 content.
Describes two simple options for the retention of content stored in ODfB accounts.
Suggests that organisations can probably use a combination of a single Office 365 retention policy and a change to the storage retention period for inactive accounts, instead of backups to achieve the same outcome.
What are ‘home drives’?
In many organisations, home drives are usually a dedicated area on a network file share designed to allow end-users to store ‘working’ documents and ‘personal’ content.
Using the network file shares for home drives ensures that the content stored in them is backed up as part of standard disaster recovery processes while the user is still active (for disaster recovery and to recover deleted items) and still accessible (as an ‘archive’) after they leave the organisation.
In some organisations, home drives may instead be an area on the user’s computer (C drive). Any content stored on local computers is not backed up.
Generally speaking, home drives – whether in the NFS or on the user’s computer, are not accessible once the end-user leaves the office. This has given rise to the fairly regular use of USB storage devices or uncontrolled, internet-based, file storage systems such as DropBox.
How is ODfB different from home drives?
In organisations that implement Office 365, ODfB is the replacement for ‘home’ or ‘personal’ drives.
Although they offer similar functionality for end-users (in terms of the ability to access the content from File Explorer), ODfB accounts are fundamentally different in several ways.
The content can be accessed on almost any device. No VPN is required.
With Windows 10 devices, the content is synced to and can be accessed via File Explorer. This makes ODfB an almost identical replacement for existing home drives in terms of look and feel, and functionality (plus even more functionality, such as the ability to share directly).
There is no accessible back up – Microsoft is entirely responsible for disaster recovery. If organisations want to back up ODfB accounts from Office 365, they will need to acquire a third-party product. The ability to establish retention for the content (last two dot points below) may make the need for back up redundant.
There is a 90 day Recycle Bin accessible via the browser-based interface. This allows end-users to restore the content they deleted themselves within that time-frame.
Organisations can set a storage retention period that will apply once the end-user leaves and their account is deactivated.
Organisations can also set a retention policy that will prevent the deletion of content while the user remains active.
Both the last two options are the subject of this post.
Access to and retention of home drives vs ODfB accounts
In many organisations, the content stored by end-users in their home drives is considered to be ‘private’ to them, despite the system being owned by the organisation.
While they can be accessed easily by network administrators with elevated privileges, it is not uncommon (often for audit purposes) for IT to have to seek special approval from someone senior to access the content of a home drive either while the end-user is still employed or after they have left. In these cases, IT will either access the active drive or request the back up tape to restore the content.
The content in home drives, when backed up, remains as long as the backup media is accessible.
In Office 365, Global Administrators can access the ODfB accounts of any active user. They do this by going to the Office 365 Admin portal and, under the ‘Users’ section, clicking the end-user account name and then going to the ‘OneDrive’ tab where the option to ‘Get access to files’ is displayed’. Any access to ODfB accounts, by anyone (including Global Admins) is recorded in the audit logs.
[Note: At at January 2020, the old ‘My Sites’ options in SharePoint still exists. These options allow the Global Admins or SharePoint Admins to assign someone, or a Security Group, as a Secondary Admin for all ODfB accounts. This option is largely redundant because Global Admins can access the content anyway.]
The default retention period for ODfB content is 30 days after the end user’s account is disabled.
What exactly are you trying to achieve?
As noted, there are some fundamental differences between ‘home drives’ and ODfB.
Consequently, organisations ideally should re-examine their business requirements for access to and the retention of ‘personal content’ both while the user account is active and when it is made inactive, and not assume that old backup option remain valid.
For example, consider the use of backup tapes:
The primary purpose of backup tapes is to support disaster recovery. These made sense when IT owned the servers, but it makes less sense when Microsoft own them and are responsible for disaster recovery. Is Microsoft’s disaster recovery capability sufficient or suitable?
Backup tapes were (and still are) often used as a type of ‘archive’, allowing organisations to recover data from active and inactive home drives for an indefinite period of time.
The bottom line is – what business outcome/s do you want? Generally, these are likely to be:
The ability to recover content stored on personal drives after a disaster (not just when the end-user has deleted something).
The ability to access and retain content while the user is active or after they become inactive.
An additional business requirement might be to reduce the use of ‘home drives’ for business related content.
Retention options for content stored in ODfB
ODfB ships with two default retention options:
Recycle Bin. Any ODfB content deleted by an end-user goes to the Recycle Bin for 90 days.
Inactive content retention. When an end-user accounts is deactivated, the content remains accessible for a default period of 30 days.
Neither of these two options on their own, without modification, is likely to meet business requirements to achieve some form of back-up equivalent capability and the ability to access content in ODfB for a period of time.
It is likely that most business requirements (to replace backups) will be met instead via a combination of the following:
Creating a single Office 365 retention policy applied to all ODfB accounts that prevents content in those accounts from being deleted for a given period of time.
Extending the default retention period for the content in deactivated accounts from 30 days to a much longer period, for example 7 years.
Office 365 Retention Policy
To ensure that content is kept (and accessible, even after being ‘deleted’ by the user) while the user is active, and after they leave, (a) create a single Retention Policy in the Office 365 Compliance portal, ‘Information Governance’ section and (b) apply it to all ODfB accounts by choosing ‘https://tenantname-mysharepoint.com’.
Once published, the retention policy creates a ‘Preservation Hold library’, visible only to the Global Admins, that stores any content that is modified or deleted by the end-user during the retention period.
At the end of the retention period, the content in the Preservation Hold library and anything else that has reached the end of the retention period is sent to the Recycle Bin where it is kept for 90 days before being permanently deleted.
This type of retention policy effectively replaces the need for a back up of home drives, provided the organisation:
Accepts the risk that Microsoft may not be able to recover all or some of the content in the case of a disaster. Note that this risk also applies to Exchange, SharePoint and MS Teams content.
Understands that, if it decides to attempt to back up ODfB, restoring from back up may not be as simple as it used to be when the organisation owned and managed the relevant servers. What, exactly, will you back up to, and how will you read the data?
ODfB Storage Retention
The second retention option relates to the ODfB accounts of departed users, or inactive accounts.
ODfB includes the option to retain files in ODfB for a specific period of time after the end-user account is deactivated. This is set in the ODfB Admin portal under ‘Storage’.
At the end of the period of time specified, the content is sent to the Recycle Bin after which it is deleted permanently.
Many organisations are likely to approach the retention of ODfB content in the same way they did for home drive content, by considering backup options first, often ‘because that’s what we’ve always done’.
Organisations implementing Office 365 should:
Define their business requirements for the retention of home drive/ODfB content
Examine, understand and consider if retention options in Office 365 result in the same outcome
Understand the potential risks of relying on Microsoft to provide a reliable service including in a disaster situation
Understand the complexity (and risks) of backing up (and recovering) content from Office 365.
In many cases, retention options in Office 365 may provide the required outcome at a much lower cost.
The retention of records in Exchange Online (EXO), SharePoint Online (SPO), OneDrive for Business (ODfB) and Office 365 (O365) groups can be achieved through the application of retention labels published in the O365 Security and Compliance admin portal.
This post describes:
How retention labels work (in summary), including the ‘per record’ rather than the container/aggregation retention model.
What happens to content in Office 365 when a retention period expires.
The options and actions that may influence the way retention labels/policies are configured, where and how they are applied, and the outcomes required.
The post highlights the need for information and records managers to be involved in all aspects of governance, site architecture and design, and decisions around specific settings and configuration, as well as being assigned specific roles, when Office 365 is implemented.
A quick summary of how O365 retention labels work
Records retention policies in O365 are based on ‘retention labels’ that are created in the O365 Security and Compliance admin portal under the ‘Classifications’ section. Multiple labels can be applied to a single policy.
Click this link to read Microsoft’s detailed guidance on retention policies.
Each retention label defines one of three potential outcomes at the end of the retention period, if retention is enabled, ‘keep forever’ is not selected, and the label is not used to classify the content as a record*:
The content will be automatically deleted. If the content is in SharePoint, it will first be sent to the Recycle Bin, from which it can be recovered within 90 days.
This option may be suitable for certain types of low value records.
A disposition review will be triggered to notify specific people. As with the previous point, SharePoint content will be sent to the Recycle Bin if a decision is made to delete it.
This option will require additional, human-intervention actions, as described below, if standard records management disposal review processes are followed.
The date when the above action will occur is based on one of four triggers:
Date last modified
When labelled applied
A event. The ‘out of the box’ (OOTB) event types are:
Employee activity. (Processes related to hiring, performance and termination of an employee)
Expiration or termination of contracts and agreements.
Product lifetime. (Processes relating to last manufacturing date of products).
A new event can also be added.
See this post for Microsoft guidance on event-driven retention.
An additional alternative option is available: ‘Don’t retain the content, just delete it if it’s older than n days/months/years.’ This is similar to the automatic deletion option above and may be suitable for certain types of records.
Declaring content as records
* The option to classify or ‘declare’ content as a record is not discussed further as relates to the way records are managed in the US. Microsoft’s guidance on labels notes that: ‘At a high level, records management means that: (a) Important content is classified as a record by users. (b) A record can’t be modified or deleted. (c) Records are finally disposed of after their stated lifetime is past.’ The standard on records management, ISO 15489, defines a record as ‘evidence of business activities, often (but not exclusively) in the form of a document or object, in any form’. This means that anything can be a record. The record may continue to be modified throughout its life.
When do retention labels become active?
Retention labels become active only when they are published. As part of the publishing process, a decision must be made if the label will apply to all (a single option) or selected parts of the O365 ecosystem:
The Exchange Online (EXO) mailboxes of all or specific recipients, or excluding specific recipients.
All or specific SharePoint Online (SPO) sites, or excluding specific sites.
All or specific OneDrive for Business (ODfB) accounts, or excluding specific accounts.
All or specific O365 Groups, or excluding specific groups. Note that content in Microsoft Teams (MS Teams) is included in the O365 Groups options that include both the SharePoint content and email/Teams chat content.
Auto-applying retention labels
Both the retention label and policy sections include the ability to auto-apply a retention policy if certain conditions are met.
Sensitive information types. These are the same types that appear in the Data Loss Prevention (DLP) section, for example ‘Financial data’ or ‘Privacy data’.
Content types and metadata (E5 licences only). See this post by Joanne Klein for a description of these options.
The ability of the first two options to accurately identify content and apply a retention policy should be investigated before they are relied on.
If you publish retention labels to SharePoint or OneDrive, it can take one day for those retention labels to appear for end users. In addition, if you publish retention labels to Exchange, it can take 7 days for those retention labels to appear for end users, and the mailbox needs to contain at least 10 MB of data.
In EXO, the default MRM policy needs to be removed before the new policy applies.
In ODfB, the policy is available to be manually applied on folders or documents. It does not automatically apply to content.
In SPO, the policy can be applied to document libraries or documents. To avoid removing the ability for users to legitimately need to delete documents in an active library it is recommended to apply the policy after the document library has ceased to be active.
Content in Office 365 Groups is covered by either the EXO (for email/teams chat content) or the SPO policy (applied to libraries).
Retention labels apply to individual records within aggregations
Records labels can be applied to aggregations of records (an entire email mailbox or folder, a SharePoint library or list, an ODfB account, O365 Groups) or individual records. However, the disposal process targets individual records (e.g., individual emails, single documents in SharePoint libraries, individual list items).
That is, even when all the individual records are disposed of, the parent aggregation remains in place without any indication that the records previously stored in it (sometimes known as a ‘stub’) have been destroyed.
This outcome has implications for the way the outcome of a retention label is set. It requires a choice between (a) delete automatically without review or (b) review before delete.
The latter option is made complicated by the requirement to review individual documents, including potentially in the original container (document library in SPO) and export metadata relating to those records if a record of the deletion is to be retained.
What happens when records reach the end of their retention period
As noted above, the outcome at the end of the retention period (trigger date + n days/months/years) will depend on the settings on the label.
Where the label was applied (EXO mailbox, SPO library or list, ODfB folder or document, O365 Group)
Whether the records would be deleted automatically or be subject to a disposition review.
If the records are to be deleted automatically:
SPO and ODfB records will be sent to the site/ODfB Recycle Bin for 90 days
EXO emails will be moved to a ‘Cleanup’ area for 14 days, before permanent deletion.
Aside from the audit logs (which by default only go back 90 days), no other record will be kept of the destroyed records.
If the records are subject to a disposition review, an email is sent to the person nominated. When that person clicks on the link in the email they are taken directly to the ‘Dispositions’ sub-section of the Records Management section of the O365 Security and Compliance centre.
It is arguable that retention policies with disposition review should not be applied to ODfB content as this will require the reviewer to review all the content that has been labelled by a user in their ODfB account.
For more information about this subject see this Microsoft page ‘Overview of disposition reviews‘. Microsoft note, on that page ‘To get access to the Disposition page, reviewers must be members of the Disposition Management role and the View-Only Audit Logs role. We recommend creating a new role group called Disposition Reviewers, adding these two roles to that role group, and then adding members to the role group.’
The dispositions dashboard shows the number of records that are pending disposition against each retention policy label:
Pending disposition tab
When the reviewer clicks on one of the retention policies listed, the following view opens for records ‘Pending disposition’:
An important point to note here is that records are listed individually, not in logical aggregations or collections. It is possible however to use the Search option on the left to filter by author (emails) or SharePoint site and/or site library. It is also possible to export the details (which does not include any unique metadata applied to documents in SharePoint libraries).
All the records displayed may then be selected and a ‘Finalise decision’ dialogue box appears with the following options:
Dispose of the records.
Extend the retention.
Re-label the records.
Disposed items tab
The Dispositions dashboard includes a ‘Disposed items’ tab.
Microsoft note that this tab ‘… shows dispositions [that] were approved for deletion during a disposition review and are now in the process of being permanently deleted. Items that had a different retention label applied or their retention period extended as part of a review won’t appear here.’
Importantly, once records are permanently deleted, they no longer appear in the ‘Disposed Items’ tab. This means that no record will be kept of the records that were destroyed.
Shortcomings of the O365 dispositions/disposal model for records stored in SPO
Only individual records appear, not all the items in a document library
If the retention outcome is based on the ‘created’ or ‘last modified’ date, individual records in SPO document libraries will start to appear as soon as they reach the retention end date. The reviewer may need (or want) to view the original library, which they can identify from the link is in the dispositions review pane.
Retention policies prevent deletion
As a retention label prevents the deletion of content by users, and this may put them off using SharePoint, it is recommended that retention in SPO document libraries be based on when the label was applied NOT when it was created or last modified. This will help to ensure that all documents appear in the disposition review area at the same time.
Event based triggers may not be suitable for disposition review
If the retention outcome is based on an event, or is auto applied and a disposition review is required, those records will appear randomly when the event is triggered. It could be difficult for records managers to decide the disposal outcome in this way without referring back to the library.
The dispositions review pane does not display the original metadata
The dispositions review pane displays only very basic metadata from the original library. Again, the reviewer may need to view the original library, export the metadata and store that in a secure location. Note that the exported metadata includes the URL of each original record including the library name.
The document library remains even when all contained records are destroyed
If the reviewer chooses to dispose of the records listed, only the content of the library (the individual documents stored in it) is deleted, not the actual library itself. No record (e.g., a ‘stub’ of the deleted item) is kept in the library of the deleted content.
The ‘Disposed items’ tab only shows records being destroyed
The ‘Disposed items’ tab only shows records in the process of being destroyed. It does not keep a record of what was destroyed. Records managers will need to retain the metadata of what was destroyed, when, based on what disposal authority, and with whose approval.
Dispositions really only provides a ‘heads up’ for further action
The Dispositions process may be instead used as a form of ‘heads up’ that records are starting to be due for disposal in a document library. This would allow the records managers (who should be Site Collection administrators) to review the library, export the complete set of metadata, and decide if the entire library can be deleted since it is no longer required.
Retention labels in O365 are an effective way of managing the retention and disposal of records in that environment, subject to the following points.
Emails will likely continue to be managed as complete aggregations of records – the mailbox. Users cannot be expected to create logical groupings and apply individual retention labels to those records.
Organisational records policies may mandate specific timeframes for the retention of email (e.g., 1 year), while HR/IT security policies may mandate that whole mailboxes are retained for a period of time after employees leave. It is important to understand the difference between these two models
Options to automatically transfer emails to SharePoint document libraries via rules may be possible using Flow but these rely on individual users to set up.
Consideration should instead be given to using O365 Group mailboxes, rather than individual personal mailboxes, for specific work related matters. For example, ‘Customer Complaints’, or ‘XYZ Project’.
OneDrive for Business Accounts
ODfB accounts may be covered by two forms of retention:
Retention labels that apply to all ODfB accounts while the account is active. These must be manually applied by users.
A separate retention period set for ODfB accounts after a user leaves the organisation.
If there is a requirement to prevent the deletion of content by a user from their ODfB account, the better way to achieve this is using an eDiscovery case with Legal Hold applied.
As most records will be stored in SharePoint document libraries (including Office 365 Group-based SP libraries), multiple retention labels will be required to address different types of content or retention requirements.
Careful consideration should be given to whether records can be deleted automatically at the end of the retention period or should be subject to disposition review, noting that the automatic deletion provides no opportunity to capture the metadata of the records.
The ‘auto-apply’ or event-based retention option should be used sparingly to avoid a trickle of records for disposal – unless there is enough trust that these can be accurately marked and deleted without review.
Shortcomings in the disposition review process support the following decisions for SharePoint Online content:
The number of retention labels should be minimised to avoid a very long drop-down menu when a label is applied. If current record retention or disposal authorities contain a lot of classes, some of these could potential be combined into a single class (e.g., ‘Company Records – 7 years’), while the site name and document library name should provide some context to the content to ‘map’ back to the original classes.
Retention labels should be applied when document libraries (or lists) become inactive as this will avoid conflict with users who want to delete content and also ensure that documents are ready for disposition review at the same time.
Retention labels applied to SPO document libraries should include the disposition review option unless a ‘delete only’ label is considered suitable for certain document libraries that clearly contain working documents or Redundant, Outdated and Trivial (ROT) content.
Records managers should review the content of all or most original SPO document libraries, and export the metadata of those libraries for storage in a separate location (such as an ‘archives’ site), or in the original library with the retention label changed to ‘Never Delete’. The original document library can then be deleted.
In my previous post I described what we did to prepare for the migration of our SharePoint 2013 (SP2013) environment to SharePoint Online (SPO). In this post I describe the process we undertook and the lessons we learned along the way.
By August 2017 we had around 245 SP2013 sites across seven web applications: apps (13 ‘purpose-built’ sites); intranet (1 site); ipform (an old site that was closed several years back); projects; publication (30 sites); sptest (used for testing sites); and team.
The bulk of our sites (around 210 sites split almost equally) containing most of our corporate records were in either the teams and projects web applications.
The details of our root sites were recorded in several key artefacts:
A SharePoint Online list in our SharePoint Admin site, used for new site requests. This was always our ‘master’ listing of sites and included a range of additional metadata, including the business owner and a ‘yes/no’ if the site had been migrated or not. This was one of the first sites we migrated.
Another SharePoint list that recorded the details of site collections and subsites.
An Excel spreadsheet used to ‘map’ of all our root sites (one per cell_ grouped under business areas. This map provided a simple, printable visual map of all our SP2013 sites grouped by business area. We used colours to indicate when sites were migrated to SPO, providing an immediate visual reference.
Configuring and learning about Office 365 Admin and SharePoint Online (and OneDrive) admin
By August 2017 we had access to our Office 365 tenant admin environment, access to which is required to get to the SharePoint Admin portal initially (subsequently, the SharePoint Service Administrator could access it directly).
After setting up and configuring the Office 365 elements and SharePoint Online (SPO) environment, we created some initial test sites (via the Admin portal) to understand the new environment.
One of the early SPO sites was a re-created SharePoint User Group site, used to store general training and other useful information about the new environment. This site has remained our primary go-to point for all SharePoint users.
Our SharePoint developer also re-created various scripts, including scripts to automatically create and configure new sites from a request in a SharePoint Online list.
Monitoring changes in Office 365 and SharePoint Online
We learned the importance of monitoring – daily – the Office 365 message centre and also the Microsoft techcommunity site (which had been moved off a Yammer platform a year or so earlier), as well as the Microsoft Office 365 roadmap to ensure we were aware of any likely changes – many of which were introduced during the time we were migrating.
We quickly learned a few things:
Customisation was not a friend of migration. Fortunately, almost none of our sites were customised. However, page-based content would need to be re-created.
Any complex workflows, integration or data extraction (e.g., ETL for business intelligence purposes which needed to be re-linked) could delay migrations. As it turned out, these sites ended up at the very end of the migration process and a couple were still waiting for migration as at the date of this post.
New ‘modern’ sites based on Office 365 Groups needed careful planning to get them right early on. We decided that any request for an Office 365 Group would go through the same request process as SharePoint requests.
Towards the end of 2018, when they were introduced, we also learned that hub sites were preferred over subsites.
While the migration of SharePoint sites was included as part of an internal IT project, that project was focussed for most of the first year on a range of other core networking elements including the broader network architecture model and high level designs required for our new cloud environment.
It would only later start work on the migration of Exchange mailboxes to Exchange Online and personal drives to OneDrive.
SharePoint migrations continued through the life of the project.
There were a number of options to migrate our SP2013 sites to SPO. We decided against going with an external provider for a number of reasons and instead – after reviewing the market – acquired the ShareGate migration tool in September 2017.
By September 2017 we had finalised the architecture for our SPO environment. As we had been using web applications in our on-premise environment we needed to ‘map’ this to the new environment.
The new model was based on the following:
All team and project sites would be created under the ‘/teams’ path. Project sites would have the prefix ‘PRJ’ to identify them. (Some would also be created as Office 365 Group-based sites, with ‘O365_PRJ’ as the prefix). ‘Team’ sites had to be based on a logical business unit or team.
All other sites, including communication sites and sites that crossed over multiple business areas would be created under ‘/sites/’.
SharePoint migrations were ready to go.
Our earlier analysis indicated that around 50 of our SP2013 project sites were inactive (because the projects had since closed). As no-one was accessing any of these sites we decided to use the ShareGate tool to test the migration process and learn from the experience.
We migrated 51 project sites in October 2017. The migrations initially took place during the day but we then changed to an early morning migration (before 9 AM usually) to avoid any network traffic issues.
First lessons learned
The ShareGate tool worked as expected, and proved to be a very useful tool for other reasons too, such as moving libraries and lists between sites.
The early batch of SP2013 sites were migrated ‘as is’ in terms of their look and feel. They looked exactly the same but were now in SPO. That is, they did not get the new ‘modern’ page look and were not mobile friendly. This didn’t matter too much as the sites were rarely accessed.
After the first batch, we did the following for all new sites:
Added a new page (named ‘home2’) and swapped over the old ‘classic’ page (renamed to ‘homex’) with the new one.
Edited the replacement home page and add any text/images from the old site home page.
Fixed up the left hand navigation; indented libraries and lists on old sites were now under a heading with a drop down menu option. In some cases we left them ‘as is’, in other cases we promoted the indented libraries via the left hand ‘Edit’ option.
For any sites that had the publishing feature enabled on the site collection and site settings, we disabled this on the SPO site post-migration as there was generally no need to have these settings enabled.
Some sites had Active Directory security groups in their SharePoint permission groups. As these were not migrated to our Office 365 environment (for multiple reasons, including the complexity of this legacy environment), these had to be added back in a different way to provide the same level of access. In almost all cases, existing SP permission groups (Owner, Member, Visitor) were sufficient. The primary one we had to re-create was the AD Group for ‘everyone’; this was replaced by the ‘Everyone except external users’ option.
The other factor we had to consider were Office 365 licences. By October 2017 few people had these licences. Anyone who needed to access SharePoint would need a licence, but these might not be issued to everyone until mid 2018. This limited the number of sites that we could migrate. By mid 2018, more or less anyone who accessed SharePoint 2013 before could now access the SPO environment.
Next batch – to end June 2018
From November 2017 to end June 2018 we migrated another 57 sites, including a further 16 inactive project sites in December 2017. The primary reason for the low number was (as noted above) the need for staff to have Office 365 licences, which were not allocated more broadly until mid 2018.
At the same time, however, we were also starting to create a range of new SPO sites, including Office 365 Group-based sites and new communication sites.
Publication sites re-created as communication sites
Almost none of our publication sites could be migrated ‘as is’ to SharePoint Online because the page-based content, while it could be migrated, was not in modern pages or mobile friendly.
Accordingly, it was decided to re-create all the publication sites as SPO communication sites. In almost all cases this was a relatively simple process of creating pages and copying content from the old to the new.
Our intranet was the only except to this process and, as of end 2018, remains as a SP2013 site because of heavy customisation.
Other project impacts
From July 2018 two key projects impacted on the SharePoint migrations.
The first was the roll-out of new Windows 10 devices. While a Windows 10 device was not required to access SharePoint, some of our older Windows 7 devices had Internet Explorer 9 that had issues with SPO. These users were asked to use Chrome instead.
The second related project work (which was part of the overall Office 365 project that included SharePoint migrations) was the migration of Exchange mailboxes and personal drives to Exchange Online and OneDrive respectively. This part of the project encountered a problem with Windows 7 devices and as a result that part of the project activity was delayed.
Final migrations – from July 2018
From July to the end of 2018 we migrated all except around 10 of the remaining sites, at an average rate of around 20 per month. Many of these were simple migrations.
For each migration we followed the same process:
Engaged with the business area to provide awareness of, and where required, training in, the new environment. (By the end of 2018, this training included information about Office 365 and MS Teams to help site owners understand that SharePoint is not an ‘isolated’ product as it was before, but part of a much larger ecosystem)
Identified a suitable date and time to migrate the site (most of these were completed before 8 AM on a working day, but some were done over a weekend)
Alerted our Service Desk to the proposed change
Migrated the site
Made minor changes to the site (home page swaps mostly)
Made the old site read only with a pointer to the new site
‘Released’ the migrated site to the business area, usually before 9 AM.
Provide post-migration support to the business area. In most cases the business area was able to use the new site immediately as the new site was very similar to the old one in look and layout.
The last sites to migrate included sites with complex workflows, integration or ETIL elements and several large, complex and sensitive sites.
New site request process
While we had always had a SharePoint-based site request form, the new environment meant that we needed an updated form. The (SPO) online form changed several times during 2018 as we learned from experience what worked and what didn’t.
The current form captures the following (not all columns/fields are listed):
Site Acronym (up to 12 characters – becomes the DocID prefix)
Site Type: (a) team or project site (no Office 365 Group), (b) team or project site (with Office 365 Group, (c) communication site
Business area owner
Sensitivity (information security)
Suggested site URL
Each of these requests was reviewed by the SharePoint administrators who, if the site request is OK, then run a workflow for non Office 365 Group-based sites only. For Office 365 Group based sites, these were created by creating the Office 365 Group.
By the end of 2018 we had approximately the same number of migrated sites as new sites and our SPO environment was ‘live’ and active.
Almost all the old SP2013 sites were made read only. We expect that these will be deleted by June 2019.
A recent (September 2017) article suggested that OneDrive for Business (ODfB) (and by extension SharePoint Online (SPO); ODfB is a SharePoint-based service), a key application in Office 365 was a potential source of data leaks and/or target for hacking attacks.
I don’t disagree that, if not configured correctly, any online document management system – not just ODfB/SPO – could be the source of leaks or the target of external attacks. Especially if these systems, and the security controls that can protect the data in them, are not properly configured, governed, administered, and monitored.
But, I would ask, what controls do most organisations have in place now for documents stored in file shares and personal file folders, not to mention USB sticks, and the ability to send document via Bluetooth to mobile devices or upload corporate data to third-party document storage systems? Probably not many, because users have no other way to access the data out of the office.
As we will see, the controls available in Office 365 are likely to be more than sufficient to allow users to access to their documents out of the office, while at the same time reducing (if not eliminating) the sharing of documents with unauthorised users.
How to stop or minimise sharing from OneDrive for Business and SharePoint Online
There is one simple way to prevent the sharing of data stored in SPO and ODfB with external people – don’t allow it.
There are several ways to control what can be shared, each allowing the user a bit more capability. All these options should be based on business requirements and information security risk assessments, and Office 365 configured accordingly.
In this article I will start with no sharing allowed, and then show how the controls can be reduced as necessary.
External sharing – on or off
This is the primary setting, found in the main Office 365 Admin centre under Settings > Services & add-ins > Sites. If you turn this off, no-one can share anything stored in SPO or ODfB.
The option is shown below:
If you do allow sharing, you need to decide (as shown above) if sharing will be with:
Only existing external users
New and existing external users [Recommended]
Anyone, including anonymous users
The second option is recommended because it doesn’t restrict the ability to share with new users. The last option is unlikely to be used in most organisations and comes with some risks.
The next place to set these options are in the SPO and ODfB Admin centres.
OneDrive admin center
If the previous option is enabled, the following options are available for ODfB. Note that BOTH SharePoint and OneDrive are included here because the latter is a part of the SharePoint environment.
Let users share SharePoint content with external users: ON or OFF.
NOTE: If this option is turned OFF, all the following options disappear.
If sharing with external users is enabled, the following three options are offered:
Only existing external users
New and existing external users [Recommended]
Anyone, including anonymous users
Let users share OneDrive content with external users: ON or OFF
This setting must be at least as restrictive as the SharePoint setting.
If sharing with external users is enabled, the following three options are offered
Only existing external users
New and existing external users [Recommended]
Anyone, including anonymous users
If sharing is allowed, there are three sharing link options:
Direct – only people who already have permission [Recommended]
Internal – only people in the organisation
Anonymous access – anyone with the link
You can limit external sharing by domain, by allowing or blocking sharing with people on selected domains.
External users have two options:
External users must accept sharing invitations using the same account that the invitations were sent to [Recommended]
Let external users share items they don’t own. [This should normally be disabled]
A final ‘Share recipients’ checkbox allow the owners to see who viewed their files.
SharePoint admin center
The SPO admin center (to be upgraded in late 2017) has two options for sharing.
The first option is under the ‘sharing’ section which currently has the following options:
Sharing outside your organization
Control how users share content with people outside your organization.
Don’t allow sharing outside your organization
Allow sharing only with the external users that already exist in your organization’s directory
Allow users to invite and share with authenticated external users [Recommended]
Allow sharing to authenticated external users and using anonymous access links
Who can share outside your organization
[Checkbox] Let only users in selected security groups share with authenticated external users
Default link type
Choose the type of link that is created by default when users get links.
Direct – only people who have permission [Recommended, same as above]
Internal – people in the organization only
Anonymous Access – anyone with the link
Default link permission
Choose the default permission that is selected when users share. This applies to anonymous access, internal and direct links.
Additional settings (Checkboxes)
Limit external sharing using domains (applies to all future sharing invitations). Separate multiple domains with spaces.
Prevent external users from sharing files, folders, and sites that they don’t own [Recommended]
External users must accept sharing invitations using the same account that the invitations were sent to [Recommended]
E-mail OneDrive for Business owners when
Other users invite additional external users to shared files [Recommended]
External users accept invitations to access files [Recommended]
An anonymous access link is created or changed [Recommended]
Sharing via the Site Collections option
In addition to the options above, sharing options for each SharePoint site are set in the ‘site collections’ section as follows. Note that the default is ‘no sharing allowed’. A conscious decision must be taken to allow sharing, and what type of sharing.
When a site collection name is checked, the following options are displayed.
Sharing outside your company
Control how users invite people outside your organisation to access content
Don’t allowing sharing outside your organisation (default)
Allow sharing only with the external users that already exist in your organization’s directory
Allow external users who accept sharing invitations and sign in as authenticated users
Allow sharing with all external users, and by using anonymous access links
If anonymous access is not permitted (setting above), a message in red is displayed:
Anonymous access links aren’t allowed in your organization
SharePoint Sharing option
The SharePoint Admin Centre has an additional ‘Sharing’ section with the same settings as shown above for ODfB. It is expected that these multiple options will be merged in the new SharePoint Admin Centre due for release in late 2017.
Additional security controls
In addition to all the above settings, there are a range of additional controls available:
All user activities related to SPO and ODfB, including who accessed, viewed, edited, deleted, or shared files is accessible in the audit logs.
SPO and ODfB content may be picked up by Data Loss Prevention (DLP) policies and users prevented from sending them externally. This is of course subject to the DLP policies being able to identify the content correctly.
SPO and ODfB content may be subject to records retention policies set by preservation policies. These may impact on the ability to send documents externally.
SPO and ODfB content may be subject to an eDiscovery case.
Administrators can be notified when users perform specific activities in both SPO and ODfB.
Sharing (and access to the documents once shared) may be subject to security controls enforced through Microsoft Information Protection.
In summary, the settings above allow an organisation to strongly control what can be shared. If sharing is allowed, certain additional controls determine whether the sharing is for internal users or for users external to the organisation. If the latter is chosen, there are further controls on what external users can do. Audit controls and policies may also control how users can share information externally.
The key takeaway is that organisations should ensure that the sharing options available in Office 365 are based on the organisation’s business requirements and security risk framework.