What Changed
Australian state governments recently published detailed guidance on managing records in Microsoft 365, highlighting a shift in how regulators view cloud platforms. The Victorian government updated its guidance in May 2025, while NSW released resources covering Purview functionality, SharePoint information architecture, and core recordkeeping elements. These are practical implementation roadmaps for agencies complying with strict public records laws.
The significance lies not in the use of Microsoft 365, but in how regulatory requirements forced governments to document where the platform excels and where it needs enhancement. If your team manages records in M365, these documents identify the gaps you'll encounter during audits.
Key Findings
M365 requires intentional recordkeeping design
The guidance documents make it clear that Microsoft 365 isn't a turnkey solution. NSW's resources on Purview and SharePoint architecture indicate the need for significant configuration to meet recordkeeping standards. Deploying Teams and SharePoint with default settings won't satisfy retention obligations. The platform offers tools like Purview for compliance controls and SharePoint for structure, but you must design how these tools enforce your Records Control Schedule.
Purview functionality needs specific mapping
NSW's standalone guidance on Purview's recordkeeping capabilities highlights that Microsoft's compliance features don't automatically align with records management needs. Purview handles retention labels, disposition reviews, and records freeze capabilities, but your team must map these features to your functional classification scheme and disposition authorities. For example, if a legal department applies a "Legal - Contracts" retention label without linking it to specific record series, disposition reviews will evaluate documents against a label, not the retention rules governing contract records.
SharePoint architecture is crucial for recordkeeping success
NSW's separate guidance on SharePoint information architecture points out where many M365 implementations fail. SharePoint's flexibility can become a liability without a deliberate structure. Your team needs a Business Classification Scheme that aligns with how SharePoint sites, libraries, and folders organize content. If your classification is functional (procurement, human resources, legal services) but your SharePoint is organized by department or project, you can't apply retention rules consistently. The architecture guidance likely addresses structuring SharePoint so that records declaration, cutoff, and disposition work within your classification framework.
Government compliance requirements reveal platform limitations
These guidance documents exist because Australian public records laws impose obligations that M365 doesn't automatically meet. Victorian and NSW agencies must maintain records that meet evidentiary standards, support Freedom of Information requests, and transfer permanent records to state archives. If government regulators needed separate guidance to make M365 compliant, your organization likely faces similar gaps, you just haven't documented them yet.
What This Means for Your Team
You're likely using a similar setup to these governments: Teams for collaboration, SharePoint for document storage, and Purview for retention labels. The Australian guidance confirms what many records managers suspect: M365 provides infrastructure, but recordkeeping requires deliberate design on top of that infrastructure.
Your current setup probably has three specific issues. First, your retention labels in Purview may not map cleanly to your Records Control Schedule because they were created based on document types or departments instead of record series. Second, your SharePoint structure may have evolved organically, requiring manual intervention for consistent retention across sites. Third, your team might treat Purview's compliance center as the recordkeeping system, when it's actually just the retention enforcement layer, the real recordkeeping logic is in your classification scheme and disposition authorities.
The government guidance also indicates a maturity threshold. If you're still treating M365 as "the cloud backup" or "where we store files," you're behind. Regulators now expect organizations to show that their M365 configuration actively supports recordkeeping obligations, not just stores content.
Action Items by Priority
Map your Purview retention labels to your Records Control Schedule
Review your retention label list alongside your approved schedule. Each label should correspond to a specific record series with a documented disposition authority. If you have labels like "Important - 7 years" or "Department Files," rebuild them. A proper label references the functional classification ("Procurement - Purchase Orders") and cites the retention rule. This mapping is what auditors will ask for when they question how you determine what to keep and what to dispose of.
Audit your SharePoint architecture against your Business Classification Scheme
Document how your current SharePoint sites and libraries align with your functional classification. If you find project-based sites cutting across multiple record series, or departmental libraries mixing records with different retention requirements, you need remediation. The fix isn't necessarily rebuilding everything, sometimes you can use metadata and content types to impose classification within existing structures. But you must know where the misalignments exist before disposition cycles start triggering.
Document M365's role in your recordkeeping ecosystem
Write down what M365 does and doesn't do in your program. It likely handles active records storage and retention enforcement. It probably doesn't handle records freeze across all custodian locations, final disposition approval workflows, or transfer packages for permanent records. Identify those gaps now, before a legal hold or regulatory audit exposes them. If you need supplemental systems for specific recordkeeping functions, document that architecture.
Review event-based retention triggers in Purview
If you're using Event-Based Retention for records tied to project completion, contract expiration, or employee departure, verify that your events actually trigger. Purview can automate retention based on events, but someone needs to ensure those events get recorded in the system. A contract record set to "7 years after contract end" only works if the contract end date propagates to Purview as an event.
