One of the most confusing aspects of Teams and SharePoint in Microsoft 365 is the relationship between permission groups used to control access to both of these resources. This is especially the case as every Team in MS Teams has an associated SharePoint site (the ‘Files’ tab).
This post explains how permission groups work between MS Teams, Microsoft 365 Groups and SharePoint.
SharePoint permission groups
Before discussing how Teams permissions relate to SharePoint, here is a brief reminder of how SharePoint permissions work.
SharePoint has always had three default permission groups, prefixed by the URL name of the site, as shown in the screenshot below (the name of the site always prefixes the words Owners, Members and Visitors).
People (including in a Group, see below) added to the Owners permission group have full access (full control) to all parts of the site and are usually responsible for managing the SharePoint site. There would normally be two or three site owners.
People (including in a Group, see below) added to the Members permission group have add/edit (contribute) rights.
People added to the Visitors permission group have read-only (view) rights.
These permissions are set at the site level and inherited on everything in the site, unless that inheritance is broken and unique permission are applied. Additional permission groups can be created as necessary but most SharePoint sites only use the default Owners, Members and Visitors groups.
Microsoft 365 Groups
Microsoft 365 Groups were introduced in 2017 and control access to resources, like Security Groups.
However, unlike Security Groups, which usually provide access to individual resources (such as a single SharePoint site, or Line of Business (LOB) system), Microsoft 365 Groups control access to multiple linked Microsoft 365 resources.
Microsoft 365 groups, distribution lists, mail-enabled security groups, and security groups (collectively referred to as Active Directory (AD) groups, are all created in ‘Groups’ area of the Microsoft 365 Admin portal.
When a new group is created, the following options appear.
As noted above, Microsoft 365 groups are recommended. It is important to understand the relationship between Microsoft 365 groups, Teams and SharePoint.
When a new Microsoft 365 group is created (from the dialogue above), it creates:
At least one Owner must be specified. The Owner/s are responsible for managing the Members group.
An Exchange mailbox with the same email @ name as the Microsoft 365 group. The mailbox is visible in Outlook to the members of the Group.
A SharePoint site with the same URL name as the Microsoft 365 group.
By default (unless the checkbox is unchecked), a new Team is also created in MS Teams.
When a new Team is created from MS Teams, or a new SharePoint Team site is created, it creates:
A Microsoft 365 Group with an Exchange mailbox and a SharePoint site (‘Files’ tab).
The name of the Team becomes the name of the Group and the SharePoint site.
The mailbox is not visible in Outlook and is only used for calendaring and for the storage of Teams chats (in a hidden folder).
Importantly, when a new Microsoft 365 group or Team is created (which creates a Microsoft 365 group), the Group Owners: (a) are the same as the Team Owners and (b) are added to the SharePoint Owners permission group, as explained below. .
Group/Team Owners and Members
In other words, the Microsoft 365 group owners (group) is added to the SharePoint site owners permission group – a ‘group within a group’.
That is, the Microsoft 365 group controls access to the Team and the SharePoint site as shown in the diagram below. Security Groups may also be added to the Microsoft 365 Group site, but this does not provide access to the Team.
This ‘group within a group’ model is visible from the ‘Site Permissions’ section of the gear/cog icon as shown below (the name of the Microsoft 365 Group/Team/SharePoint site is ‘SharePoint Admin’). The SharePoint Admin Group Owners (group) is in the SharePoint site owners group, and the SharePoint Admin Group Members (group) is in the Site members group.
If a mouse hovers over the Group ‘icon’ (in the above example, GO or GM), it is possible to view the members of the Group and, for Owners, to modify that list. Confusingly, the ‘GM’ in the SharePoint site permissions group becomes ‘SG’ in the drop down list.
You can also see the ‘group within group’ model from the back-end ‘Advanced permissions’ section of the SharePoint site, but you cannot manage the Microsoft 365 Group members here.
Implementing the model
As with Security Groups, the members of Microsoft 365 Groups will usually be a logical group of people who require access to something, in this case access to the SharePoint site or the Team (for chat, files, or other resources).
The main thing to remember is that membership of the (backend) Microsoft 365 Group provides access to BOTH the Team and the Team’s SharePoint site (the ‘Files’ tab in a Team).
Every Team in MS Teams will usually consist of the members of a logical group with a common interest – a business unit, project team, or with some other work relationship, for example, the members of a committee. The Team Owners are responsible for managing the Team Members.
The Team Owners are the SharePoint site owners and are responsible for managing the site if they decide to access it directly. The Team Members are the SharePoint site members and have the ability to add or edit content, usually via the ‘Files’ tab in Teams.
Note: Security Groups with the same members as Microsoft 365 Groups (and Teams) may already exist. There is no need to add a Security Group if it has the same members as a Microsoft 365 Group.
As noted earlier, a Group/Team does not have visitors with read-only rights. Every Member of the Team has add/edit access to both the Team and its associated SharePoint site.
If there is a requirement to give specific other people either add/edit or read-only access to the SharePoint site, that outcome is achieved by adding people by name, or a Security Group, to either the SharePoint Members or Visitors group.
If there is a requirement to give everyone in the organisation either add/edit rights, or read only access, to the SharePoint site, that outcome is achieved by adding ‘Everyone except external users’ to either the SharePoint Members or Visitors group.
External guests may also be added to the Team and the Team’s SharePoint site.
Two types of retention policy can be created in Microsoft 365:
Label-based retention policies, where the label is used to define the retention and retention outcomes. Labels must be published in a retention policy, a process that includes determining where the labels will be applied and appear (‘explicit’) to end users.
Non-label-based retention policies, where the policy includes the retention details and the outcomes. As part of the policy creation, these policies are then applied to specific Microsoft 365 workloads where they are mostly invisible to end-users (except in Exchange mailboxes). In SharePoint and OneDrive for Business, these policies create a Preservation Hold library that is only visible to Site Collection Admins and above.
It is possible to apply both a label-based retention policy and a non-label retention policy to the same SharePoint site. In theory, this would allow for (a) everything on the site to be covered by an overarching retention policy and (b) specific libraries or lists to be covered by a label-based policy.
In practice, it gets a little complicated, as described in this post.
Creating the two labels
For the purpose of this post, I will apply the two types of policy to a SharePoint site (‘FinanceAP’) that contains specific types of financial information that needs to be kept for 7 years, but I want to allow other content on the site to be destroyed after 5 years.
Retention labels are created in the Information Governance section of the Compliance admin portal in Microsoft 365. I created a label titled ‘Financial records’ with a retention period of 7 years. I then published that label to a retention policy named ‘Financial Records – 7 years’ and applied it only to the FinanceAP site.
More than one label can be published in the same policy, making this a useful option if your SharePoint architecture ‘maps to your file plan or Business Classification Scheme (BCS) and your records retention classes are based on either. It also allows you to create and add the same retention class for types of records that occur in multiple functions where the classes have the same retention – for example, ‘Meetings – 7 years’ or ‘Policy – 10 years’.
Once the policy has been published to a site or sites, the option (in Library Settings) to ‘Apply label to items in this list or library’ can be used to choose which label will apply to the content in the library, as shown below.
If the column ‘Retention label’ is checked, the retention label name appears in that column.
Non-label retention policy
Non-label retention policies are also created in the Information Governance section of the Compliance admin portal which also (a little confusingly) lists all the label-based policies as well.
The process of creating these policies includes the retention (e.g, 5 years) and retention outcome (delete) definitions, as well as the location where the policy will be applied.
For the purpose of this post I created a retention label named ‘Financial Working Records – 5 years’ and applied it to the same site (only) as the label-based policy.
I should expect now to find a Preservation Hold library (via Site Contents as a SharePoint admin) when something is deleted.
At this point, I have two retention policies, (a) one label-based and applied to the site, and (b) one that applies to the whole site.
What happens now?
In the document library where the label-based policy has been selected, I can see that the retention label (Financial Records) that has been applied to items in this library.
This means that I cannot delete this document unless (as an end-user with edit rights or admins) the retention label is removed. However, as we will see below, another policy is working behind the scenes.
In a document library where no label-based policy has been applied, I can see that no label appears under the Retention label policy. From an end-user point of view, it appears that the record can be deleted – or is it?
As this site is the subject of an ‘implicit’ or invisible retention policy that has been applied to the entire site, any attempt to delete anything will be captured by the back-end Preservation Hold library seen below via Site Contents (visible to Admins only).
Interestingly, any attempt to delete a document from a library where a label-based retention policy has been applied, which is ‘denied’ in the actual library, is recorded in the Preservation Hold library, although the document remains in the original library.
If anyone with access to the Preservation Hold library tries to delete that item there, they will receive this message:
The only way to remove this item is to remove the policy.
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
Most people should be aware that pressing the ‘delete’ option for a file stored on a computer doesn’t actually delete the item, it only makes the file ‘invisible’. The actual file is still accessible on the disk and can be retrieved relatively easily or using forensic tools until the space it was stored on is overwritten.
Traditional legacy electronic document and records management (EDRM) systems have two components:
A database (e.g., SQL, Oracle) where the metadata about the records are stored
A linked file share where the actual objects are stored, most of which are copies of emails or network file share files that remain in their original location.
In most on-premise systems, email mailboxes, network file shares, and the EDRMS database and linked file share are likely to be backed up.
When a digital record comes to the end of its retention and is subject to a ‘destruction’ process, how do you know if the record has actually been destroyed? And even if it is, how can you be sure that the original isn’t still stored in a mailbox, network file share, or a back up?
This post examines what actually happens when a file is ‘deleted’ from a Windows NT File System (NTFS), and questions whether digital records stored in an EDRMS are really destroyed at the end of the retention period.
The Windows NTFS Master File Table (MFT)
Details of every file stored on a computer drive will be found in the NTFS Master File Table (MFT).
In some ways, the MFT operates like a traditional electronic document management system – it is a kind of database that it records metadata about the attributes of the digital objects stored on the drive. These attributes include the following:
As noted in the diagram above, the details stored by the MFT include the $File_Name and $Data attributes.
The $File_Name attributes include the actual name of the file as well as when it was created and modified, and its size. This is the information that can be seen via File Explorer and is often copied to the EDRMS metadata.
The $Data attribute contains details of where the actual data in the file is stored on the disk (in 0s and 1s) or the complete data if the file is small enough to fit in the MFT record.
If the MFT record has many attributes or the file data is stored in multiple fragments on a disk (for example as a file is being edited), additional MFT ‘extension’ records may be created.
When a file is deleted, the MFT records the deletion.
If the file is simply deleted, the record will remain on the disk and can be recovered from the Recycle Bin.
If the file is deleted through SHIFT-DEL or emptying the Recycle Bin, the MFT will be updated to the ‘Deleted’ state and update the cluster bitmap section to set the file’s cluster (where the data is stored) as being free for reuse. The MFT record remains until it is re-used or the data clusters are allocated in whole or part to another file.
So, in summary, ‘deleting’ a file does not actually delete it. It may either:
Store the file in the Recycle Bin, making it relatively easy to recover, or
Change the MFT record to show the file as being deleted but leave the file data on the desk until it is overwritten.
How does an EDRMS store and manage files?
The following summary relates to a well-known Electronic Document and Records Management System (EDRMS). Other systems may work differently but the point is that records managers should understand exactly how they work and what happens when electronic files are destroyed at the end of a retention period.
Most EDRM systems are made up of two parts:
A database (SQL, Oracle etc) to store the metadata about the record.
An attached file store that stores the actual digital objects.
When EDRM systems are used to register paper or physical records (files and boxes), only the database is used.
When digital records are uploaded to the EDRMS:
The metadata in the original file, including the file type, original file name, date created, date modified and author are ‘captured’ by the system and recorded in the new database record.
Additional metadata may be added, including a content or record ‘type’.
The record will usually be associated with a ‘container’ (e.g., ‘file’). This containment makes the record appear to be ‘contained’ within that container, whereas in fact it is simply a metadata record of an object stored elsewhere.
The original record filename is changed to random characters (to make it harder to find, in theory) and then stored on the attached (usually Windows NTFS) file store, often in a series of folders.
A link is made between the database record and the record object stored in the file store (the MFT record).
When the end-user opens the EDRMS, they can search for or navigate to containers/files and see what appears to be the digital objects ‘stored’ in that container/file. In reality, they are seeing a link to the object stored (randomly) in the file store.
What happens when an EDRMS record is destroyed?
If there is no requirement to extend their retention, or keep them on a legal hold, records may be destroyed at the conclusion of a retention period.
For physical records, this usually means destroying the physical objects so they cannot be recovered, a process that may include bulk shredding or pulping.
For digital records, however, there may be less certainty about the outcome of the destruction. While the EDRMS may flag the record as being ‘destroyed’ it is not completely clear if the destruction process has actually destroyed the records and overwritten the digital records in a way that ensures its destruction to the same level as destroyed paper files.
If the original associated NTFS file share becomes full and a new one is used, the original is likely to be made read only.
There is likely to be a backup of the EDRMS.
The original records uploaded to the EDRMS probably continue to exist on network files shares, in email, or in back up tapes.
Digital forensics can be used to recover ‘deleted’ files from the associated file share.
Consider this scenario:
An email containing evidence of something is saved to a container in an EDRMS.
The container of records is ‘destroyed’ after the retention period expires.
A legal case arises after the container is ‘destroyed’
A subpoena is made for all records, including those specific records.
Has the record actually been destroyed, or could it still be recoverable, including from backups or the digital originals?
Is it really possible to destroy digital records, and does it matter?
Yes, records can be destroyed by overwriting the cluster where the record is kept, and some EDRM systems may offer this option.
Do EDRM systems overwrite the cluster when a digital record is destroyed in line with your records retention and disposal authorities, or simply mark the record as being deleted, when it is still technically recoverable?
Could the record still exist in the network file shares or email, or in backups of these or the EDRMS?
Might it be possible to recover the record with digital forensics tools?
Does it matter?
It might be worth asking IT and your EDRMS vendor.
Organisations have stored and managed records in on-premise versions of SharePoint for many years. Generally speaking, these records had to be managed in – and disposed from – individual site collections.
Office 365 now includes a range of roles, access controls and settings that can be used to manage records across the ecosystem, making it much easier to manage records centrally.
This post describes the suggested user accounts and roles, and the options they provide access to, that can be used by records and information managers to support the management and administration of records in Office 365.
The short version
If you’d like to avoid reading the entire post, the details in summary are:
User Account: A dedicated ‘records manager admin’ Office 365 user account (separate from a normal end-user account), with its own O365 licence (E3 recommended).
Admin role: EITHER the ‘Compliance Admin’ role set in the Office 365/Azure admin portals OR the same role in the Security and Compliance portal OR a custom role group (e.g., ‘Records Management’).
The Compliance Admin role provides additional options that may not be required, hence the suggestion to create a custom role group.
Security Group: An Office 365 Security Group that includes the records management admin account (and others).
The addition of the O365 Security Group to the Site Collection Admin section of every SharePoint site.
Anyone with any kind of admin access or role in Office 365 should have an admin account, in addition to their normal end-user account.
Admin accounts will usually (but not always) require an Office 365 licence.
Office 365 admin accounts should exist only in the cloud and their naming convention should reflect that difference. For example:
Normal AD end user account name: email@example.com
To access the records management features in the Office 365 Security and Compliance portal, records and information managers should have either (a) an appropriate Office 365/Azure admin account (see below) or (b) an ‘admin’ user account. The admin user account name could be something like:
There are around 35 admin roles in Office 365/Azure, in three broad role types:
Global admins. This role has unlimited access and can edit any setting.
Application-based roles such as Dynamics 365 admin, Exchange admin, SharePoint admin, and Teams admin.
Activity-based roles such as Billing admin, Compliance admin, Helpdesk admin, License admin, Security admin, Service admin, and User admin.
There is NO specific Office 365 admin role for ‘records management’ – the closest in terms of access and functionality required is the ‘Compliance Admin’ role.
Office 365 admin roles are assigned to user accounts either (a) from the individual user account or (b) from the ‘Roles’ section in either the Azure Active Directory admin centre or the Office 365 Admin portal.
Except for the Global Admin role which can access anything, all other roles provide access to specific parts of the Office 365 admin portal or to other admin portals. For example:
The SharePoint Admin role provides access to the SharePoint admin portal.
The Exchange admin role provides access to the Exchange admin portal.
The Security Admin and Compliance admin roles provide access to the Security and Compliance admin portal BUT NOTE that these two roles can also be assigned directly in the Security and Compliance portal which only give access to that portal – it does not give the person access to the Office 365 Admin portal. See below for what this role provides access to.
Users who are assigned and logged on with Office 365 admin roles will see the ‘Admin’ icon in the list of Office 365 apps in their office.com apps listing. If they are granted either the ‘Security Admin’ or the ‘Compliance Admin’ role, they will also see the ‘Compliance’ app as shown below.
Security and compliance portal – records management roles
The Security and Compliance centre (https://protection.office.com) includes a number of sections and options, including several that a records manager should probably have access to or manage:
Retention labels (published as retention policies)
(Two other options specific to security/sensitive information)
Data loss prevention
File Plan (if used when creating retention labels)
Events (that can be used to trigger retention policies)
Dispositions (where disposal is managed)
Import (PST files and social media content)
Archive (for Exchange mailboxes)
Retention (create labels and publish them as policies (which replicates the options under ‘Classification’; create retention policies (without the option of a disposition review) for specific SharePoint sites)
Audit logs (up to 90 days)
eDiscovery (cases, and legal holds)
All the options above, and the ones listed below, are accessible to anyone assigned the Office 365 ‘Compliance admin’ role. Not all of these may be relevant or required by records managers – and indeed may provide too much access.
Permissions (to manage roles)
Use to define policies that capture email and 3rd-party communications
Dashboard, Submissions, Review, Policy
Dashboard, Message trace
GDPR Dashboard, Data subject requests
Data Investigations (new)
Dashboard, Manage Schedules, Reports for download,
Four options with information about the Security and Compliance centre.
Because the Office 365 Compliance admin role provides so much access, it may be better to create a custom role group in the Security and Compliance Centre with fewer roles.
The minimum set of roles most likely to be required by a records manager, and the options they provide access to, are Disposition Management and Retention Management which (together) provide access to the options listed below. The ‘RecordsManagement’ role is redundant because it includes the same last three main dot points listed below that are included with the above two roles.
Retention labels (create and publish)
Sensitivity labels (create and publish)
BUT NOT Sensitive info types
File Plan (review)
Dispositions (review and manage)
Retention (create and publish)
BUT NOT Import, Archive, or Dashboard
If records managers need to search and view audit logs and also access the eDiscovery section, it may be better to assign the Compliance Admin role to the records manager (or at least one of them. The portal warns that because the results of these logs could contain sensitive information, the role should be used only by those people with a specific need to know to details.
Organisations will therefore need to consider if records managers should be assigned the Compliance admin role (with more options), or a ‘lesser’ custom role with fewer options created with the Compliance centre directly.
SharePoint-specific roles and access
Security Group to manage SharePoint Site Collections
In addition to the SharePoint Administrator (Office 365 admin) role, every SharePoint site has two key local ‘admin’ role groups:
Site Collection Administrator (SCA)
SCA access allows records managers to:
Access all parts of a SharePoint site (for review purposes, and also to guide Site Owners on best practice records management)
Apply label-based retention policies to specific lists and libraries
Export metadata for document libraries before the library content is disposed of as part of a retention policy
Manage inactive SharePoint sites
Adding the Security Group to the Site Collection Administration section of every SharePoint site
As SCAs can configure settings and access all parts of SharePoint sites, records managers should be in the SCA group on every SharePoint site, but not by name.
Instead, they should be added to a Security Group created in the Office 365 admin portal (under ‘Groups’) or Azure AD. This SG should be added to the SCA group on every site.
The screenshot below shows where and how the Security Group is added to the SCA group in SharePoint:
If the ability to create Office 365 Groups is not controlled, end users will be able to create SharePoint sites either directly from their SharePoint portal or by creating a Team, Plan, or Yammer Group; the O365 Group Owners are added to the SCA group.
Accordingly it may be necessary to retrospectively add the Security Group to SharePoint sites created by end users who create Office 365 or Yammer Groups, or Teams in MS Teams.
Expiry rules for Office 365 Groups and associated content
Organisations that have AD Premium can create expiry rules for Office 365 Groups that can result in the deletion of all aspects of an Office 365 Group, including its SharePoint site, if the Group becomes completely inactive (including no views of any content) within a given period of time.
Generally speaking the action of creating such rules would be restricted to the Azure Admins/Global Admins. In organisations that have AD premium, the records administrators will need to know if an expiry policy is in place OR direct what that policy should be. It is understood that any content in an Office 365 Group’s SharePoint site will not be deleted in this way if the SharePoint site (including via a retention policy applied to the Group) requires the content to be kept for longer.
Auto-application of retention policies
As noted above, records administrators may need to be able to use the ‘auto apply’ option in retention policies based on certain conditions being met. An E3 licence only allows two conditions:
When the content contains certain (machine identifiable) sensitive information (same as the DLP options)
When specific words, phrases or other properties can be identified via a keyword query.
An E5 licence allows additional conditions including based on the auto-classification (machine learning/teaching) of content.
I visited a local fast-food outlet recently and could not help but notice the ‘Lever Arch’ binders in the small office behind the counter. A small two-drawer filing cabinet was also located below the desk.
It made me wonder – in this day and age when pretty much everyone has access to the internet including via their smart phone, why are there any paper records?
And, why is it so hard to ‘go digital’, when so many better and safer digital options are available?
Reasons for not going digital
People probably want to keep paper records in this digital age for a few fairly common reasons, all of which I’ve encountered over the years.
Ease of access. It is much ‘easier’ to access a record if it’s in the folder with an obvious name, like ‘Rosters’.
Speed of access. You can access a paper record in a couple of seconds. Accessing the same record on a computer means logging on then searching or navigating to where it is stored (potentially including on personal removable storage devices).
Easier to archive. At the end of a given period the records can ‘simply’ be placed in an archive box and sent off for archiving.
Keeping digital records is too ‘hard’.
The company doesn’t offer any other option.
‘Computers are hard’.
No obvious or pressing business reason to go digital.
A preference for paper, or belief that paper records must be kept.
Which of the above have you encountered? Let me know via this anonymous Form:
Keeping paper records can be all well and good, unless this sort of thing happens:
If you keep paper records when better digital options exist, you are taking a calculated risk that doing so is ‘OK’.
Of course, not all businesses (a) store the only copy of their physical records locally or (b) burn down (including by being constructed in fire-prone areas). However, these are not the only risks. Other risks include:
Flooding, from burst pipes, storms, or floodwaters. Water-damaged records are not easy to recover.
Damage from falling objects, including trees or other objects falling from the sky.
Theft or vandalism.
Business closure and leaving records behind in the abandoned building.
Any combination of the above.
What’s the back up for physical records?
What’s the back up for these paper records when disaster strikes?
Generally, unless the physical records have been transferred off-site, or they are the printed version of a digital original that can still be accessed, there isn’t one.
Is there a better, digital way?
Printed records are likely to fall into several broad categories, each of which can be managed in their own way. For example, in the business above:
Policies and procedures, including ‘operating manuals’ and similar types of instructions are likely to be the printed version of digital originals. They can be made available on the company intranet or, if one doesn’t exist, sent via email.
Financial records (e.g., invoices). Again, these are likely to be the printed version of a digital original. If they were in printed form when received (e.g., by mail, with a delivery), the company should (a) ask for digital copies to be sent by email, or (b) scan them and store them digitally.
Rosters and general documents relating to groups of employees (as opposed to individual staff ‘files’). Rosters could still be printed for display purposes, but the original should be kept in digital form.
Staff files. The format of these may depend on the organisation, but there should be no reason for ‘local’ staff files to be kept in an organisation that has a centralised HR system.
Other types of business documents. If necessary, these could be scanned and kept in digital form.
And, of course, all of these could be kept in Office 365, including SharePoint for document storage and MS Teams for teams chat, including for front line workers.
Additional training and support may be required to help these areas ‘go digital’.
Microsoft have improved the Classification section in the Office 365 Security and Compliance centre. The change will help to reduce confusion and make it easier for records managers and security administrators to focus on their individual needs.
Previous user interface
The primary change is to the menu interface. The previous menu options, shown in the screenshot below, showed only ‘Labels’ and ‘Label policies’.
When the previous ‘Labels’ option was selected, a new screen with two tabs ‘Sensitivity’ (default) and ‘Retention’ was displayed, as shown below.
The sensitivity or retention tab had to be selected to create or publish a new label. The user interface was unclear and the difference between creating and publishing a label was not obvious.
New user interface
The sensitivity and retention elements have now been separated and placed under the primary ‘Classification’ menu option as shown below.
Now, ‘Labels’ and ‘Label policies’ are two tabs under the relevant section as can be seen below.
The options to create and publish labels remain the same.
We implemented SharePoint 2010 in early 2012 and then upgraded to SharePoint 2013 in early 2015. After acquiring Office 365 enterprise licences in April 2016 we began to play for the migration of our existing on-premise environment to SharePoint Online. After testing the migration process with inactive sites, we started to migrate active sites from early 2018. We expect to complete all the migrations by 31 December 2018.
This post, the first of three, outlines the factors that influenced and guided how we approached the migration. Our approach may not be the same as your approach, but many of the basic principles may be similar.
Overview of our SharePoint environment pre-migration
A key principle for our SharePoint environment since 2012 was to avoid customisation and dependencies, and use the product ‘out of the box’ (OOTB) as much as possible.
Customisation would almost always require some degree of development and ongoing maintenance. It also meant that upgrades could be more complex and expensive.
Dependencies of any sort – be they integration components or third-party add-ons – could also make upgrades more complex and expensive.
We also implemented a ‘balanced’ controlled environment, following the technical design models for SharePoint 2010 described by Microsoft (extract in image above), which recommended that organisations strike balance across three key governance elements:
IT Governance. Centrally managed or locally managed?
Information Management. Tightly managed or loosely managed?
Application Management. Strictly managed or loosely managed development?
In our environment, the ability to create new SharePoint sites and sub-sites required the completion of a (SharePoint) online form and was restricted to the SharePoint Administrators. This enabled us to prevent uncontrolled growth in the environment and to ensure that all new sites were created within a pre-defined – but not overly strict – architecture design model.
Upgrade to SharePoint 2013 in early 2015
Our SharePoint site collections were created across five web applications: team (approximately 120 sites), project (approx. 120 sites), publication, apps, and intranet. Most of the corporate records were stored in team or project sites, as well as a single ‘apps’ site. (Our apps sites (< 10) were set up to address small business problems that in the past might have been addressed by using Microsoft Access).
Thanks to our OOTB model, we were able to upgrade to SharePoint 2013 over a weekend, with almost no errors. The only site we could not upgrade was the intranet which remains (as at August 2018) in ‘compatibility mode’.
Note: It is not possible to migrate directly from SharePoint 2010 to SharePoint Online. It must be upgraded to SharePoint 2013 or SharePoint 2016 first.
The situation in 2016
In May 2016 we changed our Microsoft Enterprise Agreement to an Office 365 subscription model. Our reasons for going to Office 365 were driven by multiple factors, including the need for mobile access to information.
It is important to remember that SharePoint Online is only one element among many others in Office 365. That is, while it is technically possible to do it, SharePoint would not normally be migrated on its own to SharePoint Online. Any migration must take in account a range of considerations relating to the broader Office 365 environment, including (but not limited to):
Office 365 licences (and what this meant for our users with Office installed on existing computers which were being upgraded to new Windows 10-based devices as part of a separate project)
Active Directory syncing so users can access the environment.
Exchange mailbox migrations so SharePoint-based, email-linked Flow workflows can work.
OneDrive for Business, as a SharePoint service to replace ‘personal’ drives on network file shares.
Security controls and records retention policies, set from the Office 365 Security and Compliance admin portal, as well as audit logs in that same portal.
Office 365 Groups with associated SharePoint sites, Yammer groups (which can be linked with Office 365 Groups) and Microsoft Teams (which can also be linked with Office 365 Groups).
‘Classic’ and modern team sites, Office 365 Group-based sites, and communication sites.
The SharePoint user portal.
The mobile app, and how sub-sites are accessed.
The ever-changing SharePoint Online environment in which anything described as ‘classic’ is likely to be deprecated at some point, and new features appear.
Migrating multiple web applications to one
We needed to plan our migration process, moving away from our five web applications to a new model. We new that, with the exception of our customised intranet, we would probably be able to migrate almost all of our sites relatively easily because we had always kept to the OOTB model.
Fortunately, Microsoft produced a very useful 12-page document which provided a good overview describing how it ran its own SharePoint migration, and good advice for how we might do our own migration.
One of our initial decisions was not to migrate any active site until all Exchange mailboxes were migrated (and preferably, end-users had new Windows 10 devices). As it turned out, the decision to migrate mailboxes was delayed and as a result we would end up migrating most sites first.
We need to work out how to migrate our content as it was no longer possible to do a ‘lift and shift’. We investigated the market and made the decision to acquire a migration tool, ShareGate, to do the migrations ourselves. We would later find the same tool useful to migrate personal drives to OneDrive for Business.
We identified the likelihood that we would create new SharePoint Online sites in parallel with the migration of on-premise sites; this was partially because some existing on-premise sites with multiple sub-sites would be split into separate sites instead, but also because the new SharePoint was so much more versatile and would likely be popular.
The new architecture model
An important point to note is that the new SharePoint Online architecture model provided the opportunity to re-think our SharePoint model and, to some extent, clean up or leave unwanted SharePoint content behind. To quote the Microsoft site above, ‘the best migration is no migration’.
As noted above, we had five primary web applications in our SharePoint 2013 environment. These had to be migrated (or re-created, in the case of publication sites) under one of two paths (only – /teams or /sites) to one of three site option:
‘Classic’ sites (the default for all team and project sites)
Office 365 Group-based team sites
Communication sites (re-created page-based content)
Migrated team and project sites would become classic team sites under either (a) /teams/sitename path or (b) /teams/prj_sitename path, respectively. There were some exceptions:
Some sites with multiple sub-sites would be split up into multiple independent sites (including using the new ‘hub’ sites).
A couple of team sites would become communication sites.
Team sites that crossed multiple organisational business areas would be created as classic team sites under the /sites/sitename path.
Most publication sites that used the publishing features would need to be re-created as communication sites under the /sites/sitename path. There were some exceptions:
Some publication sites would become team sites instead.
The intranet would be managed separately as, at the very least, it would need to be re-created in SharePoint Online. It could not be migrated ‘as is’.
Application sites would become team sites.
Some existing sites or sub-sites might be migrated to SharePoint sites linked to Office 365 Groups, with the naming prefix of either GRP_ or PRJ_.
The above ‘mapping’ model was an early decision that did not change.
We also commenced work on the following elements of work:
Reviewing all existing sites to determine which sites would be migrated or discarded – see below.
Re-developing our SharePoint Architecture documentation for the Online version.
Investigating and documenting all Office 365 admin and Office 365 Security and Compliance admin configuration settings, and determining roles. This process, which required Global Admin access, included establishing records retention policies (from mid 2018) in the Security and Compliance admin portal.
Re-developing our existing SharePoint admin documentation for the Online version, including all the configuration settings. We included the OneDrive for Business config settings in this same document as it is a SharePoint service.
Understanding how the new environment worked, and would work.
Re-establishing our SharePoint Admin and SharePoint User Group sites in SharePoint Online.
We also created a range of ‘test’ sites to better understand the new environment.
Creating an initial schedule for the migration of sites, targeting inactive sites first.
Assigning the initial batches of Office 365 licences.
Developing a repeatable process to migrate sites using ShareGate. In our environment steps involved:
Identify need to migrate site
Register a new site request in our SharePoint Admin portal.
Register the task in our Jira task management system.
Create the SharePoint Online site (via a script linked to the request).
Migrate the on-premise site, make it read only with a re-direct notice on the front page (and a three month deletion notice*).
Prepare the migrated site, including swapping the classic default home page to a modern home page.
Hand over the site to the business owners and close the task
* In practice many of these sites still remained after 6 months.
As part of our review process, we identified around a dozen sites that had one or all of the following elements, that would mean we had to devote more time to their migration (‘custom workload’ in the Microsoft document above):
Complex workflows which would need to be re-created.
Integration with other systems (mostly via BizTalk).
Links with ETL processes.
We also identified around 50 sites that would not be migrated:
Sites that were unused or had no content of value (often because the original was still on a drive).
Sites that did not need to be migrated, for example if their content had been migrated to a different business system.
Sites that were no longer used but contained records that needed to be kept were to be migrated with the word ‘Archive’ to the end of the site URL name, assigned a site retention policy, and then made read only.
By August 2017, we had identified that 250 site collections would be migrated to SharePoint Online. We acquired ShareGate in September 2017 and were ready to start migrating.
In Part 2 of this series of posts I will describe the migration process and the lessons we learned along the way.
Records retention policies are created in the Security and Compliance Admin portal, Classifications section of Office 365, as noted in my previous post of 9 March 2018 on the subject.
This post describes how these are applied to document libraries and what happens when the records reach their disposal/disposition period.
Note: In Australia we refer to the disposal of records. In the US this is called disposition.
Setting up retention policies
Organisations may have complex or quite simple records retention policies. An important point to keep in mind in Office 365 is how many policies should be displayed to the end user to choose from.
Ideally, there should be fewer than a dozen classes so they are easy to choose from (see below). There is nothing stopping you creating 100 or 500 policies, but all of them will appear in the drop down list to choose from. Microsoft say they are working on ‘grouping’ policies, so this may help to fix the issue.
For some organisations, it may be useful to distill or group retention policies down to a smaller number.
For example, specific retention policies for certain types of records, and one (or two) for ‘all other’ records. The key, as we will see below, is naming them so they are obvious and easy to apply.
Viewing available retention policies
Retention policies that have been created appear in the Security and Compliance Admin portal, under Classifications > Labels.
Note: Labels must be published before they become visible to end users.
When you click on Labels, you can then see all the retention policies that have been created (but not necessarily published).
The screenshot below shows just the very top policy (a test/demonstration policy with a 7 day retention period) in a list of policies.
Note: Policies can be auto-applied, provided the policy has sufficient ability to identify what records they should be applied to.
Published policies appear in the Data Governance, Dispositions section:
The Dispositions section displays policies that have been published and are visible to end users in the Office 365 areas selected when the policy was created (e.g., Exchange, SharePoint, OneDrive etc).
Applying the policy in a SharePoint document library
To apply the policy to a SharePoint document library, go to the document library, library settings, and you will see the option to add the retention policy: ‘Apply label to items in this list or library’.
The ‘Apply Label’ dialogue shows the option to apply the label to existing items (recommended) and a drop down which shows all the published retention policies.
In this example below, there are four policies including the test policy.
The policy now applies to all records stored in that document library.
When the records reach the end of the retention period configured in the policy, the person designated to be informed about the retention will receive an email notifying them of the need to review the dispositions.
Note, the person (or mailbox) receiving this email MUST be assigned to the Records Management role in the Security and Compliance Admin portal, Permissions section. No-one else will see the records due for disposal otherwise (not even the Global Admins, unless they have also been delegated to that role).
The records person clicks on the link ‘Go there now’ and it opens the following section in the Office 365, Security and Compliance Admin portal, showing the documents that are pending disposition. A number of options are available to sort by Type, to search, and to filter by several options.
The following options appear if a single document is selected. Note the option to extend the retention period or apply a different label, as well as the ability to delete the item permanently.
Filtering options are displayed below.
Finally, the records manager can choose all the documents in the list and complete three bulk actions as shown.
Positives and negatives
The positives of this method of disposing of documents are that all records from any location will appear in a single view that can be filtered and actions taken as required.
The negatives are that potentially thousands of documents might appear in this listing every single day making it difficult to decide what can deleted or not.
However, as it’s possible to filter by the retention policy, that at least should make it relatively easy to identify what can be destroyed. The more fine-grained the policies, the fewer records should appear.
Organisations that have function-based disposal classes should find that all records relating to the same function appear for disposal under that function.
Another potential negative is that records may not always appear in the same context, whether it be subject- or function-based. For example, a collection of documents (often known as a ‘file’) may not appear in the disposition listing as a collection but as a set of records that are only connected by the disposal policy name. Does this matter?
Recording disposal actions
A key requirement for most organisations is keeping a record of what was destroyed.
At the moment the only apparent option to do this is to apply filters and export the list, using the handy ‘Export’ option to keep a record of what was destroyed. That csv file can then be stored in a control library to ensure a record is kept. This type of action requires a degree of control to ensure it happens every time.
It may also be possible to identify what was destroyed – and by whom – in the audit logs. This is being investigated.
In May 2016, I wrote about the creation of security classification labels in the Azure Information Protection (AIP) portal (old post here). Quite a bit has changed since that post, in particular the naming of policies, away from ‘High’ to ‘Low’ Business Impact (e.g., HBI – LBI) to real-world words such as ‘General’ and ‘Highly Confidential’.
In October 2017, I wrote about the new retention policies that could be applied to all Exchange, SharePoint and OneDrive content in Office 365.
Changes to the Security and Compliance admin portal – Classifications section
On 23 February 2018, Microsoft’s Adam Jung posted a new article to the Microsoft Tech Community titled ‘Consistent labeling and protection policies coming to Office 365 and Azure Information Protection’.
The main outcome of this change is that information security protection and records retention policies, linked with Data Loss Prevention (DLP policies) are created from a single interface in the Security and Compliance admin centre > Classifications section (Labels). These policies are set in Office 365 are then synced to Azure (and vice versa).
To quote the Microsoft blog: ‘The upcoming experience means that the same default labels can be used in both Office 365 and Azure Information Protection, and the labels you create in either of these services will automatically be synchronized across the other service – no need to create labels in two different places!’
This post looks at the changes and some potential issues that may arise.
Security and Compliance Admin Portal – Classifications
Records retention policies for Office 365 content are set as labels in the Security & Compliance Admin portal of Office 365 under Classifications – Labels.
The Classifications area also includes a section for ‘Sensitive Information Types’, which simply lists a range of information types that are also used for DLP policies.
Note: Access to that Admin portal is restricted by default to Global Admins and anyone assigned to a specific security role. Records managers in organisations that have or are deploying Office 365 should have access to this feature.
Setting (Records Retention) Classification Labels
The options for setting a records retention label were described in detail in my post above, but for reference again, they are:
Disabled or enabled (off/on)
When enabled, the ability to set (a) a retention period, and (b) an action when the period expires.
Alternatively, it is possible to just delete content when it’s older than a given time.
An option also allows the content be to be classified as a ‘record’ when the label was applied, providing further protection against deletion, for example.
Review your settings
Merging of label options – Retention and Security together in a single label
The primary change to classifications is the inclusion of new options when you choose to ‘Create a Label’.
These options are now:
Protection settings (e.g., information security)
Advanced options settings
Review your settings
These options are described below.
The ‘Protection settings’ section includes the following options:
Enabled or disabled. (If disabled the next check box options do not appear)
Block users from sending email messages or sharing documents with this label
Show policy tip to users if they send or share labeled content (The text of the policy tip is editable)
Send incident reports in email
Advanced protection for content with this label (Customise settings option)
The ‘Retention settings’ are identical with the options already described above:
Disabled or enabled
Various settings when enabled.
The ‘Advanced options settings’ section includes the following options:
Enabled or disabled. (If disabled the next check box options do not appear)
Add a watermark (text can be customised)
Add a header (text can be customised)
Add a footer (text can be customised)
The Microsoft article notes: ‘We are building labeling capabilities natively into the core Office apps – including Word, PowerPoint, Excel, and Outlook, and soon there will be no need to download or install any additional plug-ins.’ This comment references the problem of having to download a plug-in for the classification options to appear in installed versions of Office.
Does it make sense to merge security classifications and records retention?
In my opinion, putting information security and records retention policies in the same label doesn’t make sense.
Retention is almost never linked with the confidentiality (or otherwise) of the records but based on government or legislative requirements or business needs.
But that was probably not Microsoft’s intention; it was probably to make it as simple as possible to create and apply these policies.
It would have made more sense to have separate label options for ‘Retention policies’ and ‘Security policies’. This would potentially mean, however, having two labels (if a label is in fact required for retention purposes).
Organisations with complex retention policies might find that the mixing of both policies in the one view makes it harder to find the individual security related policies, and have the potential to cause some confusion.
For example, it is could be hard to spot the Highly Confidential label in this listing if there were more than (say) 50 retention classes:
Client records – 7 years
Financial Records – 7 years
Internal Use Only
Meeting Records – 3 years
Working Paper – 1 year
It also raises the question (which I have asked and will update this post if I receive a response) as to whether two policies can (or should) be applied on a document.
If two labels cannot be applied, this could mean that organisations have to have even more labels to take account of the various combinations. For example:
General Financial Records – 7 years
Confidential Financial Records – 7 years
Highly Confidential Financial Records – 7 years
Not to mention the link to DLP policies, although that doesn’t appear as a label.
In my opinion, combining these two options, while perhaps making it easier at the ‘front end’, has the potential to create confusion for users, let alone complicate the administration of retention management.
Read the full Microsoft blog article in the link below