Information Management Chronicles: Part 2

Following on from the previous post on the role of the Records Coordinator, this post focuses on a Records Management topic: Tips for writing a Records Schedule that will help with Microsoft 365 implementation. Records Management sits under the umbrella term Information Governance and concerns itself with the management of records throughout their life-cycle. 

Successfully managing content in SharePoint and Microsoft Teams requires establishing filing structures, setting retention labels for life-cycling records, and implementing metadata for search.

The Records Classification & Retention Schedule sets the terms for creating these filing structures, retention labels, and often metadata, so it is important to ensure that a Schedule exists and that it is of sufficient quality before implementation.

Records Schedule development is notoriously difficult. Rather than attempting to provide an in-depth, comprehensive how-to (there are plenty of these already in the public domain), the purpose of this post is to present five expert tips for writing a Records Schedule that will make a difference when you implement Microsoft 365.

Tip #1: Establish ownership of the Records Schedule  

Records Schedules should be organised by business function/activity as best practice (ISO15489:20161). This means that when developing the Classification Scheme section of the Schedule (the 'BCS'), records classes are aligned to business tasks ('activities'). These activities are grouped by 'functions', the latter representing organisational strategic goals.  

Functional Records Schedules, organised by strategic goals/tasks, by definition must be organisation-wide. Business areas should classify their records with records classes that span various Functions. The HR team, for instance, may use records classes from the Human Resources Management section of a functional Records Schedule, but potentially from the Governance and Business Change Management sections too. 

If Records Schedules are organised by business area, there will be overlap and inconsistencies in records classes and retention rules. This will be the case where business areas perform the same business activity, e.g. managing business change, developing policies and procedures, or creating training materials. In addition, a significant downside of Records Schedules organised by business area is the need to change them frequently to keep up with re-organisations. 

It is extremely difficult to establish an organisation-wide Records Schedule if there is no sponsor or owner at a senior management level. In this situation, it is tempting to develop business area-specific Records Schedules because these can be approved at lower management level. 

However, business area-specific Schedules will result in: 

(A)

Overlap in names of records classes across all Schedules, and scope of documents concerned, where business areas perform the same business activities.  

In Microsoft 365, records classes may be implemented as managed metadata in the term store and subsequently used to tag files and facilitate search. If records classes are ambiguous or overlap, it may be more difficult to group documents through search.  Implementing synonyms in the Term store may help, provided that there is agreement from business areas on which terms are equivalent. 

(B) 

Business-area differences in interpreting retention requirements for the same types of records will result in inconsistent (and less defensible) retention rules across the organisation.

If there are inconsistent retention rules in the Schedule, these will be reflected in Microsoft Purview retention labels.

In my experience there are a few ways in which Records Managers have secured senior level ownership for Records Schedules: 

• The Records Schedule is approved by a very senior manager, e.g. Executive Director, COO, etc., once business area heads have also approved sections that are most relevant to them. I have successfully used this approach in small to mid-sized organisations. 

• In a very large public body in which I served, a standing Committee was used to approve the Records Schedule, but it should be noted that the authority underpinning its decisions was provided by a very senior official, who also participated in meetings.  

• In a large private-sector organisation, the Records Schedule was developed by an external law firm and owned by the Head of Compliance. 

Lacking a very senior, overall owner for the Schedule will make it more difficult to develop it as per a functional model, with an impact on Microsoft 365 implementation.  

Tip #2: Develop good names and descriptions for record classes  

The names of record classes should reflect terminology used by the organisation, keeping in mind that terms may have specific meanings depending on the sector that they are used in. For instance, the term 'product' will have a different meaning in the financial services sector than in everyday language.

Descriptions add context and are essential where the name of the class is not self-explanatory. Users will understand a records class named 'Recruitment', but they may not understand 'Bearer Shares Administration'. Moreover, the absence of records class descriptions will hinder Legal or Compliance departments from effectively reviewing retention rules. It may not be clear which records classes are in scope of regulatory retention requirements. 

A reason for putting effort into good records class names is that these can be leveraged as metadata terms, or as names for document libraries, in Microsoft 365: 

• Records classes, ideally organised within a taxonomy, can be implemented in the Term Store in Purview as metadata. This metadata can be used by users to tag documents and search for them but may also be used as conditions to trigger retention. 

• Records class names may also be used as names for document libraries. Consider that in a Records Schedule, retention rules are attached to the records series level. By naming document libraries as per the records series level, one can default retention labels to the content of the library.

Tip #3: Aim for big-bucket retention rules  

Simply put, 'big-bucketing' retention means that where different retention rules apply to the same records, the longest retention rule is followed. The records are kept together rather than broken up into smaller units, with different retention rules applied. An example may be customer records, where different financial regulations may apply to records. The longest retention requirement 'wins' the whole set. 

Big-bucketing makes sense for many reasons. Where case files are concerned, it ensures that the entire story — whether it pertains to a project, the career of an employee, or the relationship with a customer — will be preserved as long as required. Big-bucketing retention rules simplifies retention and disposal processes, both for hard-copy and electronic records. 

When business users are reluctant to agree to big-bucket retention rules, in my experience, it is over concern that personal data is being over-retained. 

Often, the personal data concerned is evidence of a different business activity, and subject to different retention requirements. For instance, new employees may have to submit criminal record checks prior to beginning employment, which should only be kept for a short amount of time. Employee files on the other hand need to be kept for the duration of employment plus several years. Rather than filing and then removing these records from an 'Employee file', they should be filed in a 'Background Vetting' file, and disposed of after a short period of time, e.g. 6 months. The 'Employee file' should only contain evidence that background checks have been successfully completed. 

Failing to broaden retention rules may also have an impact on how retention labels can be assigned in Microsoft 365. For instance, if the content of a document library is subject to multiple retention rules, then defaulting a retention label to the library will not be sufficient, and other methods of setting retention labels will need to be explored.  

See an excellent blog post discussing reducing the number of retention labels here: https://www.intelogy.co.uk/blog/converting-your-retention-schedule-into-a-model-of-microsoft-365-retention-labels/  

Tip #4: Reconcile retention triggers  

All records have a life cycle, from when they are first created to the point they reach disposition. 'Retention' is the phase of the records lifecycle when records are no longer actively used but must be kept, for compliance, risk management, and operational reasons. The retention trigger starts the retention period. 

In Microsoft Purview there are four options for defining when retention starts: the file creation date; date file last modified; when a file is labelled with a retention label; and when an event needs to take place for retention to begin.  

By contrast, in a Records Schedule, there are many ways in which retention may be triggered. In a Schedule, retention is often triggered by an event or a change of status. Retention triggers may be expressed as, for example, 'end of project', 'end employment', 'when superseded or obsolete', 'end customer relationship', or 'end financial year'.   

It is evident that there is a difference in how retention triggers are defined in a Records Schedule, and how they may be implemented in Purview, with a need to bridge this gap. Event-based triggers need careful planning and may require automation to work well. 

Consequently, it would be beneficial for Records Managers to consider how retention triggers can be aligned with implementation when drafting the Records Schedule. There will be records classes that require retention to start based on an event or a change in metadata – the 'Employee file' comes to mind, with the trigger being the end of employment.  

However, it is worth exploring whether some other classes of records, particularly those that do not contain personal data or have regulatory recordkeeping requirements, can begin their retention from creation date, when labelled, or date last modified. For instance, retention triggers based on the financial or calendar year could instead start from creation date and be extended by a year.  

In one organisation, business users agreed for a records class involving spreadsheets with financial calculations to have a retention trigger of 'last modified + 10 years' – they were deemed to be superseded/obsolete if not actively used.    

Instead of adjusting retention triggers in Schedules that have been approved, Records Managers could consider how to express retention requirements prior approval, with a view to simplify implementation in Microsoft 365. Alternatively, in cases where retention periods have been extended to simplify triggering retention, and personal data is concerned, business area heads should have a chance to review decisions based on implementation considerations. 

Tip #5:  Define ownership of records and/or master versions 

A file plan, rather than a Records Schedule, contains a column defining ownership of specific records. A file plan shows for each business area, records and their respective Data Owners and/or Stewards, against records classes/retention rules from the Records Schedule. File plans are needed in addition to a Records Schedule because business areas may share records classes/retention rules.  

An example of a shared records class may be 'Training Materials Development'. In very large organisations, where the organisation structure is not documented or is constantly changing, it may not be feasible to include the 'Responsible' column, indicating responsibility for master versions. 

A records class may be implemented in one or many file plans, but an entry in a file plan relates to only one records class.  

Columns in file plans, such as Data Owner and Business Area, can be used as metadata in Microsoft 365 to indicate Owner (where it is different from the person creating the document/folder/document set), or the originating business area. Below I illustrated sample entries in a file plan, based on a fictitious 'Customer Services' business area. The grey columns represent Record Schedule records classes, and the blue columns represent records in a business area.

Receive more blogs like this straight into your inbox

Sign up to receive our latest blogs and stay up to date with our latest news, Microsoft 365 updates, events, webinars and workshops.