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: firstname.lastname@example.org
- Office 365 SharePoint admin account name: O365_ADM_SPO_username@tenantname.onmicrosoft.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:
Office 365 (and Azure) admin role
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
- Records management
- File Plan (if used when creating retention labels)
- Events (that can be used to trigger retention policies)
- Dispositions (where disposal is managed)
- Information governance
- 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)
- Content search
- Audit logs (up to 90 days)
- eDiscovery (cases, and legal holds)
- Advanced eDiscovery
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
- Threat management
- Dashboard, Submissions, Review, Policy
- Mail Flow
- Dashboard, Message trace
- Data Privacy
- GDPR Dashboard, Data subject requests
- Data Investigations (new)
- Dashboard, Manage Schedules, Reports for download,
- Service Assurance
- 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
- Records Management
- File Plan (review)
- Events (create)
- Dispositions (review and manage)
- Information Governance
- Retention (create and publish)
- BUT NOT Import, Archive, or Dashboard
- Threat management
- Mail flow
- Service assurance
- Four options
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)
- Site Owner
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.