Classification and Retention

A Business Classification Scheme (BCS) can be used both to arrange governance, such as retention policies, and form the basis of a filing scheme / “file plan”. It is a hierarchy from the general to the specific broken down in a structure to classify records according to their business function and activity (known as classification terms).  

For example: 

Financial Management (BUSINESS FUNCTION) 

Tax Management (ACTIVITY) 

Tax Year and Quarter (TRANSACTION/SUBJECT) 

Basing a scheme on business functions and activities is more stable than organisational structures, supports cross-cutting processes and ensures a consistent approach to filing and records retention. 

The firsts level of a BCS is known as the ‘Function’. This describes the business function of the records and shouldn’t necessarily follow organisational structure (although in some cases, this will be inevitable).  

The second level is known as the ‘Activity’ and this breaks the function into the business activities that form part of the function. The activity level can still be relatively high level, but combined with the function, should provide a good definition of the records classified with the terms.  

The third level is known as a ‘Subject’ or ‘Transaction’. It is sometimes referred to as the sub-activity. This level of a classification scheme is optional, and many organisations choose not to incorporate this level into their classification scheme. This level of the classification scheme is more detailed and should only be incorporated where required. 

Metadata properties are descriptive attributes attached to records or documents that provide additional information about their content, context, or structure. These properties might include details such as the creation date, author, document type, or keywords, helping users to quickly identify and understand the purpose and relevance of the material. By applying metadata properties, organisations can enhance searchability, facilitate efficient retrieval, and ensure that records are managed in line with governance requirements, making it easier to explain and organise content within a business classification scheme. [see section 2.4]. 

 

An Information Asset is a collection or type of information held for a common purpose and managed so that it can be understood, shared, protected and exploited efficiently. They have recognisable and manageable value, risk, content and lifecycles. 

Assets should be higher level than a single type of document, but lower level than a business service. Occasionally an entire asset may be contained within a single large spreadsheet (such as a customer/client list). 

Group assets together at as high a level as possible as long as they are still meaningful, useful and give you value in managing the asset and the risk associated with it. This is for practical / pragmatic reasons. If you do group assets together, this is sometimes referred to as Information Asset Type for example Organisation Records, Governance Records, Correspondence, Website, or Image library. 

If any one of the following categories are different across an asset, or change as an asset is used, then you likely have a good justification to split the asset into two or more assets: 

• The purpose / legal basis of the information
• The audience for the information
• The sensitivity or security classification
• The retention period

Where the legal basis, or audience for parts of an information asset changes, this is likely to mean there are multiple information assets. 

The information should be valuable to the organisation and be the input or output of a business process, or part of the decision-making process. 

An information asset may or may not equate to an application or system. For example, HR records as an information asset may all be stored in a HR application such as MyView, PeopleHR etc, but we may also have hard copy files too. An information asset therefore may also exist in multiple places (e.g. electronic and paper) at the same time. 

We may also have a system such as M365 Teams Application that holds multiple information assets and multiple business classifications such as: 

• Chat messages 

• Channel communication 

• File storage – SharePoint 

So, you must think about the different information assets and then what system or application they are stored on.  

 

Information assets are stored on an information asset register normally maintained by records managers or by the information governance function.

 

A retention and disposal policy may also be called a retention and disposal schedule, or a disposal authority. It includes three key components: 

Trigger + Retention Period + Disposition Action
e.g. Purchase Invoices = Financial Year Closed + 6 years – then Destroy 

• Trigger 

The field or category against which the action starts counting i.e. what needs to happen on the record before action can take place. This might include things like, date closed, date project completed, date last modified, date last accessed etc 

• Retention Period 

How long the record needs to be kept for. This will come from the organisation’s retention and disposal authority 

• Disposition Action 

The action or outcome that will be conducted e.g. dispose, transfer, archive etc 

There could be Permanent retention, with a lifecycle point to Transfer to Archive 

Include the legal citation / business rationale 

Potentially include the review cycle 

Potentially include responsible officer 

• Define retention and disposal policies based on: 

Law / Regulation e.g. for corporate governance, financial, personnel, health & safety, business transaction and casework records

Limitation Periods – for contractual, legal claim, enforcement, tribunal and other scenarios

Internal Regulation – Keeping records to meet internal audit purposes

Business Need – for reference, re-use, reporting or audit purposes

Privacy or Data Protection – aligned to lawfulness of processing

Contractual Obligations – e.g. to destroy or return records

Heritage Value – e.g. of enduring cultural, research or historical value – may need to be anonymised

  

• Best practice 

Arrange the retention and disposal policy in the same structure as the Business Classification Scheme using Functions, Activities and Tasks then record types.  

  

These are more stable than organisational structures, support cross-cutting processes and ensure a consistent approach to records retention.  

You can have complementary schedules in different parts of the organisation, inheriting corporate rules for consistency. 

Audit trails must be kept of all changes to retention and disposal policies. 

• International Jurisdictions 

You must assess retention across all operating countries. Where there are different requirements across jurisdictions, it is common practice that the longest retention period applies, unless there is a shorter period mandated under Privacy or Data Protection). 

• Applying retention policies 

You need to consider how to apply retention and disposal policies to records in different types of systems. For example: 

• Network Drives 

• Collaborative workspaces / Chat and Conferencing content 

• Document / Records / Content Management systems (EDRMS / ECM) 

• Email 

• Line of Business Application data 

• Web content 

• Social Media content 

• Physical records in office filing 

• Archived records (physical and digital/electronic) 

 

 Metadata – or “data about data” – is used to profile / index records in a system to provide them with additional context for searching and retrieval. Many jurisdictions have minimum metadata standards and this should be taken into consideration when putting a metadata model in place.  

Metadata should also be aligned to the records. The question to always ask before assigning metadata categories is ‘what is the business benefit of this metadata field’. There should always be a business outcome (e.g. compliance, search, disposal triggers etc) when assigning metadata fields or categories to records. It’s also important to consider how metadata will be applied and what impact to end users the application of metadata might have.  

Case Study – Australia & New Zealand: 

The National Archives of Australia has published the Australian Government Recordkeeping Metadata Standard (AGRkMS). This metadata describes information about records and the context in which they are captured and used. The AGRkMS outlines a minimum metadata set of nine essential properties for effective management, use and transfer of records. These elements are shown in the table below. 

Metadata Element	Use
Identifier	A unique reference for the resource within a given context, e.g. document number or employee number.
Creator	An entity primarily responsible for making the resource. (This is usually an individual in a digital system but it can also be a corporate body or organisation. )
Date Created	A point in time when the record came into existence. (This may also be when the record was acquired by the organisation if they didn’t create it)
Title	A name given to the resource.
Protective Marking	A label that denotes the sensitivity of a record, such as a security classification, caveat or dissemination limiting marker (DLM).
Disposal Class	Information identifying the specific disposal class that authorises the retention or destruction of the records.
Format	The file format, physical medium, or dimensions of the resource.  Information about the logical form of a digital record.
Rights	Policies and requirements that govern or restrict non-security related use of and access to records.
Integrity Check	A method for determining whether the bits that make up a digital record have been changed in the course of transmission or storage. Sometimes referred to as ‘fixity’.

  

The AGRkMS is the basis of the Australasian standard AS/NZS 5478:2015 Recordkeeping Metadata Property Reference Set, which is broadly endorsed by government records authorities across Australian states and New Zealand. This standard is also compatible with the international standard series ISO 23081 which has 3 parts covering Principles, Conceptual and implementation issues as well as Self-assessment. 

Metadata should be defined to enable or facilitate the following: 

• Describe and enable the identification and retrieval of records 

• Associate records with business activities 

• Identify relationships with other records (including digital/electronic and physical counterparts) 

• Enable the presentation and preservation of the record 

• Associate records with business rules, such as retention policies 

• Associate records with “agents” (individual, workgroup or organisation) and their authorisations and rights with regard to the records 

• Track processes and capture audit trails carried out on records, business actions and events involving the record throughout its existence, such as initial capture, changing access rules, migrating records into new systems, the disposition of records 

Metadata can be added automatically (through folder inheritance, database lookups, workflow systems, character recognition, from file or email properties) or manually. 

Examples for business records might include: 

• Title and Description 

• Reference ID (e.g. for staff, cases, transactions, projects, suppliers, assets etc.) 

• Project /Job/Contract Names 

• Person Names, including correspondents 

• Relevant Addresses 

• Dates relating to document receipt, dispatch, approval, expiry etc. 

• Document types (e.g. job advert, job application, CV) 

• Work Status, if applicable 

• Closing of activity, case, project, financial period etc. 

  

There should be consistent approaches for e.g. cases, people, properties or places via Master Data Management. 

It is important to remember that not all metadata fields need to be applied to each record. Metadata should be defined according to the different need of each record/record class.