IM BLOG: Recordkeeping Architecture Is a Risk Decision

One of the most useful outcomes from this week’s RIMPA Global webinar, Preserving Compliance, Enabling Collaboration, was that the discussion did not produce a universal winner. Instead, it demonstrated why recordkeeping architecture should be treated as a business risk decision rather than a contest between platforms. Each model can support effective recordkeeping. Each can also fail if it is poorly designed, inadequately governed or assumed to be compliant simply because functionality has been implemented.

The three models are not a maturity ladder:

The Australasian Digital Recordkeeping Initiative’s functional requirements for managing records in Microsoft 365 recognise several possible approaches: using Microsoft 365’s native capabilities, integrating it with a records management system, transferring records into a dedicated system or combining these approaches. The important point is that these models are not stages on a maturity ladder. One is not inherently more compliant than another. What matters is whether the complete system meets the organisation’s requirements and manages its particular risks.

Native Microsoft 365 is not the absence of recordkeeping. Microsoft Purview includes technical capabilities described as retention policies, retention labels, records declaration, event-based retention and disposition review. These functions can support an organisation’s recordkeeping model, but their product names should not be confused with legal outcomes. Applying a label does not determine whether information is legally a record. A retention setting does not establish that the correct disposal authority or trigger has been applied. Microsoft’s act of “declaring” an item as a record changes how the product controls that item; it does not create its legal status. For example, Queensland State Archives’ guidance on managing records in Microsoft 365 makes clear that public records arise from the conduct of public business, not from their declaration within a product. The relevant question is whether Microsoft 365’s technical functions have been configured and combined with the necessary policy, authority, processes and assurance to meet the organisation’s actual recordkeeping obligations. Keeping records close to their business context can reduce duplication and friction for users. Organisations must still determine how controls will operate across different Microsoft 365 workloads, how related conversations and documents will remain connected and how configuration changes will be monitored in an evergreen environment.

Manage in place extends governance across source and line of business systems without requiring all information to be moved into a central repository. This can be particularly useful when business systems contain functionality, metadata or context that would be diminished through extraction. Its effectiveness depends on more than an integration being technically available. Organisations must consider the reliability of connectors, consistency of metadata and classification, continued availability of source systems and whether information can be exported or transferred with its relationships and evidentiary context intact. Exit arrangements matter just as much as implementation.

Capturing records into a dedicated EDRMS can provide an explicit and centralised control environment. It may be well suited to processes requiring formal capture, controlled access, stable aggregation, defensible disposal or long-term preservation. However, the strength of that environment depends on whether the right records are captured completely and at the right time. If capture relies on users recognising records, leaving their usual workflow and completing additional steps, the apparent strength of the system may not be reflected in practice.

Many organisations will ultimately use a combination of these models. The appropriate response may differ between routine administrative activity, high-risk case management, contractual commitments and records of enduring community value.

Choose according to consequence, not preference. Architecture should be determined by the value and risk of the business activity and the consequences if the chosen control fails. High-volume activity is not necessarily high risk. Conversely, a single approval, contractual commitment or irreversible decision may warrant stronger capture and assurance, regardless of how routine it appears. 

Organisations should consider:

• the business, legal and community value of the information

• the consequences of loss, alteration, unauthorised disclosure or premature destruction

• whether the decision or transaction can be reversed

• the required retention period and complexity of its triggers

• the need to preserve relationships between documents, messages, participants and actions

• security, access and sensitivity requirements

• the ability to undertake authorised and defensible disposal

• dependence on integrations and the continued availability of source systems

• export, migration and archival transfer requirements

• organisational capability to configure, document, monitor and assure the environment.

These factors should determine where stronger controls are required. The decision should not be driven solely by existing licences, platform preferences or the assumption that one model will suit every type of business activity.

Functionality is not assurance. A retention rule can exist without being applied to the right information. A capture process can exist without being followed. An audit log can record an action without preserving the business context needed to understand why it occurred. Similarly, preventing deletion for a specified period is not the same as demonstrating that the correct retention requirement has been applied. Deletion is a technical event. Disposal is an authorised and documented governance decision.

Implementation cannot be the end of the conversation. Organisations need continuing assurance that controls are operating as intended, that exceptions are identified and that changes to technology, business processes or legal requirements have not weakened the environment. This is especially important for evergreen platforms, where functionality and configuration options change continually. Compliance documentation that was accurate at implementation may not remain accurate without active maintenance, testing and review. A credible assurance program should test real business activity:

• Can the organisation reconstruct a significant decision that moved between an email, a Teams conversation and a document?

• Can it identify which information was relied upon when the decision was made?

• Have the necessary metadata, relationships and access controls been preserved?

• Was the appropriate retention control applied?

• Can authorised disposal occur across every location in which the information is held?

• Could the record be exported with its context intact if the platform, integration or business system changed?

These tests reveal more than a configuration review or a statement of compliance. They demonstrate whether the organisation can produce trustworthy and usable evidence when it is needed.

The professional expectation

RIMPA Global’s interest is not in declaring one architecture universally superior. It is in ensuring that whichever model is selected produces reliable and sustainable recordkeeping outcomes. The location of a record matters. The controls applied to it matter. The burden placed on users matters. So do organisational capability, accountability and the ability to demonstrate that the controls continue to work. The professional question is not simply: Where are our records stored? It is: Can we demonstrate that our records remain trustworthy, appropriately protected, accessible for as long as required and capable of authorised disposal - regardless of where they are managed? That is the standard against which every architecture should be tested.

Meet your blog author:

 

Peta Sweeney CXRIM FRIM (Life), Information and Content Specialist, RIMPA Global