Enabling Copilot under VSA6: the pre-flight checklist

The Digital Transformation Agency has signed VSA6, the sixth iteration of the whole-of-government Volume Sourcing Arrangement with Microsoft. It runs for five years from 1 July 2026 and covers the Microsoft 365 suite, Azure, Dynamics 365, Microsoft's security and identity services, and Copilot. On Copilot, the DTA has been explicit that adoption is a choice: there is no requirement to attach Copilot to any other purchase, and the arrangement simply allows an agency to procure it if it wishes. iTnews' coverage of the signing put it plainly: Copilot is an optional buy.

Optional is not the same as deferrable. Every non-corporate Commonwealth entity under the arrangement now owns an enable-or-govern decision, and the agencies that decline to decide will make the decision anyway, informally, one staff member pasting departmental text into a consumer chatbot at a time. The useful question is not whether Copilot is available under VSA6 (it is, at capped pricing with stronger contractual protections around government data handling) but what has to be true in the tenant before an agency can defensibly turn it on. That checklist is what this guide covers. Frontrow's broader guide at /insights/copilot-for-government-australia covers the deployment and business-case picture; this piece is the pre-flight sequence.

What VSA6 changes, and what it does not

VSA6 settles the commercial layer: stable pricing with capped increases over the five-year term, a standardised contracting framework, and enhanced legal provisions covering governance, reporting, security, liability and the handling of government data. Its predecessor had been in place since 2019 and grew past $1.2 billion in contracted spend as agencies joined, so the commercial gravity of the new arrangement is not in doubt.

What VSA6 does not do is make any agency Copilot-ready. Procurement and readiness are different problems. The DTA's own evaluation of the 2024 whole-of-government Copilot trial documented the readiness gaps, from information governance uncertainty to uneven usage, and none of those close because the licensing path got cleaner. An agency that treats the VSA6 signature as the green light has skipped the part of the work that determines whether the deployment is defensible.

The pre-enablement checklist

Six checks, in the order Frontrow runs them. Each produces an artefact: a configuration baseline, an assessment mapping, or a documented decision an auditor can read.

1. Configure against the ASD Blueprint for Secure Cloud

ASD's Blueprint for Secure Cloud now includes a dedicated Copilot configuration section for Microsoft 365, describing baseline settings for systems built to Blueprint guidance. For an agency already aligned to the Blueprint, this is the authoritative starting point: work through the Copilot pages, apply the baseline, and document every deliberate deviation. For an agency not yet Blueprint-aligned, that alignment work comes first; enabling Copilot on a tenant that has drifted from the Blueprint baseline compounds the drift.

2. Confirm IRAP coverage for what you will actually enable

Microsoft's 2026 IRAP assessments of Azure, Dynamics 365 and Microsoft 365, completed in March 2026 by an ASD-endorsed assessor, support workloads up to PROTECTED under the ISM. That is the platform layer. The discipline the checklist demands is reading the current assessment reports, available through Microsoft's Service Trust Portal, and confirming that the specific Copilot services the agency intends to enable sit within the assessed scope for its classification level, rather than assuming platform coverage extends to every service riding on it. The agency's own authorisation still has to be performed against its own workloads; an IRAP report is an input to that decision, not a substitute for it.

3. Records and FOI readiness

Copilot prompts and responses are agency records, they are discoverable, and they have already been released under FOI, including a two-month log belonging to the Department of Home Affairs' head of national security. Before enablement, the agency needs Purview retention explicitly covering the Microsoft Copilot experiences location, eDiscovery and hold coverage tested end to end, and the FOI procedure updated to include Copilot content. Frontrow's companion guide at /insights/copilot-records-management-retention-foi-australia works through that sequence, including the NSW and Queensland state records positions for jurisdictions beyond the Commonwealth.

4. Sensitivity labels and DLP, in enforcement rather than theory

Copilot respects sensitivity labels and the permissions on the content it retrieves, which means labels only protect what they actually cover. The pre-enablement question is coverage and enforcement state: are PSPF-aligned labels (OFFICIAL, OFFICIAL: Sensitive, PROTECTED) deployed and applied across the estate rather than sitting in a pilot, are container labels on the SharePoint sites that hold classified material, and are the DLP policies that reference those labels in enforce mode rather than parked in audit? A tenant where labelling is aspirational will see Copilot faithfully surface whatever the permission sprawl allows, which is why an oversharing assessment belongs in the same work package.

5. Audit logging that captures Copilot use

Purview audit records Copilot interactions as auditable events, and ISM expectations for agencies handling OFFICIAL and above include retaining audit logs for defined periods. Confirm before enablement that auditing is on, that Copilot events are being captured, and that the retention tier on the audit log matches what the agency's ISM posture requires. This is the control that turns 'we think usage is appropriate' into evidence, and it is also what makes the records obligations in check three enforceable in practice.

6. Know the current data residency and processing position

Microsoft 365 customer data at rest already sits in Microsoft's Australian regions for Australian tenants. Processing is the moving part: Microsoft announced in November 2025 that in-country processing of Copilot interactions would be offered to Australian customers by the end of 2025, then revised that timeline in an April 2026 editor's note to the same post, with Australia now scheduled by the end of 2026. Until it lands and the agency opts in, Copilot processing can occur outside Australia within Microsoft's documented boundaries. Agencies should record which position their risk assessment relied on and diarise a review when the capability ships. Frontrow's guides at /insights/copilot-data-residency-au-sovereign-cloud and /insights/data-sovereignty-data-residency-australia-microsoft-365 cover the residency mechanics in detail.

From checklist to decision

The checklist produces a genuine go, a conditional go, or a documented not-yet, and all three are respectable outcomes. What the trial evaluation and the first two years of agency deployments suggest is that the agencies that did this work up front spent their first Copilot quarter measuring adoption in a scoped pilot cohort, while the agencies that skipped it spent the same quarter retrofitting governance under scrutiny. Under VSA6 the commercial door is open for five years; there is no prize for walking through it unprepared in month one.